Vlad Nevzorov's blog

In earlier posts we discussed:

• Android application architecture background
• Architectural patterns implemented by Android application architecture
• Main parts an Android application consists of

Today we are going to discuss various mechanisms through which parts of an Android application collaborate. For lack of better term we’ll call all those mechanisms together as “communication layer” (to my knowledge, Android documentation does not offer any term for this).

As we mentioned earlier, Android application framework implements several communication patterns within its communication layer:

• Message passing which involves Intent class (this involves also late binding)
• Publish/subscribe or pub/sub which also involves Intent class and BroadcastReceiver class
• Late binding and method calls that are used for accessing ContentProviders and local (in-process) Services
• Late binding and Inter-process Procedure Communication (IPC) for invoking remote (AIDL)Services

Message passing

This is probably the first communication mechanism which a developer encounters while learning Android application development. It is used to start an Activity or a Service. It is implemented via three methods on Context class (which we discussed in one of earlier posts) and one method on Activity class:

• startActivity() of Context class to launch an Activity.
• startActivityForResult() of Activity class to launch an Activity
• startService() or bindService()of Context class to start a Service if needed and to communicate with it (there are slight differences between those two methods; look at the javadocs for more details)

In both cases Intent class plays a role of a message passed.

How does Android know which Activity or Service should receive the message? There are two ways how this is done:

• Intent may specify a name of the target component explicitly. Such Intents are called “explicitIntents” and they specify a target component via setComponent() or setClass() methods of Intent class. This type of Intent-based communication mechanism does not implement late binding pattern while all others do implement it
• Target component is defined by a rather fancy resolution mechanism based on Intent filters.

Please note, in case of message passing communication mechanism the message (an instance of Intent class) is delivered to only one component or not delivered at all.

Publish/subscribe

Publish/subscribe communication mechanism involves the same Intent class as a message and the same intent filters as a resolution mechanism defining target components, but it works quite differently. Intents used for publish/subscribe communication are called “broadcast Intents”. Those broadcast Intents can be delivered to BroadcastReceiversonly. Since BroadcastReceiver is a class and Activity and Service are classes as well, neither Activity nor Service can receive the broadcast Intent (Java prohibits multiple inheritance).

Also, unlike Intent used for message passing, a single broadcast Intent can be delivered to many target components.

In fact, Android implements 2 different publish/subscribe mechanisms each o which has two versions (regular one and sticky one):

• Normal broadcast which is implemented bysendBroadcast() and sendStickyBroadcast() methods of Context class.
• Ordered broadcast which is implemented bysendOrderedBroadcast()and sendStickyOrderedBroadcast()methods of Context class

You are still not confused, right?

Normal broadcast mechanism delivers the Intent to all eligible BrodcastReceivers asynchronously and they act on it independently, i.e. one BrodcastReceiver can’t affect either how another BrodcastReceiver is reacting on the Intent or whether the Intent is delivered to another BroadcastReceiver. It is a regular pub/sub pattern.

Ordered broadcast mechanism delivers the Intent to eligible BrodcastReceives in a sequential manner, i.e.toone at a time. Due to this each BrodcastReceiver can potentially:

• Use results produced by previous BroadcastReceivers that worked on the same Intent
• If needed, abort further processing of the Intent

By executing ordered broadcast, a component which initiated it gets opportunity to receive the result of processing the Intent by all BroadcastReceivers in the chain.

Ordered broadcast actually is an implementation of chain-of-responsibility design pattern.

Sticky broadcasts are versions of the corresponding regular broadcasts. The difference is the Intent is available until it is explicitly removed by removeStickyBroadcast() method of Context class. Please note, this type of broadcast should be used with great caution since not removing the sticky Intents will result in a memory leak.

Conclusion on Intent-based communication mechanisms

All communication mechanisms described so far make use of Intent class as a message. Please note, that majority of corresponding methods are implemented by Context class so they can be theoretically used by all subclasses on the Context class.

By this point one may start thinking that all Android application communication mechanisms are using Intent class. Not at all.

Late binding of ContentProvider

ContentProvider class is essentially a wrapper around SQLite database in most cases although theoretically it can use other persistence mechanisms to store/retrieve data. You can read more about the class and its usage here.

There are many ways how Android code can use ContentProviders. Some of them include getting an object which acts as a proxy to the ContentProvider (normally it is an instance of a subclass of ContentProviderClient, which implements proxy design pattern). Some of them return an instance of Cursor class which allows iterating through data set returned by ContentProvider. In all cases the concrete ContentProvider which is going to be used is identified through URI (see details here).

