Question

I have a question. I'm learning about the activity lifecycles in Android at the moment. I had some trouble with the orientation change of the device.

In my particular case I have an activity with a quite complex data-structure. As I don't like the retained fragment method to pass this object to the new created activity, I will use the deprecated onRetainNonConfigurationInstance() method, because I feel its more light weight. Is there a big disadvantage to use this?

Another thing I did experience is, that when I have an activity and views, for example TextEdits defined (in the layout XML in my case) and I write something and then cause an orientation change, the TextEdits keeps its state (the text written in), even though I didn't care for it. How can that be explained?

Was it helpful?

Solution 2

This biggest issue with something like "onRetainNonConfigurationInstance()" is that it won't account for the destruction and recreation of your app's activities during the OS's Process Lifecycle. See the documentation for this here. Basically, when your app is in the background and as you use other device apps, the OS will begin to kill processes to release system resources. When this happens and you then reopen your app, the OS attempts to recreate your application through the savedInstanceState.

For this reason, regardless of whether my application supports landscape mode or not, I always make sure that orientation changes work seamlessly to recreate state without using anything like onRetainNonConfigurationInstance.

Here's a simple test to run to check for recreation of app state after it's released by the OS:

  1. Open your application to the page in question.
  2. Push the "Home" button on your phone.
  3. Open up no less than 3 high resource usage apps with long scrolling listViews ( I use Facebook, Youtube and Google Play store).
  4. In each app scroll the listview down a good amount to use system resources.
  5. After you're done with all 3 apps, reopen your app.

What happened? If you've handled saving your state correctly, you should see the application recreating the view from the savedInstanceState bundle that you saved. You could also see a recreated view with lost data OR a null pointer exception.

As for your second point, smitalm is correct, the OS does handle the saving of state of basic view elements for you when correctly configured. For more info, check out the Recreating an Activity documentation.

Hope this helps.

OTHER TIPS

If your inputs have unique IDs, then their state will be saved upon orientation change.

As for correct way of saving activity state upon orientation change, see onSaveInstanceState () and onRestoreInstanceState (). Basically, when you override onSaveInstanceState (Bundle icicle) any data that needs should be put in Bundle (provided as method parameter).

When you override onRestoreInstanceState () you load these data back.

Additionaly, if you need to save custom objects, you need to make them implement Parcelable interface.

If you dont want to use Parcelable, you can just serialize your objects as JSON String and put that String to Bundle - Bundle already supports Strings. Then, in onRestoreInstanceState () just deserialize your JSON back to your Java objects.

As for JSON serializing, i highly recommend google GSON for this job.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top