Threads signaling mechanisms in Java

In Java, there might be situations where you want to perform an operation on a certain thread and then, the same thread should wait for a certain condition before completing its task. This condition happens after another thread completes its execution.

For instance, we want to run a syncronous method on thread-1:

A first option to do this is by using the wait() and notify() methods provided by Object class.
The first thread calls wait() and the callback thread calls notify().


We must be carful though, because if the notify() method happens-before the wait() one, the waiting thread will wait forever.

To prevent this, we need a boolean variable, that can be used to prevent a similar scenario:

It is also possible to use Semaphore class, from java.util.concurrent package and call acquire() and release() methods to do the same thing.

Take a look also at this interesting tutorial that deals with many important Java concurrency topics:
http://tutorials.jenkov.com/java-concurrency/index.html

Inter Process Communication on Android: Binders and Aidl

In contrast with iOS, where an app can be responsible for only one process at a time, Android provides many ways to create an app which spawns two or many processes. On Android instead, there is the possibility for two different apps (i.e. two different apks) to communicate, or two processes that live in the same apk but in different processes.
In both cases, the system must provide a "channel" that allows two processes to communicate. In contrast with threads, two processes don't share memory for data, therefore the system must provide a way for the data to cross the process boundaries.

Historically, have been defined many ways to create a communication between two processes (for example, CORBA, or JRMI); Android has defined its own implementation: it is called AIDL, and the acronym stands for Android Interface Definition Language.

This blog post describe how to create a simple application that spawns two processes, and in detail shows two ways to implement it. The first is through the Messenger class and in many cases it is enough powerful, the second one is more low level, but requires to implement an AIDL interface. In detail, there is a simple Activity that lives in a process (the process where the app lives) and two services. Both the services are remote; the first one communicates with the activity via a Messenger, the second via the AIDL.


In the code above, there is the important part of the manifest, where the two services are declared. As we can see, to declare a service as remote, we must specify the android:process attribute. The exported attribute tells the system if a component can be exposed to other applications; in case it is true, another app can launch the component. But this is not relevant in our context.

IPC with Messenger and Handler

This mechanism allows two process to communicate and save the developer from creating AIDL files and it is more simple and straightforward; the system under the hood however will use AIDL but the developer doesn't see it.

In the code above, it is shown how the service is created and bound.

In the code above, it is shown how the remote service is implemented. If the service is remote, we must implement the method onBind(); the three fundamental components are: binder, messenger and handler.
The service use a handler, used to receive data from a remote process; the binder is as its name suggests, the "thing" that binds the two processes.  The messenger is tied to the binder and provides a convenient way for the two sides to communicate effectively. In the example above,  the activity generates a Messenger from the binder received as parameter in the onServiceConnected() callback. It will use the messenger to send data to the remote process (method sendMessage()). In the ClientService.java, the handler is used to receive data from the remote process.

The example shows that the Process ID of the sender is different from the process ID of the receiver and the string sent from the activity is correctly received from the service, that lives in its own process.

IPC with AIDL

If we want to use AIDL, we must first specify an interface between the client process and the server one; it is a file with methods shared between the client and the server. These methods are the "entry points" for a process to start the communication with the other process.

In our case, the scenario is very simple. The aidl file contains only a method (multiply) that multiplies two numbers. The service will take care of the mathematical operation. In the example we don't return a value to the client, but of course it can be done.

When we define an aidl file, the system will generate the relative implementation in the /gen directory. If you have a look at the implementation, it is easy to spot what happens under the hood: the data which have been serialized before the dispatch, are then received as a Parcelable object, deserialized and then the method at the server side (in this case multiply) is finally called.

The service implements the Stub (defined as an abstract class in the auto-generated file); the Stub is also the binder (extends Binder).
The activity retrieves the interface to communicate with the server via this method:
multiplierService = IMultiplier.Stub.asInterface(service);
It returns a client-stub that has the same interface as the counterpart implemented at the server side (AidlService).
When we have the instance, we can banally call the multiply method as if it were a local method:

multiplierService.multiply(5, 7);

The complete code can be found here:

https://github.com/nalitzis/BinderTest

Threading, loopers and messaging queues in Android

Android provides an efficient way to allow communication between different threads.
One thread can communicate with another by creating a Message object. Usually a Message is not created with the normal constructor; instead, it is used one of the static factory methods provided by the class, for instance obtain(Handler h, int what, Object data).