Overall, it is a typical late binding pattern.

Late binding and Inter-process Procedure Communication (IPC) of Service

If you think it’s all communication mechanisms, you are mistaken.

Apart of ContentProvider class there is Service class which architecturally plays the same role of Model in MVVM architecture pattern. We have discussed the hypothetical reasons why Android has two different classes to fulfill the same role in the previous post here.

There are two types of Service and each requires a separate communication mechanism:

• Local Service which runs within the same process where it is invoked. Architecturally it is similar to ContentProvider apart that it has its own lifecycle and it is not necessarily backed by DB. A version of late binidng is used to access the local services
• Remote Service which runs within another process from where it is invoked. Such type of service is accessed through a sort of IPC call implemented using AIDL (Android Interface Definition Language)

It is worth mentioning that the same Service may be used as both Local and Remote; the difference is in where the component which invokes the Service is located (within the same process or in another process).

You can read more about using Services here and here.

Read Full Post »

OK, we looked at Android application architecture background and architectural patterns implemented by Android application architecture. Now let’s talk about main parts of an Android application.

In this post we’ll introduce main “personages” of Android application architecture.

Android application usually consists of:

• Java classes that are subclasses of main Android SDK classes (View, Activity, ContentProvider, Service, BroadcastReceiver, Intent) and Java classes that have no Android SDK ancestors

• Android manifest
• Resources like strings, images etc
• Files

Java classes

The diagram below represents a class hierarchy of main classes from Android SDK a developer has to deal with while developing Android application:

There are much more classes than that, but those are the main ones. Classes highlighted in yellow are those a developer has to deal with (e.g. extend) directly. Other classes are important as well, but they are relatively rarely used directly.

View class is a base class for all GUI widgets. Android application GUI is a tree of instances of its subclasses i.e. GUI widgets. One can build the tree programmatically, but this is not how you should do this. GUI is normally defined by an XML GUI definition (layout file) and inflated (Android term) automatically into a tree of corresponding objects at runtime.

Activity class and its subclasses are the ones that provide logic behind the GUI. Actually it corresponds to ViewModel in Model-View-ViewModel architecture pattern (MVVM). Relationship between subclasses of Activity and GUI layout is 1-to-1; normally each subclass of Activity has one GUI layout associated with it and vice-versa. Activity has a lifecycle.

During the lifecycle Activity can be in one of three states:

• Active and running when its GUI is in the foreground (technically speaking – on top of activity stack)
• Paused if its GUI lost focus but it is still visible. No code is executed in this state
• Stopped if its GUI is not visible. No code is executed in this state

Activity code runs only when the Activity GUI is visible and has focus. Also there is no guarantee that Activity object and its associated objects are in memory while the Activity is paused or stopped (very important point to remember; we discussed this Android memory management peculiar feature earlier).

ContentProvider class and its subclasses correspond to Model in MVVM architecture. In most practical cases it is a wrapper around SQLite database with rather fancy URI-based way to query the database. Theoretically nobody prevents a developer from building ContentProvider which will be using something else instead of DB for storing data. However given that query() method of ContentProvider returns Cursor object which is quite similar to JDBC ResultSet interface and the way how the query is made, nobody would doubt that the real purpose of ContentProviders is to encapsulate a database.

I don’t know how Android team came to such design, but my guess is here we have a combination of two good but not very compatible ideas.

Here is why I think so. The whole idea of content provider is likely inspired by AJAX application architecture. AJAX applications normally use MVVM architecture where Model is represented by particular URIs on a server side (however this has changed somewhat since introduction of HTML5 which allows storing data locally). Indeed, the fact that ContentProvider class is queried by URIs and makes extensive use of MIME types points to AJAX as an origin of the design. Remember, Google folks were developing a lot of AJAX software, e.g. Gmail, Google Docs etc, so it was natural to borrow ideas from AJAX application architecture for them.

Probably somebody else came with another cool idea: how great it would be to have a fully functional relational database running on a mobile device! (note, this was happening at around 2005 when mobile phones were much less powerful than now). And as a result they combined two good ideas into one ContentProvider class. As it often happens in software development combining two great ideas not always results in a good design; in Android case we have rather confusing ContentProvider design.

Service class and its subclasses are something which I have difficulty to classify. I think, Google folks have the same difficulty (please read their javadocs). They classify it by mostly describing what it is not. I would personally classify it as a special type of Model, serving a bit different use case than ContentProvider does.

