Android lifecycle: Fill in data in activity in onStart() or onResume()?
Asked Answered
K

2

7

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.

Kinnon answered 8/1, 2011 at 23:36 Comment(0)
D
2

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.

Dank answered 9/1, 2011 at 0:54 Comment(3)
This just says that they requery after a pause. I've suggested the same in my question. Your point being? Obviously it's merely a bad example and not a bug in Notepad because nothing else that NoteEditor interacts with amplifies the difference between onStart() and onResume() in their case.Kinnon
@pjv: My point is that onPause() -> onResume() -> onPause() -> onResume() etc etc can occur many times without onPause() -> onStop() -> onRestart() -> on Start() (or onPause() -> onStop() -> onDestroy() -> onCreate() -> onStart()) ever happening. If there is a possibility of a critical change to anything during the onPause() -> onResume() cycle then it makes absolute sense to 'do' (and 'redo') something in onResume() rather than in onStart().Dank
Ok that's clearer and you're right, I'd be looking at a 'redo' in onResume() then as well.Kinnon
P
3

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

Palm answered 9/1, 2011 at 0:48 Comment(3)
If you have a dialog that a) is based on your data, and b) is modifying that data, then you need to a) load the cursor data in onStart() for the purpose of onPrepareDialog(), AND, b) reload the cursor data in onResume(), as the data may have changed after being paused??Kinnon
@Kinnon Based on what you asked, you could simply load the data in onResume() method. Manage the dialog lifecyle within onResume(). See the doco for activity (developer.android.com/guide/topics/fundamentals.html#actlife). The activity will go through onResume before the user can interact with it.Palm
thanks for your comment, but as I said in my second paragraph wrt. the managed dialog: onCreateDialog() and onPrepareDialog() are called before onResume(). I'd prefer not to take the managing of the dialog into my own hands when there's a perfectly usable platform implementation.Kinnon
D
2

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.

Dank answered 9/1, 2011 at 0:54 Comment(3)
This just says that they requery after a pause. I've suggested the same in my question. Your point being? Obviously it's merely a bad example and not a bug in Notepad because nothing else that NoteEditor interacts with amplifies the difference between onStart() and onResume() in their case.Kinnon
@pjv: My point is that onPause() -> onResume() -> onPause() -> onResume() etc etc can occur many times without onPause() -> onStop() -> onRestart() -> on Start() (or onPause() -> onStop() -> onDestroy() -> onCreate() -> onStart()) ever happening. If there is a possibility of a critical change to anything during the onPause() -> onResume() cycle then it makes absolute sense to 'do' (and 'redo') something in onResume() rather than in onStart().Dank
Ok that's clearer and you're right, I'd be looking at a 'redo' in onResume() then as well.Kinnon

© 2022 - 2024 — McMap. All rights reserved.