avatar

Derek Zeng

A programmer

Android dev note 1

by coderek

Coding android application is always an enjoyable process for me.

I find the following stuff intrigued me a lot.

Self-contained activity and task stack

As a mobile OS, android is very memory-conservative. In android, the basic building block of an app is an Activity. (there are 4 components consisting an application, but obviously Activity is most used and important component).

Activities are launched in sequence and their states are recorded down by the OS into a task stack. The task stack follows the rules below: (these are incomplete rules, but are those I think is important for newbie Android Developers)

  1. Multiple tasks can be held in the background at once. However, if the user is running many background tasks at the same time, the system might begin destroying background activities in order to recover memory, causing the activity states to be lost.

  2. If the user leaves a task for a long time, the system clears the task of all activities except the root activity.

The very important information here is that developer need to manage the Activity instance state data themselves. As a developer, we cannot assume the Activity object will be kept in memory forever. This is critical important when an Application has many activities depending on each other. A persistent way to store state data is often desired. We also need to be very clear on the App's life-cycle and initialize approriate data at approriate time.

I think this design is very brilliant. The OS throws the responsibility of memory management to developers. So developers need to be responsible and considerate when using the shared environment. If their app is not going to being used or seen, they need to prepare to save data and exit. OS just takes care of killing the app and recollect the memory. However, OS will preserve the visual state of the application, so user experience will be consistent. This amount of data kept be in OS is very minimum. And as the rule stated above, the task stack will also be cleared.

Local broadcast

In contrast to the system-wide Broadcast component, the local broadcast is a light-weight messaging mechanism that exists within individual application. It's very handy to use when there is something interesting happening within the application and you want other activities to know this event. In my application, I allow user to logout from menu at any activity. The usual way to implement an interface that act as callback function doesn't work well here. The situation is many to many relationship. There are many listeners and many firers.

I have to use broadcast here.

{% include_code android_note_1.java %}

Because I instantiate Receivers with AuthenticatedActivity which is parent class extended by many other activity. I can do instanceof inside the onReceive method to do actions specific to that child activity. Very handy.

Intent

It actually takes me quite a while to understand this concept as it's not known to me before. I like the concept of intent very much.

The design philosophy of Intent includes an idea of collaborative system. This also aligns with the well-known programming practice of "Do not repeat yourself". If some other app on the system can do this task, then let that app do it. The application itself doesn't have to re-invent the wheel. Doing it this way also gives users full flexibility on choosing his favorite application to complete the task.

It's also a concept that decouples the software system and let the activity focus on doing one task and do it good. This is a concept that is lacked in other popular mobile system like iOS.

-- EOF --

(End of article)