In my opinion, architecturally design of Android Service was inspired by OSGI services.

I think Service is the solution Google folks came up with to solve a logical problem they created in Android application architecture with its threading model.

Think of this: Activity is active and running only when its GUI is on foreground. As soon as another Activity GUI comes in front of the current one, the current one stops running even if it was doing something. And what if you need to perform certain operation even when the process which tries to perform it is not on foreground? You can’t do this with Activity. You can’t do this with ContentProvider as well since it does not have its own lifecycle and it can run only while Activity which uses it is active.

Here Service comes to the rescue. It can be executed even when the process it runs within is not on a foreground. So if you develop Activity which must perform a long running operation which should be completed even while running in background, you should create Service implementing that operation and invoke it from Activity.

Service has a lifecycle as well. This means that it can be instantiated and run by Android application framework under certain conditions (we’ll discuss this later).

As I mentioned, as a Model, Service is somewhat of more general purpose than ContentProvider. It can use DB, but its API is not bound to DB as ContentProvider API does. In many cases Services are used to connect to external servers.

BroadcastReceiver class and its subclasses serve as “subscribers” in publish/subscribe (or pub/sub) communication mechanism implemented by Android application architecture.

Intent class and its subclasses serve as messages in message passing and publish/subscribe communication mechanisms implemented by Android application architecture.

We’ll discuss the communication mechanisms in another post later on.

Of course, Android application developer is not limited to just extending Android SDK classes. She can write her own classes as she wants. But all they will be just “helper classes” of sorts for those main classes derived from Android SDK classes.

Android manifest

Android manifest is another important part of Android application. The idea has been clearly inspired by Eclipse plug-in manifest.

Android manifest is an XML file and it serves several functions. Here is Google description of manifest functions:

• It names the Java package for the application. The package name serves as a unique identifier for the application.
• It describes the components of the application — the activities, services, broadcast receivers, and content providers that the application is composed of. It names the classes that implement each of the components and publishes their capabilities (for example, which Intent messages they can handle). These declarations let the Android system know what the components are and under what conditions they can be launched.
• It determines which processes will host application components.
• It declares which permissions the application must have in order to access protected parts of the API and interact with other applications.
• It also declares the permissions that others are required to have in order to interact with the application’s components.
• It lists the Instrumentation classes that provide profiling and other information as the application is running. These declarations are present in the manifest only while the application is being developed and tested; they’re removed before the application is published.
• It declares the minimum level of the Android API that the application requires.
• It lists the libraries that the application must be linked against.

Please note the second point. It means even if there is a class extending Activity, ContentProvider , BroadcastReceiver or Service within an application, the class can’t be used unless it is explicitly described in Android manifest.

Resources

Any modern GUI application technology uses resources in some form. Android applications are not an exception of the rule. They use following types of resources:

• Pictures
• GUI layouts (XML files)
• Menu definitions (XML files)
• Textual strings

The way resources are referenced by Android applications is somewhat unusual. Normally in Java resources are identified by strings. Such strings may contain e.g. a path and a name of a file containing the picture or an ID of particular string etc. The problem with such approach is that mistakes in those references could not be caught during code translation.

Let’s consider following example. A file named mybutton.png contains a picture for a button. A developer makes a mistake and types mybuton.png as a reference to the resource in the code instead of using the correct file name. As a result the code is instructed to use nonexistent resource, but the code will compile just fine. The mistake may be discovered only during testing (and may not be discovered at all).

Google folks came with an elegant solution to the problem. Android application build generates a special Java class named R (just a single letter name) for each package where classes use resources. This class has a number of static final data members. Each such data member is a reference to a particular resource and they are used in Android Java code for referencing resources. Due to this each mistake in referencing resources is discovered at compile time.

Files

Android applications use several different types of files:

• “General purpose” files
• Database files
• Opaque Binary Blob (OBB) files (those represent encrypted file systems on its own that can be mounted for the application)
• Cached files

Although ultimately they are all just Linux files, it makes sense to consider them as separate types of files since they are handled by different Android APIs and stored separately. There is also a distinction between files stored in internal device storage and in external device storage (the latter may be not present or disappear/appear at any moment).

APIs for working with the files are implemented by Context class which is an ancestor for Activity and Service classes. We already discussed this class here.

That’s all for now. In the next post we’ll discuss how different parts of Android applications communicate between them.

Read Full Post »