Phases Of Android App Development Life Cycle
The recent research on android, security issues have been dominant and are given more emphasis. Yet, there is a scanted knowledge of the android application features and implications. This detailed explanation of the android application life cycle will give android research a new dimension. People just think about the mobile interface design only, which is just the front face of the whole system. Android is an operating system that is useful in various tasks. An application is one or more activities plus a Linux process to contain them. After opening an android application, all the various phases it undergoes is the life cycle. Android applications can exist even if its process is not followed.
To begin, there are the core components which are the building blocks of developing an android application. Core components are ones which comprise an application.
This is because the activity life cycle is not tied to the process life cycle. A unique and important characteristic of android applications is that the lifespan of a process is not controlled by the application that is running. Processes are disposable containers for activities. Internally, each user interface screen is represented by an Activity class (Cai & Ryder, 2017). Every activity has a life cycle of its own. A life cycle of an activity is the steps that the activity goes through from the start state to the exit state. The purpose of the life cycle is to guarantee the dependability and performance of the generated applications.
To make sure that Android applications function properly, this completely applies. Phases for apps include prototype, alpha, beta, and release candidate. Firms like XAM that specialize in app development tend to pay meticulous attention to these phases, ensuring each step aligns with the Android application life cycle. Although different people define things differently, they all fit into the same pattern: Prototype – The app is still in the proof-of-concept phase and only has basic functionality or a few functioning components. There are several bugs present.
Alpha – Most of the basic features are code-complete (built, but not fully tested). There are still significant problems, and auxiliary functions might not be available. Beta – Most of the functionality is now complete, and some minor testing and issue fixes have been made. It’s possible that the system’s critical weaknesses are still present. Release candidate: The mobile apps security analysis has been done, and every functionality has been tested. Barring any new concerns, the program is prepared for public release.
a) Activity
An activity represents the Graphical User Interface of the application. This is the main page of the application when the user launches an app. This activity transmits data and control to other activities through intents. This is applicable if an app has multiple activities.
b) Broadcast provider
This is a dedicated server that is used to send alerts or messages for instance low battery.
They usually don’t display the user interface. It uses notification mechanisms to request user authentication.
c) Services
Service may run in the background without the knowledge of the user. Applications can use their own services or use those of others.
d) Content providers
A data-centric system that makes a database available for a long time to any number of apps.
All components according to:
The beginning – how they are instantiated.
End – when instances are terminated.
Sequence – or between states, some components may be active or inactive.
Android applications are various activities. Additionally, as opposed to other development paradigms, the main method does not launch an app in android. Instead, each application has a specific sequence of callback methods that start or end an activity. There are many activities in the android application. Activities have various methods and states. These activities have been detailed below:
Oncreate() method
This is the first method to be called when activity is first created. An activity does all its initial setup of “global” state in onCreate(). It can be used to perform one-time initialization such as creating the user interface. This is where normal static set up is done for example creating views and binding data to lists. All activities must implement onCreate() method to do the initial setup when the object is first instantiated. This method is passed a Bundle object containing the activity’s previous state, if that state was captured – onCreate(Bundle). Oncreate() is always followed by onStart().
On start() method
The second phase is the onStart() Method which is called just before the activity becomes visible to the user or displayed to the user (Vithani, & Kumar, 2014). The method is executed when the activity starts running. It is followed by onResume() if the activity comes to the foreground, or onStop() if it becomes hidden.
OnResume() method
OnResume() method is called when an activity result or a new intent is delivered.
At this point the activity is at the top of the activity stack, with user input going to it. It is a good place to start animations and music.
This method is always followed by onPause(). This method is called when the device goes to sleep or when a new activity is started.
It runs when the activity is about to go into the background, usually because another activity has been launched in front of it. The method is typically used to commit unsaved changes to persistent data, stop animations and other things that may be consuming CPU.
OnPause() method
OnPause() Method is followed either by onResume() if the activity returns back to the front, or by onStop() if it becomes invisible to the user. The activity in this state is killable (destroyable) by the system.
OnStop() method
This method is called when the activity is no longer visible to the user and it won’t be needed for a while. This may happen because it is being destroyed, or because
another activity (either an existing one or a new one) has been resumed and is covering it. The method is followed either by onRestart() if the activity is coming back to interact with the user, or by onDestroy() if this activity is going away. The activity in this state is killable (Destroyable) by the system. If memory is tight, onStop( ) may never be called (the system may simply terminate the current process).
OnResstart() method
OnRestart() method is called after the activity has been stopped, just before being started again. If this method is called, it indicates that the activity is being redisplayed to the user from a stopped state
onRestart() method is always followed by onStart().
OnDestroy() method
OnDestroy() method is called just before the activity is destroyed. It is the final call that the activity will receive. It could be called either because the activity is finishing or because the system is temporarily destroying this instance of the activity to save space. The activity in this state is killable (Destroyable) by the system. If memory is tight, onDestroy( ) may never be called (the system may simply terminate your process). To determine which processes should be destroyed, when on low memory, every application is grouped in a hierarchy according to their importance. The components running in the application and the state of the components are considered when determining their importance. The most important types of processes are given priority.
The processes are:
1) Foreground process
This is required to handle applications being run by the user. Different applications have various ways of making a process to be considered foreground. The following conditions are considered:
- An activity is being run on the screen that the user is interacting with(OnResume method).
- If the activity has a broadcast receiver active.
- In case it has a service that is executing blocks.
There will only be a few processes remaining and these are destroyed when the memory is too low.
2) Visible process
This is a process that the user is aware of happening. If this process is terminated, it will have a negative impact on the user experience of the user. This is why developers often pay the most attention to this part while developing an app. And possibly user experience is the reason why some apps such as westfield plus tend to gain more popularity over others.
During this time, the user can see the activity on screen, though it may not be in the foreground and interacting with the user. The onStart() and onStop() methods can be called multiple times, as the activity alternates between being visible and hidden to the user. Between these two methods, you can maintain resources that are needed to show the activity to the user.
A visible process is one that is:
- Visible to the user but not in the foreground.
- Services hosted using a particular characteristic for example a live wallpaper.
- Service running as a foreground.
The visible process is considered to be extremely important hence they cannot be terminated unless it is to keep the foreground processes running. The services here are less bounded than those in foreground.
3) Service process
The user cannot see these processes but they are essential services that keep processes running. Such processes are required unless there is no space for foreground and visible processes. Services that run for a long period of time are demoted because they could potentially use excessive resources (Backes, Bugiel, Derr, McDaniel Octeau & Weisgerber, 2016).
4) Cached process
A cached process is one that is not needed and the system is free to destroy this process when memory is needed. An efficient system has multiple cached processes to enable processes to run smoothly.
Other activities include :
OnSaveInstanceState(Bundle):
This method is called to allow the activity to save per-instance state, such as a cursor position within a text field.
Usually you won’t need to override it because the default implementation saves the state for all your user interface controls automatically.
OnRestoreInstanceState(Bundle)
This is called when the activity is being reinitialized from a state previously saved by the onSave-InstanceState.
OnSave-InstanceState( ) method.
The default implementation restores the state of user interface. The visible lifetime of an activity happens between a call to onStart() until a corresponding call to onStop(). During this time, the user can see the activity on screen, though it may not be in the foreground and interacting with the user.
Onstart() and onstop methods
The onStart() and onStop() methods can be called multiple times, as the activity alternates between being visible and hidden to the user.
Between these two methods, you can maintain resources that are needed to show the activity to the user.
The foreground lifetime of an activity happens between a call to onResume() until a corresponding call to onPause().
During this time, the activity is in front of all other activities on screen and is interacting with the user.
According to Zein, Salleh & Grundy, an activity can frequently transition between the resumed and paused states. During its lifetime, each activity of an Android program can be in one of the following states :
- New Activity state
- Active or running state
- Paused activity
- Stopped activity
- Destroyed activity
New Activity state
A new activity that is being too loaded to memory (i.e. allocated memory).
Active or running state
This state is in the foreground of the screen (at the top of the activity stack for the current task). This is the activity that is the focus for the user’s actions.
Paused activity state
Paused activity has lost focus but is visible to the user. If another activity lies on top of it and that new activity either is transparent or doesn’t cover the full screen. A paused activity is completely alive (it maintains all state and member information and remains attached to the window manager), but can be killed by the system in extreme low memory situations (Neamtiu, 2020).
Stopped activity state
Stopped activity is completely obscured by another activity.
It still retains all state and member information.
However, it is no longer visible to the user so its window is hidden and it will often be killed by the system when memory is needed elsewhere.
Destroyed activity state
Destroyed activity is killed (i.e. dropped) activity to reclaim memory. Activity that is no longer in the activity stack. The Killable States are states that are followed by activity termination (destroyed state). They include paused state and stopped state. On SaveInstanceState(Bundle) method is called to allow the activity to save per-instance state, such as a cursor position within a text field. Usually, you won’t need to override it because the default implementation saves the state for all your user interface controls automatically.
In conclusion, those are the phases and the various states of an android application life cycle. When the user interacts with the app, the activities transit through specific stages in the life cycle. The user is alerted by the application through a number of callbacks when any state has altered. For example, when the system has started, stopped, resumed or terminated an activity. It is very critical to have a basic understanding of the life cycle of an android application life cycle, before starting out. The methods, states and process in an android application life cycle should be followed to avoid inconveniences.
