Public class extends

Static final

Null

Null

Public onCreate

Super onCreate

SetContentView

FindViewById

SetOnClickListener new OnClickListener

Public onClick

New Intent

Parse

StartActivityForResult

FindViewById

SetOnClickListener new OnClickListener

Public onClick

StartActivity new Intent

RestoreMe

SetEnabled null

Protected onActivityResult

If

If

GetData

SetEnabled true

Protected onSaveInstanceState

Super onSaveInstanceState

If null

PutString toString

Private restoreMe

Null

If null

GetString

If null

Parse

By and large, it looks like a normal activity… because it is. Initially, the “model” – a named – is null. It is set as the result of spawning the sub‑activity. Its string representation is saved in and restored in (called from ). If the contact is not null, the “View” button is enabled and can be used to view the chosen contact.

Visually, it looks like Figures 26‑1 and 26‑2.

Figure 26‑1. The RotationOne application, in portrait mode

Figure 26‑2. The RotationOne application, in landscape mode

The benefit to this implementation is that it handles a number of system events beyond mere rotation, such as being closed by Android due to low memory.

For fun, comment out the call in and try running the application. You will see that the application “forgets” a contact selected in one orientation when you rotate the emulator or device.

Now With More Savings!

The problem with is that you are limited to a . That’s because this callback is also used in cases where your whole process might be terminated (e.g., low memory), so the data to be saved has to be something that can be serialized and has no dependencies upon your running process.

For some activities, that limitation is not a problem. For others, though, it is more annoying. Take an online chat, for example. You have no means of storing a socket in a , so by default, you will have to drop your connection to the chat server and re‑establish it. That not only may be a performance hit, but it might also affect the chat itself, such as you appearing in the chat logs as disconnecting and reconnecting.

One way to get past this is to use instead of for “light” changes like a rotation. Your activity’s callback can return an , which you can retrieve later via . The can be just about anything you want – typically, it will be some kind of “context” object holding activity state, such as running threads, open sockets, and the like. Your activity’s can call – if you get a non‑null response, you now have your sockets and threads and whatnot. The biggest limitation is that you do not want to put in the saved context anything that might reference a resource that will get swapped out, such as a loaded from a resource.

Let’s take a look at the sample project, which uses this approach to handling rotations. The layouts, and hence the visual appearance, is the same as with . Where things differ slightly is in the Java code: