In my code i call finish on a activity but the onDestroy method of this activity not be called. would anyone can tell me why? when the onDestroy method will be called?
onDestroy() is called only when system is low on resources(memory, cpu time and so on) and makes a decision to kill your activity/application or when somebody calls finish() on your activity.
So, to test your code() you can make a test button, that will call finish() on your activity.
I believe you don't need to call all this stuff in onDestroy() until adap is not a critical resource. And even in that case android system has mechanisms to properly dispose them.
For More Details you can Refer Here
Related
I have a line of code that I should call after my activity is destroyed, so I override onDestroy() method and I call it inside. Like this:
#override
public void onDestroy(){
//my code here
super.onDestroy()
}
Now I noticed that the this line of code is not always executed when my activity finishes.
I read about this and some said don't depend on onDestroy() method to call something.
My question is I need to call the code from onDestroy() and I want it to always work. Any thoughts on this? And why onDestroy() is found in the first place if we cant depend on it to execute?
It is not a good idea to depend on onDestroy() for your cleanup works. It is better to perform these operation in onPause() or onStop(). These are the callback methods which the system calls whenever your activity goes out of view.
Now I noticed that the this line of code is not always executed when my activity finishes.
Either:
onDestroy() is called, or
You crashed with an unhandled exception, or
Your process was terminated (e.g., user revoked a runtime permission from Settings, Android needed RAM in a hurry)
I read about this and some said don't depend on onDestroy() method to call something.
Correct. onDestroy() is for cleanup of things assuming that your app is continuing to run normally. However, if your app is no longer running normally (you crashed) or your app is gone (process terminated), onDestroy() is not relevant.
I need to call the code from onDestroy() and I want it to always work. Any thoughts on this?
You will need to reconsider those two requirements, as they cannot both be true. Either initialize in onStart() and clean up in onStop(), or live with the fact that your cleanup code may not be called. Even the onStop() scenario is not completely guaranteed — in a multi-window environment, the user could revoke a runtime permission in Settings while your app is still visible — but we're getting into fairly unlikely scenarios.
There is no guarantee onDestroy it will ever be called, but i had rely on onPause to check if the Activity is finishing by calling if( isFinishing() ) // activity is about to finish yet this might not work properly.
I had rethink of my logic to not rely onDestroy at all.
boolean isFinishing ()
Check to see whether this activity is in the process of finishing,
either because you called finish() on it or someone else has requested
that it finished. This is often used in onPause() to determine whether
the activity is simply pausing or completely finishing.
https://developer.android.com/reference/android/app/Activity.html#isFinishing%28%29
These are the system calls for the method they will crash when they are called explicitly by the programmer...
Normally while calling finish(), we are expected to call onPause(), onStop() and onDestroy(). Most of the times it is working fine. But sometimes finish() only calls onPause() i.e. onStop() and onDestroy() are not calling sometimes. Why it is like so? What happens finish() for not calling onStop() and onDestroy(). I have put log in finish() method Activity.java. But in working and non working conditions logs are same. Please help.
According to developer docs, onStop() and onDestroy() are Killable:
Note the "Killable" column in the above table -- for those methods that are marked as being killable, after that method returns the process hosting the activity may killed by the system at any time without another line of its code being executed. Because of this, you should use the onPause() method to write any persistent data (such as user edits) to storage.
So onStop() and onDestroy() may or maynot be called, it depends on how system handle it.
When calling finish() on an activity, the method onDestroy() is executed this method can do things like:
Dismiss any dialogs the activity was managing.
Close any cursors the activity was managing.
Close any open search dialog
Also, onDestroy() isn't a destructor. It doesn't actually destroy the object. It's just a method that's called based on a certain state. So your instance is still alive and very well* after the superclass's onDestroy() runs and returns.Android keeps processes around in case the user wants to restart the app, this makes the startup phase faster. The process will not be doing anything and if memory needs to be reclaimed, the process will be killed
finish() Call this when your activity is done and should be closed. The ActivityResult is propagated back to whoever launched you via onActivityResult().
finish()
I always think finish() will fire onDestory() immediately.But in 4.3 it seems not the truth.
I just want to know in which condition it'll happend ?
sorry,I can't put all my code on here.
It confused me a few hours,and I can't find any useful info about it.
From the docs:
onPause() is the last method that's guaranteed to be called before the process can be killed—if the system must recover memory in an emergency, then onStop() and onDestroy() might not be called. Therefore, you should use onPause() to write crucial persistent data (such as user edits) to storage.
It doesn't matter if you used finish() or the system killed your Activity on its own. If the system "wants" to recover memory, there's no guarantee that onDestroy() or onStop() will be called.
First, this answer assumes that you are referring to Android's Activity class and its finish() method and onDestroy() lifecycle method.
Second, it depends upon your definition of "sure":
Your process could be terminated in between finish() and onDestroy(), for reasons independent of whatever is triggering the call to finish()
A device manufacturer or ROM modder could introduce some screwy change that would break the connection between finish() and onDestroy()
The battery could go dead in between finish() and onDestroy()
Etc.
No, there is no guarantee onDestroy() will be called.
The same goes for onStop()
What you want instead is onPause()
This is true for all versions of Android, going back to 1.0 to the very latest. The Activity lifecycle can be initially very confusing for beginners. But it's not the beginner's fault, it's the fault of the framework designers.
Another mistake beginners make is to assume that onResume() is about resuming the Activity, when in fact it's the UI thread that is resuming while it is in its Activity. This is another point that the documentation goes over and over again, but really, it would have been a lot simpler if the android team had called that method something less ambiguous to begin with.
according to: http://developer.android.com/reference/android/app/Activity.html
Will allways be 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.
When I start my android-activity first onCreate() is called, then onResume().
When I then press the back-button to return to the home-screen and tap the app-icon again, first onCreate() is called, then onResume() and then onDestroy().
My app is still active then, but doing some action result in error since onDestroy() sets a few members to null.
Why is that?
Update: When I wait 30 seconds after pressing back everything works fine. I'm not doing anything heavy in onDestroy except setting a few variables to null and .interrupt()ing a background-thread.
Figured this out by myself. My understanding of what an Activity is was flawed. Of course Android calls onDestroy() on the old Activity instance, which can happen several seconds after the new one has been constructed.
onDestroy gets called because, by default, pressing back key results in your activity calling finish() which initiates the destroying of the activity which calls onDestroy().
To prevent doing some action in case the activity is being destroyed do like this:
if(!isFinishing()) {
// do your action here
}
isFinishing is a method of the Activity.
are you doing some heavy operations in onDestroy(). I think your activity view is destroyed, but not the activity object. And you tap on the App icon even before the previous Activity object is actually destroyed.
I think there is something in addition to what you are describing. Android doesn't just keep activity from being destroyed, something MUST be happening on the main thread.
The symptoms sound exactly as if you had either:
a service doing a longish HTTP or database operation. Are you sure there are no suxg things?
another thread (perhaps managed by an AsyncTask?) calling a synchronized method
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.