Handling orientation changes yourself

From the documentation regarding the android:configChanges='orientation' attribute of the activity tag in the manifest:

Note: Using this attribute should be avoided and used only as a last-resort. Please read Handling Runtime Changes for more information about how to properly handle a restart due to a configuration change.

Why does it say this?

In the case of threads and networking requests via a service API library, a request could be made with a reference to the original Activity, and then an orientation change could occur, leaving the thread pointing to the old Activity.

While this can be fixed, it's tedious and ugly compared to just handling the configuration c开发者_JAVA百科hanges yourself.

Why should it be avoided?

Edit: I guess I should also ask: would this be an acceptable reason for doing the orientation configuration changes yourself?

---

Why does it say this?

Because they want you to read the "Handling Runtime Changes" section in the docs. :-)

In the case of threads and networking requests via a service API library, a request could be made with a reference to the original Activity, and then an orientation change could occur, leaving the thread pointing to the old Activity.

For cases where you care about rotations, don't use implicit references to the Activity (e.g., regular inner class), but rather explicit ones (e.g., static inner class). Here is a brand-spankin'-new sample project that demonstrates what I mean.

While this can be fixed, it's tedious and ugly compared to just handling the configuration changes yourself.

The recommendation is there, I suspect, because they are afraid newcomers to Android will mess up "handling the configuration changes yourself". For example, they decide to have some different strings for landscape (where you have more horizontal room) and forget to reload them. Or, they decide to have some different images for landscape and forget to reload them. And so on.

Most activities in most apps aren't going to have background threads or sockets or whatever of their own, either because they just don't need them, or because something else is managing them (e.g., a Service). Their stock implementation of destroy-and-recreate typically "just works", particularly with the built-in support for saving the widget state of EditTexts and such.

In addition, you may not save that much by "handling it yourself", because you still need to implement onSaveInstanceState() anyway, to handle scenarios other than configuration changes (e.g., your activity is kicked out of RAM to free up space).

Now, is their phrasing a bit harsh? Probably. Seasoned Android developers can make their own decisions as to which rotation handling strategy to employ. I suspect their tone is to try to scare newcomers into thinking twice before going down this route.

---

I agree, in certain cases it seems like overkill to have to save state and redraw my views. I can understand if you want to configure a different layout when orientation changes but otherwise it is so much easier to add this to my activity.

@Override
public void onConfigurationChanged(Configuration newConfig) {
 if(newConfig.equals(Configuration.ORIENTATION_LANDSCAPE) 
   || newConfig.equals(Configuration.ORIENTATION_PORTRAIT)
   || newConfig.equals(Configuration.ORIENTATION_SQUARE)
   || newConfig.equals(Configuration.ORIENTATION_UNDEFINED)) {

 } else {
  super.onConfigurationChanged(newConfig);
 }
}