Should you get data via a cursor and fill in the data on the screen, such as setting the window title, in onStart() or onResume()?
onStart() would seem the logical place because after onStart() the Activity can already be displayed, albeit in the background. Notably I was having a problem with a managed dialog that made me rethink this. If the user rotates the screen while the dialog is still open, onCreateDialog() and onPrepareDialog() are called between onStart() and onResume(). If the dialog needs to be based on the data you need to have the data before onResume().
If I'm correct about onStart() then why does the Notepad example give a bad example by doing it in onResume()? See http://developer.android.com/resources/samples/NotePad/src/com/example/android/notepad/NoteEditor.html NoteEditor.java line 176 (title = mCursor.getString...).
Also, what if my Activity launches another Actvity/Dialog that changes the data my cursor is tracking. Even in the simplest case, does that mean that I have to manually update my previous screen (a listener for a dialog in the main activity), or alternatively that I have to register a ContentObserver, since I'm no longer updating the data in onResume() (though I could update it twice of course)?
I know it's a basic question but the dialog only recently, to my surprise, made me realize this.
Again the solution depends on what suits you.
If you want the cursor to be pre-populated once per application (and not bothered about any change, then you can do it in onCreate(). This method will be recalled only if the app process is killed and app is reinitiated.
If you want the cursor to be prepopulated everytime the visible lifetime starts (most cases a service/broadcast is calling your activity, you should use onStart()
If you want the cursor to be prepopulated for every foreground lifecyle of activity, you should use onResume(). So if you have a dialog box or another subactivity modifying some information and hence you want to reload the cursor, it is best you do so in onResume(). The downside for this method is everytime the activity comes in foreground the cursor is reloaded.
Hope this makes it clear
To answer your question about NoteEditor, simply take a look at the lines above the one you cite and you'll see...
// Requery in case something changed while paused (such as the title)
mCursor.requery();
The comment seems to explain it all. Although I haven't gone through the NotePad example myself, it appears the author(s) are building in the ability to recover from changes whilst the NoteEditor is paused (and then resumed).
As GSree explains (whilst I was typing this), there isn't a right or wrong answer and it simply depends on what needs to be done at which point of the Activity life-cycle.
Related
I'm a little confused in trying to save values to an SQLiteDatabase. I want my app to seamlessly save the state and data, so I first put the "save to SQLDb (AsyncTask)" code into onStop(), and the "load from SQLDb" code in onStart(). However, I've noticed this is unreliable: pressing the back or home button calls onPause(), and sometimes onStop(), and when the app is brought back to the foreground, the Spinner items are sometimes there, sometimes empty, and the rest of the Views/content is also unpredictable due to whether onStop()/onStart() had been called.
So I moved the "save" code to onPause(), and the "load" code to onResume(). Now, I've read in the docs that this kind of stuff shouldn't be done in these methods, but for the most part, it works better than onStop() and onStart(). However, still, it is not exactly reliable: sometimes the AsyncTask never seems to end. If the user brings the app back to the foreground before the AsyncTask finishes, it leads to the above-mentioned unpredictable Views.
Where should I be saving this stuff?
Note: I have two Spinners that the user can dynamically add items to, as well as a GridView that must repopulate itself based on one of the Spinners (one gridChild per Spinner item). This kind of stuff, to my knowledge, cannot be saved easily by SharedPreferences or similar state-saving techniques, it must be done by database (especially since there are an indefinite amount of objects being saved, depending on what the user input).
Normally, you persist your data onPause() and restore it onResume().
This is because onStop() is not guaranteed to be called if the system needs to kill your app.
I'm learning about android programming from official website(http://developer.android.com).
I understand most of life cycle, but I'm not sure when system is destroying activity.
From what I understand, system is destroying activity when some activity stays for longer time in onStop() or when foreground activity needs more resources. Is that right ?
And from what I read the most efficient way to update data base is in onStop(), but let's say user is adding one word to my 'dictionary' application. So I need to gather this words in list and then update data base? Or I should insert rows to DB with each word ( in other method ) ?
As i understand you will never know when android force your application to stop.
So it is like this
onCreate() // here you could initialize
This is safe
onResume() // here turn on
onPause() // here turn off
// After this it is not sure
But if you are sure that finish() is always called you could use others
Data has to be persisted in the onPause()method. Otherwise, the system might terminate your process without further notice.
I have finished the Layout exercise and wondering why they include the call to populateFields() in both onCreate and onResume.
According to Activity Lifecycle "onResume" will always be performed before the Activity is shown so why not just there?
I have real production code that populates fields and is only called in onResume and it works just fine.
I thought one reason would be that maybe onResume is called after the activity is shown, but a bit of googling digs this (mostly unrelated) thread:
http://groups.google.com/group/android-developers/browse_thread/thread/ddea4830bedf8c6c?pli=1
Quote: onResume() is thus the last thing that happens before the UI is shown
This is what Dianne Hackborn says so i guess we can trust her :)
Actually I have seen apps (in my app and also others), where fields were only populated in onCreate(), but not in onResume().
Lets call that app 'A'.
The effect was that when the user pressed the home button, went to a different app, and then returned to 'A', the screen stayed black, as 'A' was still in memory and thus the system did not bother to call onCreate(), but directly went into onResume().
So basically I'd say (and this seconds what #Torp wrote) populate the UI in onResume() and be done.
But then, this answer is slightly off-topic as it does not answer your "why" question.
You don't populate in onResume because it will be called every time the activity is shown.
You generally want to create as few objects as possible, so you create them once and for all in onCreate, and then you can always check that they are still updated in onResume.
I have two activities. One loads all rows from a database, and the other saves to the database. When I have the second save in onStop and the first repull the data in onResume, they do it out of order (the first resumes and then the second saves). I managed to fix this by putting the saving data in onPause, but why was this happening? Was this the cleanest way to do it?
Doing the save in the first actvity's onPause should be fine.
You've discovered that 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 on screen and is interacting with the user.
When you start the second activity, onPause is called on the first and then interactive control switches to the second, with onStop on the first to be called somewhat in background.
This improves responsiveness and gets the new activity in front of the user ASAP. Consequently, you should try to keep your onPause implementation as fast and efficient as possible.
See the following Android docs for more details on the lifecycle http://developer.android.com/guide/topics/fundamentals.html, but what you have found should work fine for you.
Some official quote as an add-on:
The Activity documentation states that
onPause() is where you deal with the user leaving your activity.
Most importantly, any changes made by the user should at this point be
committed
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().