onActivityResult() & onResume()

As others have posted, onActivityResult() is called before onResume() when your activity is being restarted.

Diane Hackborn explains that onActivityResult() is called before onResume() in order to allow anything that might affect the UI to be received and available prior to updating the UI (presumably to avoid a double-update - once in onResume() without the returned result, and then in onActivityResult(), adding the returned result).

https://groups.google.com/forum/?fromgroups=#!topic/android-developers/3epIML7fjGw

One consequence of this is that any initializations you might have decided to perform only within onResume() (e.g., initializations of data from an outside source that you need to be fresh) rather than in onCreate(), would be uninitialized when a call to onActivityResult() occurs as part of restarting an app that has been flushed out of memory by the OS (because onResume() would not have been called prior to onActivityResult()).

In this situation, onActivityResult() would have to be prepared to perform such initializations for any such variables that are used by onActivityResult().

Of course, if the initializations needed by onActivityResult() could be performed in onCreate() rather than in onResume(), then since onCreate() will be called on a restart before both onActivityResult() and onResume(), that would be the easiest way to go for stuff that you don't need to do each time the app is resumed. If, however, the data you're initializing comes from an outside source and you need it to be fresh, you may want to initialize such data in both onCreate() and onResume(), with onResume() checking a flag set in onCreate() to see if the data have just been initialized in onCreate), and then updating it in onResume() only if they have not been. That way, some vintage of it will always be available (at least as of the previous time the app was resumed).

Another way to deal with this is to store the information returned by onActivityResult() in variables that will get picked up by onResume() and processed there (after any required initializations have been performed by onResume()), rather than performing the processing within the body of onActivityResult() itself.

This is a feature that is very tersely documented, with no explanation or warning offered (in the official docs) regarding the consequences of this somewhat unexpected sequencing. It is also very easy to miss the problem during testing, because on a device with plenty of memory that is not running many apps, the activity that is calling startActivityForResult() (or its variants) may never get flushed from memory while waiting for the started activity to return a result via onActivityResult(), and thus all initializations done by onResume() will already be available, and thus the problem may not be detected.

There's an informative exploration of some of the issues surrounding this sequencing (including a warning regarding attempts to use of the app's Application object to protect variables from its effects), complete with a hand-drawn UML sequence diagram, here:

http://steveliles.github.com/android_activity_lifecycle_gotcha.html

First calling onActivityResult() then onResume().

Quote from docs:

protected void onActivityResult (int requestCode, int resultCode, Intent data)

Since: API Level 1 Called when an activity you launched exits, giving you the requestCode you started it with, the resultCode it returned, and any additional data from it. The resultCode will be RESULT_CANCELED if the activity explicitly returned that, didn't return any result, or crashed during its operation. You will receive this call immediately before onResume() when your activity is re-starting.