Mobile Java: The Next Generation

Figure 2 is the lifecycle for a MIDP application (a "MIDlet"). A typical mobile phone then might have a black-and-white 96×54 pixel screen, with 128 KB of RAM and 256 KB of nonvolatile memory. In such a constrained platform, only one MIDlet executes at a time. A MIDlet spends most of its lifecycle shuttling between two statesactive, where it does work, and paused, where the phone switches the MIDlet out so that it can handle a call. However, a MIDlet isn't completely inactive while in the paused state. It can use timers to schedule work, and create background threads to execute tasks that don't require the UI.

[Click image to view at full size]

Figure 2: Lifecycle for a MIDP application.

One problem when writing a MIDlet is that its startApp() method is called every time the phone returns it to the active state. This complicates the MIDlet's design because you often place the initialization code in the startApp() method. The reason for locating code there (rather than in the MIDlet's constructor) is that the specification requires that if an error occurs in the constructor's code, the stack throws a fatal exception. This behavior rules out the possibility of recovering gracefully or displaying messages that could tell users what went wrong. Many MIDlet applications therefore set a Boolean flag so that for subsequent calls of startApp(), the initialization code is bypassed. Another complication is that there's no set mechanism to preserve the state of a complex MIDlet when it is paused. You must save the values of key variables into its RMS yourself when pauseApp() is invoked, then restore these values when the MIDlet becomes active.

Figure 3 is the lifecycle of an Android application, termed an "Activity." The diagram reflects the more powerful capabilities of the hardware platform. Nowadays, high-end phones often have 1 GB of RAM and up to 16 GB of Flash memory. They have larger color screens (240×320, which are now more common), along with faster processors and features like cameras and GPS. The extra states in an Activity's lifecycle not only address some limitations in the MIDP specification, but also enable support for the concurrent execution of Activities.

[Click image to view at full size]

Figure 3: Lifecycle of an Android application.

An Activity's lifecycle starts with a call to onCreate(), which handles set-up chores and static global initializations. The onStart() method begins the Activity's visible lifetime, where it presents its UI window on-screen. Invoking onResume() has the Activity begin interactions with users. The application is in the foreground and active state. If another application must come to the foreground, Android calls the onFreeze() method to save the Activity's state. To this end, Android provides support methods that let you easily store and retrieve various data elements in objects called "Bundles." After you save the Activity's context, onPause() is called. The Activity stops any animations, commits its variables to persistent storage, and enters the paused state. At this point, the other Activity's UI window can come to the foreground and interact with users.

What happens to the Activity next depends on several things. If the foreground application only partially obscures the screen, the Activity hovers in the paused state, as users might bring it back to the foreground at any moment. If the foreground application's window completely covers the screen, onStop() is called and the Activity enters the stopped state. This state is similar to the paused state, except that for low-memory situations, Android might dispose of its window. If the Activity returns to the foreground later, calls to onRestart() and onStart() restore the window and UI. In very low memory situations, Android might kill the Activity to release memory. If users select the Activity again, it must be completely restarted and its context restored from saved Bundles. As Figure 3 illustrates, the additional methods and states let the Activity cleanly resume execution whether it's been paused, stopped, or destroyed.

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task.
However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Video

This month's Dr. Dobb's Journal

This month,
Dr. Dobb's Journal is devoted to mobile programming. We introduce you to Apple's new Swift programming language, discuss the perils of being the third-most-popular mobile platform, revisit SQLite on Android
, and much more!