One way to send a message to another thread is to create a Messenger object and invoke the send method with the Message to send.
But how can we pass to the messenger which thread will receive the message? In the constructor, it is specified the handler bound to the target thread, i.e. the thread that will receive a messenger. An Handler is an object that, as its name suggests, when created, binds itself with the thread that is creating it.
Consequently, the receiver thread will create the handler, that will be used by the sender thread that calls the send() method with a Messenger object.

This is the basic behavior.
But usually we want that, at least the receiver thread, will be running indefinitely, or at least, as long as we need it running.
We can use a Looper object to transform a simple "one-shot" thread, in a thread that runs indefinitely, or at least, as long as the quit() method is not called, to quit the loop.
The Looper class "enriches" the behavior of a thread in two ways:

• transforms a thread in an indefinite one
• creates internally a messaging queue that provides a serialized handling of the messages received. A message received is handled in the handleMessage() method of Handler.Callback.

In the script above, the code between Looper.prepare() and Looper.loop() creates a handler that will handle the messages received by the current thread. If a message is received before the handler has finished processing the message, it will be automatically enqueued and executed as soon as the previous message has been completely processed.


The Handler subclass manages the incoming message. In the example above, it just prints the data received and sleeps for 2 seconds.

I have created a short demo project consisting of a main activity and a looper thread. The looper thread processes in its queue messages sent by the main thread (ui thread) of MainActivity. A message is sent each time the button send is pressed by the user. I have inserted a sleep of 2 seconds in the handler() method of the handler bound to the receiver thread, to show that if a user clicks quickly many times on the send button, the message queue handles the incoming messages sequentially, one after the other.

The demo project can be downloaded from here:
TestLooper

Pleas note that I had to use wait() and notify() methods because the code that trasforms the thread in a looper is not so immediate, so before getting the handler we must be sure that the looper has been created.

Remove views with nice animations

In iOS is very simple to create effective animations on UI components.

For an app I'm currently working on, I would like to create an animation on a set of views, vertically aligned. When user taps on a button inside the view, the app should start an animation that translates and rotates te view offscreen, while fading it at the same time. At the same time, all the views below it, should react by translating up occupying the space left by the removed view.

This is the initial scenario:

To perform this effect, we need two different animations, one on the view to delete, and the other on the views below it.

This is the first one:


To translate all the views below the one that we want delete, we first need to find them:


 and then we can apply the translation to all of them:


The complete sample project can be found here:
https://github.com/nalitzis/View-delete-animations

iOS view hierarchy

Sometimes it is usefeul to find the view hierarchy of a certain graphical component.
On iOS, here's a small code snippet to do this:

Android fragments for beginners

Fragments have been introduced in Android with the Honeycomb milestone (aka Android 3.0). The main reason was to provide a flexible and powerful solution to deal with different kind of screens (i.e tablets and phone displays).

An activity layout is composed by one or more viewgroups, at the end, by simple views. Every view group is also called layout. An activity has one root layout, usually set with the setContentView(int resId) call.

If a layout is composed by many sublayouts/views, having all the UI code and the application logic code for the activity inside one class might quickly increase the complexity and lower the maintainability of the component.

A solution I've used in the past was to subclass the layout class and create a custom layout where I put all the UI code related to such layout. This approach has a drawback: a view group is not an activity. You've to put the app logic code inside the activity and consiquently to provide some sort of communication channel between the view and the activity when, for instance, you want to react to user actions (tap on a button, typing of a text). Components became tightly coupled and difficult to maintain/change.


With Honeycomb (but also in previous releases of the platform, thanks to the compatibility package), you can use fragments. These are like layouts but they have their own lifecycle, they have been created with the aim to contain both UI and app logic code, and can be used to provide an efficient way to deal with layouts that must be placed in different positions depending on the device the app is running on, or on the orientation of the device itself (portrait, landscape).




I've create a simple test project that shows how a layout can be created by different fragments that place themselves in a different way based on the orientation of the device.


The activity has provided a main layout for portrait and another for landscape. Fragments are placed in the LinearLayout in a different way depending on the orientation of the device:





The app logic that manages the fragment is inside the fragment itself:



