Question

I have used both approaches:

1. Let the activity be destroyed on rotation
2. Don’t let the activity be destroyed on rotation

My approach almost everytime is to catch the rotation event and if needed call the setContentView and add some components again. If not, just let it rotate and the layouts are designed to adapt.

So far I only have seen advantages on letting it be destroyed on screens with very complex construction that are very dynamic, and whenever I rotate and not destroy show some flickering when re-building the screen.

The overhead of having to pass the state with onSaveInstance, onRestoreInstace is sometimes very error prone, and somehow time consuming.

Am I missing something?

UPDATE:

I’m not doing any kind of if “Orientation.XPTO == …” on my code. This is the logic of each of the 2 approaches (the code is reused):

When destroying

onCreate -> DrawUI() setContentView and add views -> fill() add content

When not destroyed:

onCreate -> DrawUI() setContentView and add views -> fill() add content
onRotation -> DrawUI() setContentView and add views -> fill() add content

When calling setContentView after rotation it will pick the right layout for the device orientation (Check this answer by Google’s Reto Meier https://stackoverflow.com/a/456918/327011 )

And the DrawUI and fill would have to have the logic for both the portrait and landscape layouts as the activity can be created on each of the two orientations to begin with.

Answer 1

Am I missing something?

Yes. You are assuming that your alternative is somehow less error prone.

By not going through the destroy-and-recreate cycle, you have to ensure that you are handling changing every resource for every possible configuration change.

Don’t let the activity be destroyed on rotation

Unless you are using android:screenOrientation to force your activity into a single orientation (e.g., landscape), you cannot only handle rotation-related configuration changes. You need to handle all configuration changes. Otherwise, as soon as the user drops their device into a dock, removes it from a dock, changes language from Settings, attaches or detaches a keyboard, changes the global font scaling, etc., your app will break.

This, in turn, means that on every configuration change, you need to:

• update your UI for your potentially new string resources
• adjust or reload your layouts (and by “adjust” that includes changing any drawables, animations, menus, etc.)
• anything else tied to your resources (e.g., array lists in your PreferenceFragment)

The problem is that you are going to forget something. For example, you will miss changing a string associated with an action bar item, so now most of your UI is in Spanish and that action bar item is in English. The sorts of things you are going to forget will be less obvious (how often do you test your Spanish translation?).