Called by the system, as part of destroying an activity due to a configuration change, when it is known that a new instance will immediately be created for the new configuration. You can return any object you like here, including the activity instance itself, which can later be retrieved by calling Activity.LastNonConfigurationInstance in the new activity instance. If you are targeting NoType:android/os/Build$VERSION_CODES;Href=../../../reference/android/os/Build.VERSION_CODES.html#HONEYCOMB or later, consider instead using a Android.App.Fragment with Fragment.RetainInstance.

This function is called purely as an optimization, and you must not rely on it being called. When it is called, a number of guarantees will be made to help optimize configuration switching:

• The function will be called between Activity.OnStop and Activity.OnDestroy.
• A new instance of the activity will always be immediately created after this one's Activity.OnDestroy is called. In particular, no messages will be dispatched during this time (when the returned object does not have an activity to be associated with).
• The object you return here will always be available from the Activity.LastNonConfigurationInstance method of the following activity instance as described there.

These guarantees are designed so that an activity can use this API to propagate extensive state from the old to new activity instance, from loaded bitmaps, to network connections, to evenly actively running threads. Note that you should not propagate any data that may change based on the configuration, including any data loaded from resources such as strings, layouts, or drawables.

The guarantee of no message handling during the switch to the next activity simplifies use with active objects. For example if your retained state is an Android.OS.AsyncTask`3 you are guaranteed that its call back functions (like Android.OS.AsyncTask`3.onPostExecute(Result)) will not be called from the call here until you execute the next instance's Activity.OnCreate(Android.OS.Bundle). (Note however that there is of course no such guarantee for Android.OS.AsyncTask`3.doInBackground(Params...) since that is running in a separate thread.)

[Android Documentation]