As you can see, the fragment has framework methods that allow to save the current state. In the sample, a simple counter value is saved and if you change device orientation its valued isn't lost. As you can see, all the application logic pertaining the fragment is inside the fragment. The activity can handle other higher level tasks, such as fragment repositioning/move or orchestrating tasks affecting different portions of the UI.

The sample code can be found here:

https://github.com/nalitzis/SampleFragments

Audio mix and record in Android

iOS offers, among its frameworks, many interesting features that allow to create audio tracks by simply mixing multiple tracks together. You can use Audio Unit and its methods, as described here:

http://developer.apple.com/library/ios/#documentation/AudioUnit/Reference/AUComponentServicesReference/Reference/reference.html#//apple_ref/doc/uid/TP40007291

But what if you need a similar result on Android? Android does't offer such feature in its audio framework. So I've spent a couple of days on google groups and stackoverflow, reading unanswered questions of android devs searching for a similar functionality on the Google mobile platform, or developed and released by third party contributors and external devs.
It appears there isn't nothing available.
So I've studied the problem and the tools I had to solve it. First let's see what possibilities the platform offers to play files.
Android audio framework consists of these main classes for audio playback:

• MediaPlayer: useful to play compressed sources (m4a, mp3...) and uncompressed but formatted ones (wav). Can't play multiple sounds at the same time. [HIGH LEVEL methods]
• SoundPool: can be used to play many raw sounds at the same time.
• AudioTrack: can be used as SoundPool (raw sounds), but need to use threads to play many sounds at the same time. [LOW LEVEL methods]

I've found that AudioTrack works fine to play uncompressed raw data, and if you want to play multiple sounds at the same time, you can create different threads and start the playback in an asynchronous fashion.
Unluckily this is not always precise: sometimes you can experience a delay before a certain sound is played, and in such cases the final result is far from acceptable.

Another option is to mix sounds before playing them. This option offers you a nice plus: you obtain the mixed sound that is ready to be stored on file. If you mix sounds with SoundPool for instance, then when you play it, you cannot grab the output and redirect it to a file descriptor instead of to the audio hardware (headphones or speaker).
As mentioned at the beginning, there is no ready solution for such problem. But actually we will see the solution is rather trivial.

Before delving in the details of how 2 sounds can be mixed together, let's see how can we record a sound on Android. The main classes are:

• MediaRecorder: sister-class of MediaPlayer, can be used to record audio using different codecs (amr, aac). [HIGH LEVEL methods]
• AudioRecord: sister class of AudioTrack. It records audio in PCM (Pulse Code Modulation) format. It is the uncompressed digital audio format used in CD Audio, and it is very similar to .wav file format (the .wav file has 44 bytes header before the payload). [LOW LEVEL methods].

AudioRecord offers all the features we want be able to control: we can specify the frequency, the number of channels (mono or stereo), the number of bit per sample (8 or 16).


In the fragment of code posted above, there is a simple function that can be used to record a 44.1khz mono 16 bit PCM file on the external storage. The function is blocking so it must be run on a secondary thread; it continues to record until the boolean isRecording is set to false (for example when a timeout expires or when a user taps on a button).

And now comes the most interesting part: how to mix two sounds together?

Two digital sounds can be mixed easily if files have the same features (same number of channels, same bit per samples, same frequency). This is the simplest scenario and is the only one I'm covering in this post.
Every sample in such case is a 16 bit number. In java a short can be used to represent 16 bit numbers, and infact AudioRecord and AudioTrack work with array of shorts, which simply constitute the samples of our sound.

This is the main function used to mix 3 sounds together:


There are some complementary methods I'm not posting here because this post is already too long :) but these are some small hints of what they do:

• createMusicArray reads the stream and returns a list of short objects (the samples)
• completeStreams normalizes the streams by adding  a series of '0' shorts at the end of smaller files. At the end the 3 files have all the same length.
• buildShortArray converts the list in an array of short numbers
• saveToFile saves to file :)

The key point in the method is that we sum every sample together. We normalize the short to a float [-1,1] so we dont have under/overflow issues. At the end we reduce a bit the volume and we save it in the new array. That's it!

Of course this is the simplest scenario; if the samples have different frequency we should do other computations. But I think most of the time we want to mix sounds we can also control how they are recorded thus reducing its complexity a lot.

Once we have a PCM mixed sound, it can be transformed in a .wav file so that every player can read it. EDIT: as many people have asked me some more help, below it is the code snippet to build a short array from a file containing a raw stream.