Let's say you wake up one morning, and think, "Hey, I'm going to build an Android app today." First off, good choice! As of the end of June, 500,000 Android devices were being activated every day, outpacing even the iPhone. That means there is a large, potential audience for your app. Additionally, Android is built with Java. This may not seem like a big deal, but I have worked in Objective-C on the iOS platform for a few years, and while I am now quite comfortable with it, the iOS SDK offered a steeper learning curve than I experienced with Android. Android just felt more accessible when I first started working with the Android SDK. That said, there are some clear differences from any other Java application you have built in the past, and I'll go over some of those in the first section.
So moving forward in time, you have completed your first app, and have submitted it to the Android Market. Congratulations are in order, as your friends are all downloading your app and tweeting about it. Now it is time to start on your second app. You spend a few days, and suddenly realize that you are starting to reuse code from your first app, which in itself is not a bad thing. Code reuse can be valuable. But you notice there is a lot of boilerplate code that tends to be repeated often, and that can be distracting from focusing on your business logic. Fortunately, there are some ways to improve upon this.
In this blog post, I will provide an overview of Android and the application lifecycle, and discuss some of the limitations imposed by the framework. I will also review a few of the techniques and third party projects that can help you clean up your Android code, and focus on what you want to achieve with your app.
Android Overview
Let's begin with a brief overview of how Android works. Android applications (apps) are built using Java, and compiled to class files. The class files are then compiled into the Dalvik Executable (DEX) format, so they may run on the Dalvik virtual machine used by Android. After conversion to DEX format, the class files are zipped to an Android Package (APK) for distribution to devices. Because of the use of the DEX format, the Dalvik VM is not a true Java Virtual Machine, since it does not operate on Java byte code. Additionally, the Dalvik VM is based on a subset of the Apache Harmony project for its core class library. This means that many of the classes and methods to which you are accustomed in Java SE are available, but certainly not all. I have found the API reference on the Android developer web site to be an invaluable resource for reviewing these differences.
By default, each Android application is assigned a unique Linux user ID by the Android operating system. When started by the system, an application runs in its own Linux process, within its own virtual machine (VM). The system manages the starting and shutting down of this process when needed. As you can guess, this means that each application runs in isolation from the other running applications. When installed, an app can request permission to access hardware features or interact with other applications. The user elects to grant these permissions to the app or to not install it. The permissions required or requested by an app are defined in each app's Android Manifest file. This is an XML file that lists all the components of the app, and any settings for those components. The four types of application components are activities, services, content providers, and broadcast receivers. For the purposes of this post, I will be focusing on activities.
Activities basically represent a single screen of an Android application. For example, a Twitter app may have a login screen, a screen with a list of tweets, and a screen for authoring a new tweet. Each of these screens represent different activities within the application. As a developer you never instantiate an activity object yourself. Activities are activated by sending an asynchronous message called an Intent, as seen in the example below.
startActivity(new Intent(context, HomeActivity.class));
When startActivity(Intent intent) is called, the system either creates a new instance or reuses an existing one in order to display the activity to the user. The important point is that the system controls the starting and stopping, and creation and destroying of the application and each activity. If you want to interact with this process, then the application and activity classes provide methods for different lifecycle events that you can override in a subclass.
Dependency Injection
The Spring Android project recently reached its fourth milestone release. With that release we have continued to improve upon the RestTemplate and Spring Social support for Android, which simplifies the process of making RESTful HTTP requests and accessing REST APIs secured by OAuth. And while we believe these are valuable additions for Android development, some developers have asked questions regarding the possibility of dependency injection support in Spring Android, because as you are probably aware, the Spring Framework already provides a popular Inversion of Control (IOC) container for enabling dependency injection in enterprise Java applications. Early in the Spring Android planning stages, dependency injection support was identified as a potential candidate for inclusion in the project. At that point, it was unclear what that support would entail, and how it would be implemented. Because of this, I began the process of researching and investigating the possible methods available for, and limitations of, performing dependency injection in Android.
Well, what is dependency injection? If you ask two different developers, you may get two different answers. You might hear about IOC, XML files, annotations, or some other implementation detail. In reality, dependency injection is simply a technique to reduce coupling by handing an object what it needs to work, rather than having the object reach out into its environment. That sounds easy enough, and you might be thinking to yourself you can already get this with class constructors and setter methods, which is completely true. However, recall from the overview section above, the Android system drives the application lifecycle, so the way we can do this is limited.
The Android Way
Without using any third party libraries, it is rather easy to pass a dependency to an Activity. As discussed earlier, the system creates the application instance. So by extending application, you can effectively create a singleton dependency instance, which can then be accessed by any of the activities in the app.
public class MainApplication extends Application {
private MyService service;
@Override
public void onCreate() {
super.onCreate();
service = new MyServiceImpl();
}
public MyService getMyService() {
return this.service;
}
}
The activity class has a method called getApplication() which returns a reference to the application object that owns the activity. We simply cast it to MainApplication, and we can access the getter method for the MyService. Of course, the activity now has to "know" about the application, which might seem like a disadvantage. But remember, the activity already knows about its application. The method is built in.
public class MainActivity extends Activity {
private MyService service;
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
MainApplication app = (MainApplication…
