views:

147

answers:

1

I am only a beginner to Android, but I have noticed a number of things that seem a little strange in the third notepad tutorial:

  • The tutorial explicitly states that you need to call saveState from BOTH onSaveInstanceState and onPause. Is this really necessary? It seems to me from reading the process life-cycle documentation that onPause will always be called before the Activity is killed, regardless of whether it is done so by the system or the user. If this is the case, surely just calling saveState from onPause is sufficient?
  • Calling populateFields() in both onResume and onCreate is pointless, since onResume is always called after onCreate anyway. Hence if I understand correctly, the call in onCreate serves no useful purpose and can be safely removed.

Could someone please either confirm these points, or let me know what I have misunderstood.

Olly

A: 

From what I understand...

You are correct that onResume is always called eventually after onCreate, and you can often put the code there. Keep in mind though that onResume will also be called when an activity comes back to the foreground, without first going through onCreate. So for one time initialization code (like setContentView() or initializing variables) the onCreate event is a better place.

Also, you are correct about the onPause and onStop. onPause is where you'd normally code the state handling. onPause is killable so that onStop can potentially not even get called in very low memory situations.

Mike
Oops I just noticed you were referring to onSaveInstanceState not onStop (not sure how I got off track there, sorry). Their example is correct. While savestate will get called twice at times, they need to call it in onSaveInstanceState to get the ID of the new data to add to the bundle and in onPause (in the case that onSaveInstanceState isn't called) just to make sure the data is at least saved.
Mike
Ah - Ignore my previous post here..talking rubbish :). Thanks.
Olly
saveState called by onSaveInstanceState modifies mRowId, which is then put in the bundle by the next line in onSaveInstanceState. While that rowid is technically persistent in that it's in the database, the way they are using it there, it isn't. There they are using it to know which note is being displayed. However, that is why they do also call saveState in the onPause event. At that point they aren't concerned with which ID is being displayed, but that the data is saved and not lost. Since onSaveInstanceState may not be called, they have to call it from onPause as well.
Mike
Yep I see now - Thanks :).
Olly