In Activity, I register receiver in onCreate and unregister it onDestroy. It should works fine if every onCreate is followed by onDestroy after the next onCreate. Otherwise, if onCreate is being called more than onDestroy, receiver is registered multiple time and the app mis-behaves.
So my questions are:
Is that ok I register receiver in onCreate and unregister it in onDestroy?
Is that onCreate is always followed by onDestroy before next onCreate?
onDestroy is not guaranteed to be called:
http://developer.android.com/reference/android/app/Activity.html#onDestroy%28%29
"
protected void onDestroy ()
Added in API level 1
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. You can distinguish between these two scenarios with the isFinishing() method.
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.
Derived classes must call through to the super class's implementation of this method. If they do not, an exception will be thrown.
"
You may also want to look at this thread:
Activity OnDestroy never called?
onDestroy is called when the activity is being destroyed. Or removed from the back stack, when ever the user doesn't want it or there is no possible way to get back to it. When your activity wants to receive a broadcast that is fine to do it how you are. If there are no dialogs appearing or notifications or toasts appearing after you receive that should be fine also, if you want to be on the real safe side and only have one activity receiving at a time, and only while the activity is visible move these to onResume and onPause.
You could probably some how unregister when another activity has been brought to the front and re-register after?
Related
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")
In my app, In an special situation I need to start an Activity and put it behind the current showing Activity, I mean if the current Activity, which is being shown by the user was closed, the user now can see the Activity which I just started. how to do that?
You cannot do this.
Activities will always start right away. You cannot manipulate the back stack in the way you want.
You would have to detect the activity closing and then start your new activity then.
You can implement your case by using 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. You can distinguish between these two scenarios with the isFinishing() method.
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.
Derived classes must call through to the super class's implementation of this method. If they do not, an exception will be thrown.
Source : http://developer.android.com
I would like to call onDestroy() at the end of my Activity.
Here is what i put :
#Override
protected void onDestroy()
{
unbindDrawables(findViewById(R.id.rootView));
super.onDestroy();
System.gc();
}
But, it is never called. Indeed, when I use auto completion, onDestroy never appear...
but onPause, onCreate, onStop .... yes
So do I miss something here ? I might be so stupid after all...
You should call finish().
onDestroy is called automatically, althought you should not rely on being called.
onDestroy():
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.
onDestroy may be not called
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.
Derived classes must call through to the super class's implementation
of this method. If they do not, an exception will be thrown.
Thanks everybody for your help.
I have now understand that onDestroy may not be called.
I don't know why, but now Eclipse prompt me the onDestroy method.
So it is called but not where i want to.
According to the android Activity Lifecycle, the only callback guaranteed to be called (if an activity ever leaves the Running state, which is typically expected) is onPause().
So, I must assume that there are scenarios in which it makes sense to implement onStop() and onDestroy() although they are not really guaranteed to be called.
I understand that onStop() should be implemented when it's possible for an activity to return to the Running state via the Stopped state (why would it do that instead of returning directly is a different question).
But the need for onDestroy(), when I can place all cleanup/state-saving into onPause(), is unclear to me.
Can you describe a real-app situation (i.e. not analogy to driving a car etc.) in which it would make sense to implement onDestroy()?
onDestroy will be called if you explicitly call finish(); yourself.
Your main activity calls startActivityForResult on a map activity.
Map activity with a LocationListener, the user clicks the map and selects say a local restaurant.
The activity then , sets up some extras to be sent back to your main activity, it then explicitly call's finish(); on itself and in the onDestroy kills the LocationListener and other variables you had invoked.
Just found this in the docs
onDestroy() = 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.
Can you describe a real-app situation
(i.e. not analogy to driving a car
etc.) in which it would make sense to
implement onDestroy()?
When you want to capture a configuration change. It's all in the SDK:
http://developer.android.com/reference/android/app/Activity.html