I have an Android existential question:
Does an App's onDestroy() get called when I kill it by swiping it out of the task manager?
If not... how can I detect a "killing" swiping event on the app, and do some final stuff beore it dies?
onDestroy()
Perform any final cleanup before an 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.
Note: do not count on this method being called as a place for saving data!
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.
Instead, rely on onPause() and onStop() to do any final work before your app goes out of view.
Is your main concern the "swiping" event or just saving data? :)
Related
I wanted to ask about the activity's lifecycle.
If an activity is going to the background, or the user pressed the home button so the application itself is not visible anymore, the onStop() is called, but not always destroyed.
1) when the above happens, what actually happens to the activity? Does it move to the backstack? or something else?
2) specifically related to the first question - when will the onDestroy() method be invoked in a case where the activity has already stopped, but the onDestroy() wasn't yet called at that moment of stopping?
3) generally about onDestory() - I know onDestroy() is called when the system doesn't have enough resources anymore, or when Android is destroying a portrait/landscape layout in order to load the other one. When else can it be called?
1) when the above happens, what actually happens to the activity? Does it move to the backstack? or something else?
Suppose you have pressed the home button and the current application will be moved to the background state, now the object of the current app activity will be stored in the TASK and this task has all the objects of the activity of the application. So this TASK will be in the memory and the Android System will kill this task only when there is shortage of the memory or any user manually kills the app or finish() method is called.
2) specifically related to the first question - when will the onDestroy() method be invoked in a case where the activity has already stopped, but the onDestroy() wasn't yet called at that moment of stopping?
onDestroy() will only be called in the following possibilities
User manually kills the application.
Android System will reclaim the memory where there is shortage.
When finish() is called in the code itself.
Hope it helps.
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 have implemented ActivityLifecycleCallbacks in a private class inside my Application class.
If Home button or Back button is used, lifecycle's onStop() and onPause() methods are getting called. If I kill the activity by swiping out from background, onDestroy() method is not getting called. It gets called when I start my activity next time. I am using moveTaskToBack(true) in case of Back press.
What must be the issue and which lifecycle method should get called when we swipe out from background?
From the documentation of onDestroy():
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.
Such a situation is swiping the app out of the recent tasks list.
Check out this answer on how to get notified when the app is getting swiped out of Recents.
I remember reading a similar question on StackOverflow. Here was the top answer:
Handle exit application from Task Manager
Handle exit application from Task Manager
Unfortunately there isn't a good answer for handling this situation. If the app is force-killed, onDestroy method isn't necessarily called. According to the documentation.
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.
If you can, clean up in the onPause() method. In order for the user to get to that screen to kill the app, it has to have been backgrounded and thus onPause() would be called. (see documentation)
swiping app from back ground i.e. clearing from recents causes the whole process and task to be killed and that time onDestroy() may not be called , when user presses back from an activity then only that activity is killed not the process.
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")
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.