Android hardware is always changing. Sometimes, the hardware change is highly visible, like from a regular screen to a wide screen or to an ultra-wide screen. And sometimes, it is not. If you are building apps for Android, I think you must be familiar with the device available in the market. Generally, there are two types. Some Android devices are 32-bit only. They are usually mobile devices for the low-end market or TV-devices. And the majority of mobile devices are 32/64-bit mixed mobile devices. Now, this is a bit different after the Pixel 7 is launched.
The first Android phone to be solely configured as 64-bit is the Pixel 7. And as forthcoming high-end SOC cannot run 32-bit code, this will be a big thing this year. Every developer should get ready for this. It is anticipated that 64-bit only will become the default option in the future, due to several advantages.
First, it is faster. 64-bit applications run faster because they have access to extra registers and adjustments that are not available to 32-bit apps. Secondly, it is safer. The bigger address space makes defense like ASLR more effective and the spare bits can be used to protect control full integrity. And the new hardware instructions get added to 64-bit but not 32-bit instruction sets. Thirdly, it improves system health. Removing support for 32-bit code, saves up to 150 megabytes of RAM, which has been used by the OS even when it is not running 32-bit apps. And finally, starting in 2023, high-end SOCs will no longer be able to run 32-bit code.
Why scan the classpath? There are various patterns that are often used in enterprise Java applications that require scanning of classpath and getting the list of all classes that are present in the application.
For example, if you want to discover all classes with a certain annotation (such as @Component in Spring Framework) to process them in a special way, you need a way to go over all classes in your application and select some of them based on which annotations they have.
However, neither Java SE nor Android have built-in facilities to safely get the list of all classes in your application in runtime. The reason for that is the theory behind classloaders in Java – the ability to go over all classes is neither needed in classic OOP nor feasible for all theoretically possible classloader implementations. However, in practice, scanning classpath and discovering the classes you need is quite possible in most cases, both in your web app and on Android. This is always going to be more or less a hack, but if it has been useful in web applications, it can also be useful in Android apps – with some caution, of course.
Thus, in this article I will show and explain a piece of code that does exactly that – scans your classpath and gives you the ability to go over all classes in your app.
My definition or, rather, my perception of an enterprise mobile app is generally the following:
The app in question is a mobile client for a multi-user client-server application. It can either be the only kind of client for the app, or co-exist with a web interface or, for example, a PC desktop client for the same server app.
It has a “serious” user interface – rather than trying to impress the end-user with a slick, non-typical UI, it aims to be as straightforward and predictable as possible. It tends to have various forms, charts, trees and lists of various complexity.
Conceptually, very often a big part of the app is dedicated to managing (CRUDing) a set of entities such as users, documents, reports etc. Domain models can get quite complex, often with tree-like structures, fine-grained user permissions with different access levels and profiles.
Internally the app uses typical client-server protocols like SOAP, XML-RPC or even CORBA. Often in-house protocols and frameworks are used on top of those generic ones or instead of them. You get the picture.
Enterprise apps might not seem to be the most interesting kind to work on. However, they are attractive for many studios because customers usually pay well for them. In addition, as a developer, you will find that they are often challenging to implement – at least with functional and internal quality that will satisfy both the customer and you.
In this article, I would like to cover a list of typical facilities that Android developers need when developing such kind of apps. The platform does not really have that much to offer (as we will see), and many developers build their own ad-hoc frameworks that they try to reuse as needs arise.
I will share some thoughts that I have about that, and will be happy to know your stories too.
How do you separate application state, user interaction logic and data presentation in your Android apps?
Platform designers did not enforce any high-level application architecture framework upon us but left us enough options to implement our own solutions based on application requirements and scale. Most simple applications will get away with just storing data in their widgets (such as in text fields, spinners etc.) and their state manipulation right in event handlers such as OnClickListener‘s. However, if you are going to write a complex application or plan to sophisticate your simple app further, you should really think how to layer it well so that the architecture supports adding new features and satisfies the expected performance, flexibility, responsiveness and other requirements, and your code does not become a mess.
In this article, I will show you one practical approach to dividing application code into three layers according the MVC paradigm and connecting the view to the controller using the Android messaging framework. I used it in my own code and although it might not be 100% academically correct or applicable for every possible app, I love the benefits it gives to me as my app grows more and more complex.
There are many cases where we use byte[] in our code. In fact, it is the “rawest” type possible in Java unless you go native. Thus, byte arrays are often used to store raw data such as bitmaps, audio and various binary objects.
The previous two articles on MTR were dedicated to audio decoders, including WAV and MP3. In both cases, raw PCM data that was the result of your decoding was a byte array (which you would later write to AudioTrack).
I already mentioned in one of those articles that you should consider streaming any audio that is longer than the reasonable maximum. However, even if your data will definitely fit into the heap, in most cases you can still do better than just using a byte array. Why? Read on (relevant for non-audio byte[]s as well!)
If you’ve managed to hack around the various issues that AudioTrack has, then you are probably enjoying its benefits, such as low latency (in the STATIC mode), ability to generate audio on the fly (in the STREAM mode) and the wonderful ability to access and modify raw sound data before you play it.
However, the problem now is getting that data from a source. Many applications that need to use AudioTrack do not generate PCM audio from scratch (an example of an app that does that would be Ethereal Dialpad and other similar apps). You will probably encounter the need to load and use existing audio samples from file sources such as WAV or MP3 files.
Don’t expect to be able to use MediaPlayer facilities to decode raw audio from WAVs and MP3s. Although MediaPlayer can play those files pretty well, its logic is almost entirely contained in the native layer and there is no option for us to plug in and use the decoders for our own purposes. Thus, we have to decode PCM from audio files manually.
In this article I will cover WAV files and in the next one we will get advanced and read audio from MP3s.
Lately I’ve been digging into Android audio APIs. Earlier I wrote an introductory article that describes the three available APIs for WiseAndroid. Now this article assumes you are familiar with AudioTrack, SoundPool and MediaPlayer at the basic level.
What I want to present in this post is my experience with the existing audio APIs on Android, including the issues and problems I personally faced. I will also shortly cover OpenSL ES, the standard that is expected to be supported in one of the upcoming Android releases.
I don’t know about you but I have an emotional attachment to old platforms and APIs. They are often sweet and nice in their primordial simplicity, even with their well-understood limitations. Even when they become obsolete, we developers still remember and miss them.
In case of Android, version 1.5 / API level 3 is technically obsolete but is far from being extinct from the device market. In fact, as of the day I write this article, it is one of the most widely installed Android versions on the market. (And if you add the not-so-different 1.6, they take almost half of the market together.) While subsequent versions brought us a lot of goodies in various areas of the platform API, 80% or more of all functionality our apps need today is present in 1.5.
Sure, there are cases when your app just isn’t meant to run on 1.x. For example, its core functionality is based on the APIs that are absent from API level 3 (e.g. you’re making a live wallpaper), or when you don’t want to support old devices for performance reasons, or due to a marketing decision. However, in many cases what makes developers raise the minSdkVersion bar is the need to use some of the 1.6+ APIs, such as the new contact management facilities, signal strength detection or better animation support.
The good news I’m trying to bring in this article – to those who aren’t yet familiar with this trick – is that you can actually use the new API yet keep minSdkVersion at 3. This trick might not work in all cases, and might look like a hack, but it will work for many situations like this – and who knows, might allow your app to reach out to its grateful, ready-to-pay customers who still use 1.5.
Most Android developers start their learning from pure Java, Android SDK based apps. While everyone is aware that there is the NDK (the Native Development Kit), they don’t face the need to use it. Since NDK is distributed separately from the SDK, including documentations and samples, you are not likely to get familiar with NDK before you actually try it as a solution to one of your development challenges.
Because of that, many people think of NDK as of “black magic” of Android development. Many developers who are not familiar with NDK think it is 1) complex to understand and use, and at the same time a lot of developers will think it is a sort of a 2) silver bullet that can solve any problem that can’t be solved with SDK.
Well, both opinions are rather wrong, as I hope to show further in this post. Although it does have a maintenance cost and does add technical complexity to your project, NDK is not difficult to install or use in your project. And, while there are cases where NDK will be really helpful for your app, NDK has a rather limited API that’s mostly focused on several performance-critical areas, such as:
OpenGL, including support for some newer versions that the (Java) SDK supports
Math (some, but not all, calculation-intensive algorithms might benefit from being done on the native layer)
2D graphics – pixelbuffer support (only starting with 2.2)
libc – it’s there for compatibility and perhaps to allow you to port existing native code
In this tutorial we will take our basic Android development environment that we created in one of the previous articles and add NDK support to it. We will also create a basic skeleton project that uses NDK that you can use as the foundation for your NDK-powered apps.
Hello again! I’m back from a wonderful vacation and ready to share some more experience of Android programming. Today I’m presenting a simple drum machine app that I made for fun. If you saw the video above, then you probably got the idea how a drum machine works. The design was inspired by one of the greatest drum machines ever – the AKAI MPC. You can have a look at how the original device looked like for example here. Our app is, of course, greatly simplified compared to AKAI MPC, but you can have some fun with it too.
Here’s a screenshot for a better idea of how the UI looks (clickable):
Some interesting features of this app:
The UI is done using bitmaps and custom controls to imitate the original device
The latency is low enough not to be annoying (at least on my Droid)
You can press multiple buttons at once which is very good for long samples such as the bass drum
The LCD screen control uses a 9-patch bitmap background, and switches between flashing, static and ticker text
The LCD screen uses a custom TrueType font that is included within the app
Now let’s see how the most interesting features of this app were implemented (as usual, the source is available at the bottom of the article).
