What are the pros and cons of using configChanges="orientation" for android devices?

I'm wanting to use android:configChanges="orientation|keyboardHidden" for a few of my activities so that my onCreate doesn't get called again, but I thoug开发者_如何学Pythonht I'd see if anyone had a list of pros and cons first because this link says that it should only be used as a last resort.

It's weird that Google doesn't really talk more about the reasoning behind it, but there are really three main reasons I can think of to avoid using that approach:

• In my experience, some view types (particularly WebViews and MapViews on Android 2.1 or lower) can behave rather oddly after the orientation change if they haven't been recreated (zoom buttons mispositioned, for example).
• It prevents you from using orientation-specific layouts (see the new Market app's landscape view, for example).
• It can keep you from discovering buggy behavior from your application relating to other types of reasons your Activity might be destroyed and recreated (e.g. low-memory or other normal kills while backgrounded). That is, if your activity can gracefully handle a restart due to rotation, it can probably handle a restart due to background-killing. If you skip handling rotation, though, you may not encounter a restart due to background-killing under normal testing until a user with an older low-memory phone writes in with a bug report.

The last reason is the big one; especially with older low-RAM phones and with the supposedly more-aggressive autokilling behaviors in Gingerbread, your activities need to know how to quickly be recreated after a destruction by saving their state, regardless of orientation handling. And once your activities can handle those kinds of destruction/recreation, you're probably all set for rotation change kills anyways. You can gain some speed by absorbing the rotation event (since you don't have to go back through layout inflation and all that) but that's about all, at that point.

If you do decide to swallow rotations I highly recommend always using an emulator or device with the Development.apk's "Immediately destroy activities" option checked, and then making sure that switching apps or backing through your task stack still work correctly.

In my experience absorbing rotations can actually a good choice for an improved user experience, especially on activities with complex layouts that may take a few moments to recreate, but you really need to test carefully and effectively make sure that your activity would still work even without the rotation-ignoring.

A big Pro of using this approach is that it requires very little effort on your part, and that your app will survive config changes without resorting to crashes.

The small drawback is that using configuration specific resources (for landscape or portrait orientation) don't get applied automatically.

In my (perhaps little) experience, I think its not really worth the effort to do all the plumbing.

"Proper" handling of these config changes requires a lot of plumbing on your part, and things get even more dramatic if you have to support progress dialogs during screen orientation changes.

Although most people will opt for the quick fix by changing the manifest, and configuring their activity with android:configChanges=”keyboardHidden|orientation”, I think it’s important to realize that there are alternatives to this.

It requires more code, but it does give you better insight in how the overall system works.