I am attempting to save keys to SharedPreferences during an onPause() event, but this is called BOTH when I leave the activity and when I return to the activity.
Therefore my values get overwritten with zero and default values when I return to the activity, and my methods in the oncreate method do not respond like I would expect them to because of this.
Perhaps I am misunderstanding the Android lifecycle, but I've seen the lifecycle graph a dozen times and my programs do not act like I would expect them to.
Insight appreciated.
From my experience some devices are completely nuts about the event lifecycle of an activity.
The only solution I found was to make the activity as independent of the lifecycle as possible. I've seen devices that when they return from onPause destroy the activity only to create a new one. You should probably check if that's not your case.
The android tests for devices seems to lack a lot in this area.
As per activity life cycle, onPause() will be called both after onResume() and just before onStop(). So anything you do in onPause() will gets execute twice. But in my experiance some devices skipping onPause() before onStop() some times. So you don't rely onPause() alone. Better to write codes on onCreate() or onResume() with proper conditions.
Please put your code here for more clarification.
Related
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.
This is a text I have copied and pasted from this training tutorial.
"Because the system retains your Activity instance in system memory when it is stopped, it's possible that you don't need to implement the onStop() and onRestart() (or even onStart() methods at all. For most activities that are relatively simple, the activity will stop and restart just fine and you might only need to use onPause() to pause ongoing actions and disconnect from system resources."
I don't understand it. Because to the best of my knowledge, an activity is only stopped by calling onStop() and is only started by calling onStart(). How can an activity start at all without an onStart method.
Do you people understand what they mean in this paragraph?
I think they are confusing you with the word "stop" which appears to have multiple meanings in the paragraph.
I would rephrase it as
Because the system retains your Activity instance in system memory
when it is not in the foreground, it's possible that you don't need
to implement the onStop() and onRestart() (or even onStart() methods
at all. For most activities that are relatively simple, the activity
will suspend and restart just fine and you might only need to use
onPause() to pause ongoing actions and disconnect from system
resources.
The point being is that the App can appear to be stopped, when in actual fact, the system has simply paused it and hidden it from the screen. When the user launches it again, the App doesn't need to start (because it technically hasn't stopped), so it is simply resumed.
When you make an Activity and extend the base class Activity, there is already code in the onStop(), onStart(), and onRestart() methods in the base class.
Your activity simply extends these methods, meaning that you could add more code to them by Overriding them.
So, even though Activities are only started and stopped through those methods, you do not have to explicitly override them in your application. In most cases you won't even have to worry about them: They will be called by the base class from which you are extending.
Please make sure, An Activity starts from onCreate method , then onStart is called by system. If you override onStart method then your overridden method will be also called after onCreate method. If you don't override , then default version of onStart is called.
onStop is called after onPause.
Please check this link , and take a look at Activity life cycle . Your concept will be clear.
Difference between onCreate() and onStart()?
you can use an Activity just fine without - if you need to do something special in onPause() you can override the method:
#Override
public void onPause(){
super.onPause();
// Your magic here!
}
Same goes for onStart(), onStop() etc. You don't need to override the methods but you can if you need to do something specific.
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
Hi All!
I have an Activity which allocates quite lot of memory while it shows a visible layout. The UI heavily depends on this memory, however, there is no need to keep these allocations after the user traverses away from the Activity (usually by bringing another Activity to focus).
The Activity starts to allocate memory in onResume() and all is fine with that. It's the deallocation that confuses me a bit, though. As of now I release all memory in onPause() which also destroys the corresponding UI elements. Since the Activity is still visible while running onPause() the user will see the actual UI elements becoming destroyed. This is ugly and not what I want.
So my question:
Is it safe to release memory (destroy UI) in onStop() (according to documentation the Activity is not visible when onStop() is called)?
Is onStop() reliable?
Is onStop() guaranteed to be called every time when onPause() is called?
Edit:
I feel I must explain a bit more clearly what confuses me. According to developer.android.com:
...for those methods that are marked as being killable, after that
method returns the process hosting the activity may [be] killed by the
system at any time without another line of its code being executed...
The onStop() method is marked as "killable".
Does the above mean (especially the "after that method returns" part) that the entire scope of onStop() is guaranteed to run, but once it returns nothing else is guaranteed any runtime (e.g. a spawned thread started in onStop())?
Or does it mean that onStop() might get interrupted even before it reaches the end of its scope (as of the killed at any time part)?
Or does it mean something else that I - in my divine stupidity - don't see.
The difference is that the activity sees to it that onPause should finish executing first before "destroying" the view, while onStop is a lifecycle stage that follows after the view is already in the background - meaning the activity is not visible anymore.
doing things inside onPause makes sure that the items you need to save are still intact before letting go of them - for example you need to save the text in your EditText, or the on/off position of RadioButtons, etc.
deallocation however doesn't need any of these things anymore, so it should be fine if you do it in your onStop
onStop() should be safe and reliable enogh for your purpose.
"Guaranteed" is relative in this case, given that your activity may be killed without any notification. But in that case your memory resources are released anyway.
it's as safe as anything else? Worse comes to worse your app will be killed with onDestroy. In mobile development, you basically have to assume that at any given moment your app could be killed.
It's been reliable for me in releasing media objects for a while now.
Not really guaranteed, as sometimes onDestroy is called depending on what's going on.
No, it is not safe as only onPause() is guaranted to be called. onPause() means that yor activity loses focus - perfect place to give away not necessary resources
According to the "Application Fundamentals" article, section "component lifecycle", onResume() is always called when a View becomes active, independent of the previous state.
In the Notepad tutorial, Exercise 3, I have found something confusing in NoteEdit.java:
There is a call to populateFields() in onCreate() as well as in onResume().
Wouldn't it be enough (or even better) to have it only in onResume() ?
In such a small example, it will not do any harm if populateFields() is performed twice, but in a bigger App, things can be different ...
Thanks and Regards,
Markus N.
From a look at Notepad3, I would say you are correct. There doesn't seem to be any reason for them to call populateFields() in both onCreate() and onResume(). onResume is sufficient.
I can see where you need it in both places, if application pauses then you would need it in onResume and if your process gets killed or user navigates back to activity then you will need it in onCreate especially if you are doing some pre-processing.
Per the documentation....for onResume() they recommend using it for lightweight calls unlike in onCreate():
"The foreground lifetime of an activity happens between a call to onResume() until a corresponding call to onPause(). During this time the activity is in front of all other activities and interacting with the user. An activity can frequently go between the resumed and paused states -- for example when the device goes to sleep, when an activity result is delivered, when a new intent is delivered -- so the code in these methods should be fairly lightweight. "
The Notepad app may want a variable declared if the method was already hit by onCreate not to redo in onResume().