In the Activity Lifecycle diagram there's an arrow from 'onStop' to 'App process killed' to 'onCreate'. I've always wondered, and now I'm going to give a small talk on fragments; How is it possible for onCreate to receive the bundle from onStop if the whole app process is destroyed? Does the system keep track of killed apps and their activity bundles? I think that would be how it would do it because at that point the killed application would have zero memory allocated to it.
Also, from the last paragraph on the page Managing the Activity Lifecycle>Starting an Activity, "The system calls onDestroy() after it has already called onPause() and onStop() in all situations except one:...' And that one situation isn't stated as being low on memory. This makes me think that the arrow should never go from onStop to onCreate because of 'Apps with higher priority need memory'. Is this a typo or am I reading it wrong? I assume I'm reading it wrong because of the 'Killable?' column in 'in general the movement through an activity's lifecycle looks like this:' chart.
One of these has to be wrong either the arrow in the activity lifecycle chart or the "The system calls onDestroy() after it has already called onPause() and onStop() in all situations except one:..." statement. Hopefully I'm reading out of context.
How is it possible for onCreate to receive the bundle from onStop if the whole app process is destroyed?
It doesn't "receive the bundle from onStop", insofar as onStop() has nothing to do with a Bundle. The Bundle delivered to onCreate() and onRestoreInstanceState() contains the data put in an earlier Bundle by onSaveInstanceState(). The content of that Bundle is passed across process boundaries to a core OS process that manages the state of outstanding activities and their tasks. That content is passed back to the fresh process for your app if and when it is relevant.
Does the system keep track of killed apps and their activity bundles?
The OS keeps track of outstanding tasks. For a while (~30 minutes since last use), it keeps track of the instance state Bundle for the activities on the task.
The system calls onDestroy() after it has already called onPause() and onStop() in all situations except one
There is more than one situation in which onDestroy() is not called. Terminating the process due to low memory conditions may or may not result in onDestroy() being called, depending on the urgency of the need for system RAM.
It is very possible for onCreate to be called after onStop(). You pass bundles using onSaveInstanceState() which is called anytime the activity or fragment pauses or stops. Say you have an activity and press home. OnStop and onSaveInstanceState are both called. In onSaveInstanceState you save your bundle to save the state of the app. The app is then killed because it was in the background for too long. Then when you open the app back up the bundle from onSaveInstanceState is passed to oncreate in the SavedInstanceState parameter when ever it gets recreated. See the official docs for more https://developer.android.com/training/basics/activity-lifecycle/recreating.html
Related
When an Activity goes in pause state, an instance of it remains in the Activity stack that is managed by operating system. And I know after a while, it destroys the instance. Now my question is whether the onDestroy() method is called when operating system destroys the Activity instance after a long while?
Like if I put a Toast inside onDestroy() method, that will be shown when the Activity instance gets destroyed by OS? (I know it will be shown by pressing back button).
The nature of this question makes it hard to test because sometimes it takes a day or more for OS in order to destroy an Activity instance in stack.
There is no guarantee that it will be called. You can see Activity#onDestroy for that.
Note: do not count on this method being called as a place for saving data! For example, if an activity is editing data in a content provider, those edits should be committed in either onPause() or onSaveInstanceState(Bundle), not here. This method is usually implemented to free resources like threads that are associated with an activity, so that a destroyed activity does not leave such things around while the rest of its application is still running. There are situations where the system will simply kill the activity's hosting process without calling this method (or any others) in it, so it should not be used to do things that are intended to remain around after the process goes away.
By simply killing it could be e.g. a System.exit call or something similar where it skips the lifecycle hooks.
I want to use Application.ActivityLifecycleCallbacks to monitor how many activities are there in the back-stack. Can I increment/decrement counter in onCreate/onDestroy to handle this?
onDestroy is NOT guaranteed to be called every time an activity is destroyed.
If the user clicks back to destroy it, onDestroy will be called.
If the user swipes the application from the recent app menu, onDestroy will NOT be called.
If the application crashes, it's undetermined if it'll be called (from my experience, it isn't called).
Is onDestroy always called when android destroys activity to save memory?
Yes
Documentation:
The final call you receive before your activity is destroyed. This can happen either because the activity is finishing (someone called finish() on it, or because the system is temporarily destroying this instance of the activity to save space. You can distinguish between these two scenarios with the isFinishing() method.
I want to use Application.ActivityLifecycleCallbacks to monitor how
many activities are there in the back-stack. Can I increment/decrement
counter in onCreate/onDestroy to handle this?
Better to counter in the onStart() and onStop() methods, onCreate() doesn't guarantee visibility. For example if somehow something stopped onStart() from happening.
onDestroy() is the final method that is called on an Activity instance before it’s destroyed and completely removed from memory. In extreme situations Android may kill the application process that is hosting the Activity, which will result in OnDestroy not being invoked. Apparently most of the Activities will not implement this method because most clean up and shut down has been done in the OnPause and OnStop methods.
For more details please visit Android Developers Portal.
(https://developer.android.com/reference/android/app/Activity.html "Android Developers")
I've read several posts that describe the difference between onStart() and onResume(): onStart() is called when the activity becomes visible, onResume() is called when the activity is ready for interaction from the user. fine.
I've always just added code to onPause() and onResume(), and never bothered with onStart() and onStop().
Can anyone give some concrete examples of what you might do in onStart(), vs. onResume()? Same goes for onStop() and onPause(), how is onStop() useful? I must be missing something fundamental here.
onStop() will (for example) be called when you leave the activity for some other activity (edit: almost. see commonswares comment about dialog themed activities).
For example if you use startActivity() in activity A to start activity B. When you press back in activity B you will return to activity A and onStart will be called.
This differs from some of the reasons onPause might be called without onStop being called. If for example the screen times out or you press the standy button onPause will be called, but probably not onStop (depending on memory available and whatnot), so it is a "lighter pause". onStop will be probably be called eventually even in this case, but not immediately.
Ok, but what's the use
Often there is no specific use, but there might be. Since your activities will keep its memory state on the stack even after you start some other activity, that stack will increase with the number of activities started (height of the stack).
This can lead to large memory usage in some applications. After a while the framework will kick in and kill some activities on the stack, but this is rather blunt and will probably mean a lot of states to be retained when returning.
So an example use for onStart/onStop is if you want to release some state when leaving an activity for another and recreate it when you get back.
I have used it to set listadapters to null, empty image caches and similar (in very specific applications). If you want to free the memory used by visible views in a listadapter you can recreate it in onstart and let the views be picked up by the gc. This will increase the likelyhood that the rest of the memory state of the activity will live on.
Some resources can be deemed good enough to save while the activity instance is alive and some only when it is on the front of the stack. It is up to you to decide what is best in your application and the granularity of create/start/resume gives you that.
onStart() works after onCreate() ended its task.
It's a good place to put a broadcastReceiver or initialize some state about the UI that should display consistently anytime the user comes back to this activity.
onResume() works when you come back to your Intent or Activity by pressing the back button. So onPause will be called every time a different activity comes to the foreground.
i think that your question is pretty explained here on the doc : read about the Activity Life Cycle
I think my ideas on activity lifecycle and bundles
are a little confused,can you help me?
Let's suppose the user opens activity A from home screen,
activity A "calls" activity B which fills the screen.
On this event onSaveInstanceState() is called on activity A then onPause() and onStop().
Since there are too many apps currently running on the system,
andorid decides to kill the process hosting activity A.
When the user navigates back to activity A,onCreate() is called an we can
use the bundle ( setted during the last call of onSaveInstaceStae() ) to restore the state.
then onStart(),onRestoreInsanceState()
and onResume() are called,
am I right?
Then lets suppose the user presses back key to exit from activity A
onPause(),onStop() and onDestory() are called in sequence on activity A (the call of onDestroy() could be postponed though)
onSaveInsanceState() should not be called in this scenario.
When the user opens again activity A later on then the bundle
passed to onCreate() is null,right?
Now Suppose the user rotates screen
onSaveInsanceState() ,OnPause() ,OnStop(), OnDestroy() are called
then onCreate() with bundle setted by the last call to onSaveInsanceState(),
and then onStart(), and onRestore().
am I right?
My guess is that:
when the user creates an ativity,the bundle passed to onCreate() is always null and onRestoreState() is never called,but when the system creates it , for instance when it killed the activity because of low memory or because of a rotation event,the bundle passed is the one setted by the last call of onSaveInstanceState().
Is my guess right?
thanks and sorry for my poor english.
P.S. : I think onRestoreInstanceState() is passed the same bundle is passed onCreate() but typically state is restored using onCreate().
Interesting question - never thought about it.
Take a look at the documentation, onCreate() and onSaveInstanceState().
This answers at least your question what Bundle will be supplied to onCreate().
Unfortunately there is no exact definition on which events onSaveInstanceState() is called, but I guess it is called by default in all relevant situations (whatever they may be...), but you can find out for some situations (e.g. rotating the screen) by putting a Log.i() to LogCat.
onRestoreInstanceState() is passed the same bundle is passed onCreate() is right, and the system restart the activity by call onCreate() and also call onRestoreInstanceState(),the bundle will be null if get from onCreate() when the activity first started.
Since there are too many apps currently running on the system,
andorid decides to kill the process hosting activity A.
This is a very common situation. Furthermore - you can emulate this action using developers option.
In this case each activity, that was move into background, will be automatically destroyed.
About Bundle in OnCreate .
I can get from my memory only two cases when OnCreate will be called with non-null Bundle. First - described above. Second case - screen rotation.
When you launch app Android calles
onCreate
onStart
onResume
After that lets doing screen rotation. Android will call
onSaveInstanceState
onPause
onStop
onDestroy
onCreate
onStart
onRestoreInstanceState
onResume
The more information you can find on topic about recreating
Looking at the Activity Life Cycle diagram, I notice that onPause() and onStop() can both lead to the "process" being killed. This would require onCreate() to be called when the user wants to resume their application. The point being that onStop() is not necessarily called, nor is onDestroy(), but that onPause() may be the only event that the Activity may see. This being the case, onPause() must handle saving the application status so that the user can return back to it later, regardless of whether onStop() is called or not.
I can see onDestroy() being used to clean up Activity specific resources that would naturally be eliminated in a process kill action. Is there anything else that onDestroy() would be good for?
And what would onStop() be good for? Why would I want to override it for?
If I got your question right: It depends what you want to do with your application. Let's say you are programming application that uses GPS. In the onStop() which is called when the activity is no longer visible to the user, you can remove these requests. Or you can stop the some service if your application is running any. Or you can save preferences (not recommended, do it in onPause() instead), or you can close permanent connection to a server.....If I think of anything else, I'll add more...
If you have read the doc further, you'll see following:
Saving activity state
The introduction to Managing the Activity Lifecycle briefly mentions
that when an activity is paused or stopped, the state of the activity
is retained. This is true because the Activity object is still held in
memory when it is paused or stopped—all information about its members
and current state is still alive. Thus, any changes the user made
within the activity are retained in memory, so that when the activity
returns to the foreground (when it "resumes"), those changes are still
there.
However, when the system destroys an activity in order to recover
memory, the Activity object is destroyed, so the system cannot simply
resume it with its state intact. Instead, the system must recreate the
Activity object if the user navigates back to it. Yet, the user is
unaware that the system destroyed the activity and recreated it and,
thus, probably expects the activity to be exactly as it was. In this
situation, you can ensure that important information about the
activity state is preserved by implementing an additional callback
method that allows you to save information about the state of your
activity and then restore it when the the system recreates the
activity.
Summary: After completing onStop() Activity object is still alive in memory. And this will help the system to restore the activity.
Very basic example: consider you are showing your activity to user, and suddenly your friend calls you! Rest you can understand..
So now it it up to you that, which are the resources/objects/connections should be released on which event.
Another example would be to register and unregister a broadcast receiver.
Note that usually these things are placed in onResume and onPause, the difference is subtle though, onResume/onPause are called when the activity gets placed behind another activity, onStart/onStop are called when the activity is no longer visible in the screen.