36

As far as I can see onRetainNonConfigurationInstance is a redundant callback. If my activity has really expensive initialization, I am better off using onSaveInstanceState. Saved instance covers more situations than non-configuration instance. Is there any guideline for using one API vs. the other? Thanks.

Raj
  • 361
  • 1
  • 3
  • 3

1 Answers1

48

As far as I can see onRetainNonConfigurationInstance is a redundant callback.

No, it is not.

If my activity has really expensive initialization, I am better off using onSaveInstanceState.

onSaveInstanceState() is not designed for "really expensive initialization". It is designed for "hey, the user made some changes to the information in the activity but has not saved it yet, let's not lose that data, m'kay?".

Is there any guideline for using one API vs. the other?

If it fits in a Bundle and is not too big, use onSaveInstanceState(). Everything that does not fit in a Bundle (e.g., a socket) or is really big (e.g., a photo as a Bitmap) should use onRetainNonConfigurationInstance(), and your application should be in position to re-create those items if needed.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • 6
    @Raj: No, it wouldn't. The two methods serve different roles. `onSaveInstanceState()` happens to be used in configuration changes. It also happens to be used in cases where Android wants to terminate the application's process to free up RAM, yet the user can still get back to the activity (e.g., via the BACK button). This is why Android uses a `Bundle` -- it can be converted into a `byte[]` and shipped across process boundaries. Android holds onto the `byte[]` until such time as it is needed or until the activity is no longer reachable via BACK. – CommonsWare Nov 26 '10 at 17:02
  • 6
    @Raj: However, since a `Bundle` (or whatever `onSaveInstanceState()` would use) needs to be transported across process boundaries, we still lack ways of handling things that we want to hold onto for a configuration change yet cannot themselves go into a `Bundle`, like a socket. For that, there is `onRetainNonConfigurationInstance()`, which is only used in cases where the process will *not* be terminated, and so we can pass arbitrary objects from old to new activity instance. – CommonsWare Nov 26 '10 at 17:04
  • 4
    My take is, onSaveInstanceState() allows saving simple serializable data in long term persistent storage. This data can be retrieved at a later time, even after the application processes has been killed. In contrast, onRetainNonConfigurationInstance() allows you to save any Java object with the assumption that, these objects will be re-used immediately by a new activity instance. Hence, items like AsyncTask and SQLiteDatabse can be saved. The key here is to create these objects using application and not activity context. Otherwise, the destroyed activity may be unable to be garbage collected. – Raj Nov 26 '10 at 17:05
  • 1
    @Raj: Hence, `onSaveInstanceState()` and `onRetainNonConfiguration()` instance have different roles, will be called at different times, and handle different sorts of data. If you feel this use of two whole methods is egregious, you are cordially invited to submit a patch to Android to consolidate them (http://source.android.com). – CommonsWare Nov 26 '10 at 17:06
  • 1
    Thanks everyone. It's clear now and I agree that these two methods have different purposes. The documentation could have been more elaborate. – Raj Nov 26 '10 at 17:08