DIY Rotation

Even this, though, may still be too intrusive to your application. Suppose, for example, you are creating a real‑time game, such as a first‑person shooter. The “hiccup” your users experience as your activity is destroyed and re‑created might be enough to get them shot, which they may not appreciate. While this would be less of an issue on the T‑Mobile G1, since a rotation requires sliding open the keyboard and therefore is unlikely to be done mid‑game, other devices might rotate based solely upon the device’s position as determined by accelerometers.

The third possibility for handling rotations, therefore, is to tell Android that you will handle them completely yourself and that you do not want assistance from the framework. To do this:

1. Put an entry in your file, listing the configuration changes you want to handle yourself versus allowing Android to handle for you.

2. Implement in your , which will be called when one of the configuration changes you listed in occurs.

Now, for any configuration change you want, you can bypass the whole activity‑destruction process and simply get a callback letting you know of the change.

To see this in action, turn to the sample application. Once again, our layouts are the same, so the application looks the same as the preceding two samples. However, the Java code is significantly different, because we are no longer concerned with saving our state, but rather with updating our UI to deal with the layout.

But first, we need to make a small change to our manifest:

Here, we state that we will handle and configuration changes ourselves. This covers us for any cause of the “rotation” – whether it is a sliding keyboard or a physical rotation. Note that this is set on the activity, not the application – if you have several activities, you will need to decide for each which of the tactics outlined in this chapter you wish to use.

The Java code for this project follows: