Events in the life cycle of Android activities

life cycle android

When working with Android not forget that most are mobile devices, so that some activities are more important than others (for some users may be more important to take a call to play Angry Birds). And since they are phone, it is obvious that the devices have less RAM than a PC or laptop.



It is therefore vital to understand how Android manages its memory and can even sacrifice some activities in order to offer the resources you need an application that is interacting at a given time with the user. So do not always work to assume that an application will run until you have completed some process.
Today we review the various states and callbacks that make up the life cycle of an activity and how we can manipulate and work with them properly in your applications.
An activity usually works in one of four states at some point:
Active: When the activity has been initiated by the user is currently running and is in the foreground.
Pause: When the activity has been initiated by the user is currently running and visible, but a notice or something else is superimposed on the screen somewhere. During this state, the user can view activity, but you can not interact with it.
Stop: When the activity has been initiated by the user, is still running but is hidden by other activities that have been released. When an activity is in this state, the activity is not able to show meaningful information to the user directly, but may do so by using notifications.
Completed: The activity enters this state either because they never started (scenario that occurs after the user reboots the phone) or because the system was completed by the lack of available memory.
Android uses the methods explained in this post that talks about the life cycle of an activity for the activity to make the transitions between the four states just mentioned. Some of these transactions may result in multiple calls to a business, so it is important to decide which events require more attention than others. Another fact you should not forget is that when using these methods, we invoke the superclass version, that is, use the @ Override sentence before filing for our activities and otherwise, Android can throw an exception.
onCreate () and OnDestroy ()
In the tutorials and examples that have followed so far, we have implemented the method onCreate () in all major activities, which are only a subclass of Activity. This method is called three times:
When is the first time that an activity is called (eg after rebooting the phone), onCreate () is invoked with a parameter of type null.
If an activity has been running and at some point has been completed, onCreate () is invoked with an instance of Bundle through onSaveInstanceState method () as parameter.
If an activity has been running and we have set our activity to load different resources based on different states of a device (eg when switching from portrait to landscape position), what will happen is that the activity will be created and onCreate ( ) will be called.
At this point is when we initialize the user interface and run all you need to be done only once, regardless of how the application when the user starts to interact with it.
At the other end of the life cycle is OnDestroy () is called when the activity is being closed (in this context we understand it more as a shutdown), either because the activity invoked the method finish () or because the system needs more RAM and has therefore decided to terminate the application prematurely. Generally, OnDestroy () is also used for a clean release resources that invoke in onCreate ().
OnStart (), onRestart () and OnStop ()
An activity can be found in the foreground being the first was launched by the user or the user has called again after it has been hidden for making use of some other application. In either of these two cases occupy the OnStart method ().
OnRestart method () is called for cases in which an activity was arrested and is now rebooting.
By contrast, OnStop () is called when the activity is about to be stopped.
onPause () and onResume ()
OnResume method () is called just before an activity pass to the fore, having been released initially, after being restarted from a stopped state (forced by the system or not) or after it has missing a pop-up dialog. This method is useful to refresh the user interface based on actions that may have passed since the last time the user saw the activity. A good example is a Twitter client that we take a backseat to address a notice of chat and when we pass to the fore already uploaded new tweets.
Conversely, any event that causes the user leaves our launch another activity will result in a call to the method onPause (). In these cases, we must get rid of everything done in the method onResume (), how to stop background processes, releasing any access to any resources of the phone that was acquired by the application.
Once onPause () is called, Android may end up with our business whenever it sees fit.
Conclusions
In order to know in detail what we can now use each of these methods is to not only conceive the ebb and flow of activities as a whim of the memory requirements have Android at some point.
As all this happens without the user noticing, we have to design applications so that if a user was typing a tweet and you get an SMS interrupting this task, you can re-open your Twitter client and find the incomplete text up where it left off instead of being surprised to have to rewrite it from scratch.
To achieve this, activities must be able to save the status of each of the states of the life cycle by passing, in a quick and "cheap" in terms of resources consumed. Needless to emphasize that given the environment in which applications are running makes them stay in a state that can be closed at any time without notice, must be prepared for everything.
As mentioned above, onSaveInstanceState (), will help us to keep the data presented before an activity to be paused to restart the user can be displayed as it was in the earlier time. The implementation of this method must be rapid, it is only to provide information to the Bundle and go.
I hope that this theoretical part will help you understand a better way of life cycle of an activity, in a following tutorial will try to implement all that we've seen so you know how you have to implement each of the methods and still see the importance of taking in a real environment in which the user interacts with many applications at once.