Recently I was studying some finer points of application development on the Android platform, and I was inspired to share some basic information with those who may be unfamiliar with the system.
The first thing you need to know about Android applications is that they aren’t like what most people think of as applications. On most platforms, desktop computer operating systems included, an application has a single entry point. So you “start” the application, and it runs code from a specific place. Usually this is in the form of a main() function.
The best thing about Chrome, Android, and other Google projects, in my opinion, is that Google hasn’t been working on them for decades, adding on to and working off of archaic concepts and practices. They’re also really good about noticing obvious problems with the way that others have been doing things for years, and not making the same mistakes. They’re like the Dyson of software.
But back to the point – Android applications work differently. They consist of multiple components which can all be started independent of the rest of the application. You can define a “default” component, so when a user simply clicks on the application’s icon it will react in an expected way. But it can also be started by other applications (provided the application allows it) or by various events, defined as being of interest to the application. Each time the application is called, it is given the opportunity to do different things depending upon the situation that made it start.
As a practical example, let’s say you’re developing a text messaging application. When the user clicks your application’s icon, you probably want to present them with a screen that allows them to review recent conversations, or choose from a list of contacts. So that’s the default screen. Then when the user’s ready to compose a message, you have another screen in the same application handle that. This is important because it means that if you choose to allow integration with other applications, you can allow this message composition window to be loaded directly – for example from a contact directory application. Now when the user receives a message, you’ll want to alert them, but you most likely don’t want to have the full window come up for this. Instead, you can identify an incoming text message as being of interest to your application, and define that you want a simple notification to be called whenever the event in question occurs. So now you can play a sound and/or vibrate the handset, and display an icon with a message in the notification area at the top of the screen.
All this is possible because of subtype polymorphism. To put it simply, each component is defined as a component (activity, service, etc) and then is also given its specifics. Because each Activity is defined as being of the Activity class for example, the Android platform knows how to interact with it. Within its own operations, a component is given the freedom to do whatever it needs to do. However, each application is also run within its own virtual machine, so application A can’t mess with application B except in the ways B allows it to.
Like some other mobile platforms, Android transparently manages when programs actually get terminated, based on resource usage. This means when a user “closes” a program, it goes to the background, but may (or may not) continue to run for some time. Developers are also encouraged to keep track of the state of their applications if the user is expected to switch to other applications and back again to resume a task. Applications designed this way seem to remain running in the background indefinitely, even if they have actually been killed by the platform. Android is not the first platform to implement this, but it’s still worth mentioning.
After gaining experience developing on several major mobile platforms, and getting a sense for how they do things behind the scenes, I definitely intend to get an Android device for my personal cell phone. Right now I’m waiting to see what devices get released in the near future, and hoping that AT&T gets an HTC Android device that can compete with Sprint’s Evo.
If you found this overview of Google’s open-source Android platform helpful, check out http://developer.android.com/guide/topics/fundamentals.html – it’s where I got most of the information.