MobileAndroidUnderstanding Android Code Structure

Understanding Android Code Structure

Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Programming a hand-held device is significantly different from that of programming a PC. Apart from the base coding structure, the functionality of the device context is also different. For example, in a PC, the user is given full freedom to use the primitive window operation as they want. But, hand-held devices do not have that luxury to marionette at the whim of the user. Instead, these operations are differently abled, and many of them, however trivial it may seem in comparison with a PC, need conniving and direct intervention by the OS. This is partly because a PC is a full-blown device with virtually unlimited resources (such as processing power, memory, and power supply) at its disposal. Hand-held devices powered by the Android OS are somewhat economized to compaction, built to squeeze the maximum out of minimum resources. This directly impacts the structure of coding in Android. The article shall try to provide some key ideas of Java code structure and flow of control in developing an Android application.

Life-Cycle Phases

Android applications run through several phases, keeping in coherence with the complexity of the OS’s functioning. A high-level overview can be illustrated as follows.

Coding
Figure 1: An overview of life-cycle phases

The life-cycle of the application begins as soon as the user decides to open an application. The application is created and starts executing. At this stage, the application resumes control over the display along with its fair share of system memory and processing power. Now, suppose the user taps the screen to respond to an incoming call or switch to some other operation; the application collapses into a paused state. Once the user is done with the immediate operation and seeks to resume the application, it wakes up from its paused state then resumes to a running state. After the user decides to close down the application, it is stopped and destroyed (cleared from the system memory) subsequently. However, Android OS has the sole discretion to stop or destroy the execution of an application any time it deems fit. The reason of such gauche behavior can be immediate shortage resources, a long pause of a running application, user stopped interacting, and so forth. Once the process is stopped and destroyed, the cycle begins again with the creation of a new instance of the application.

A Glimpse into Garbage Collection

Android runs in a virtual machine, much like Java in JVM. Therefore, the janitor that works for memory cleaning is the garbage collector. However, there is a subtle difference in its working mechanism in comparison to Java. Android treats any activity component that goes out of visibility scope as half dead. That means the application may be in a paused state but the reference to visible components are suited for garbage collection. But, before garbage collection is done, the properties of the components’ state are saved for memory recovery at a later point in time. The strategy of garbage collection economizes high utilization of resources that spans across multiple processes resulting in an undeterred performance.

Activity Life-Cycle

The coding of the complexities of life-cycle phases is handled by default by Android without much programmer’s intervention. However, they can be overridden when needed. The code is segmented into parts called activities. Each activity has a life-cycle of its own. In Java terminology, these parts are nothing but methods, modularized to overcome complexity. The list of the methods that give a glimpse of the life-cycle is as follows.

  • onCreate: This method is the stepping stone of Android activity. All resources are initialized and made ready for use. This method is called only on creation of a new activity. If the instance of the application is not destroyed, this method will not be called. This method takes an argument called Bundle, which contains the saved application state.
  • onRestart: If the activity has been stopped, this method will be called before onStart. This situation occurs when the application is not in the foreground, interacting with the user.
  • onStart: Utilization of resources begins when this method is executed. The activity and its views are visible.
  • onResume: Though start and resume seems almost similar, closely onResume relates to a previously paused state of the application and basically relates to reload after executio,n such as its views becoming interactive with the user.
  • onPause: This method is called when another activity would be visible, while the current activity has stopped its interaction.
  • onStop: This method is called when the activity has stopped interaction and has no visibility. The application will be destroyed any time soon.
  • onDestroy: This method is called just before the activity is destroyed. All the dismantling operations are done here.

Observe that there is no running method or run method. The reason is that the running phase is not a state per se but a process. These methods are the means to manipulate the process of application execution.

Dip into the Code

A simple code to instrument the life-cycle process would make the picture clearer. This would be a console application, in the sense that the output would be viewed in LogCat viewer (the IDE used is Eclipse).

package org.mano.lifecycleapp;

import android.app.Activity;
import android.os.Bundle;
import android.util.Log;

public class MainActivity extends Activity {

   @Override
   protected void onCreate(Bundle savedInstanceState) {
      super.onCreate(savedInstanceState);
      setContentView(R.layout.activity_main);
      Log.i("MainActivity ", "from onCreate");
   }

   @Override
   protected void onRestart() {
      super.onRestart();
      Log.i("MainActivity ", "from onRestart");
   }

   @Override
   protected void onStart() {
      super.onStart();
      Log.i("MainActivity ", "from onStart");
   }

   @Override
   protected void onResume() {
      super.onResume();
      Log.i("MainActivity ", "from onResume");
   }

    @Override
   protected void onPause() {
      super.onPause();
      Log.i("MainActivity ", "from onPause");
   }

   @Override
   protected void onStop() {
      super.onStop();
      Log.i("MainActivity ", "from onStop");
   }

   @Override
   protected void onDestroy() {
      super.onDestroy();
      Log.i("MainActivity ", "from onDestroy");
   }
}

Conclusion

This is a rudimentary sketch of the flow of control of Java code in Android. There are quite a few other life-cycle methods, such as onSaveInstanceState, onRetainNonConfigurationInstance, onRestoreInstanceState, and some minor methods, such as onPostCreate and onPostResume, that are not mentioned in this article to keep things straight and simple. Also, we must keep in mind that the Android GUI and life-cycle handling go in unison to make an application. In fact, a complete Android application is the correct handling of life-cycle processes, the Activity object that contains the user interface and the Fragment object contained within the Activity instance.

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories