Mark Murphy - Beginning Android

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 restoreMe()call in onCreate()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.

The problem with onSaveInstanceState()is that you are limited to a Bundle. 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 Bundle, 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 onRetainNonConfigurationInstance()instead of onSaveInstanceState()for “light” changes like a rotation. Your activity’s onRetainNonConfigurationInstance()callback can return an Object, which you can retrieve later via getLastNonConfigurationInstance(). The Objectcan 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 onCreate()can call getLastNonConfigurationInstance()— 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 Drawableloaded from a resource.

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

public classRotationTwoDemo extendsActivity {

static finalint PICK_REQUEST = 1337;

Button viewButton = null;

Uri contact = null;

@Override

publicvoid onCreate(Bundle savedInstanceState) {

super. onCreate(savedInstanceState);

setContentView(R.layout.main);

Button btn = (Button) findViewById(R.id.pick);

btn. setOnClickListener( newView. OnClickListener() {

publicvoid onClick(View view) {

Intent i = new Intent(Intent.ACTION_PICK,

Uri. parse("content://contacts/people"));

startActivityForResult(i, PICK_REQUEST);

}

});

viewButton = (Button) findViewById(R.id.view);

viewButton. setOnClickListener( newView. OnClickListener() {

publicvoid onClick(View view) {

startActivity( new Intent(Intent.ACTION_VIEW, contact));

}

});

restoreMe();

viewButton. setEnabled(contact!= null);

}

@Override

protectedvoid onActivityResult(int requestCode, int resultCode,

Intent data) {

if(requestCode==PICK_REQUEST) {

if(resultCode==RESULT_OK) {

contact = data. getData();

viewButton. setEnabled( true);

}

}

}

@Override

publicObject onRetainNonConfigurationInstance() {

return(contact);

}

privatevoid restoreMe() {

contact = null;

if( getLastNonConfigurationInstance()!= null) {

contact = (Uri) getLastNonConfigurationInstance();

}

}

}

In this case, we override onRetainNonConfigurationInstance(), returning the actual Urifor our contact, rather than a string representation of it. In turn, restoreMe()calls getLastNonConfigurationInstance(), and if it is not null, we hold onto it as our contact and enable the “View” button.

The advantage here is that we are passing around the Urirather than a string representation. In this case, that is not a big saving. But our state could be much more complicated, including threads and sockets and other things we cannot pack into a Bundle.

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 android:configChangesentry in your AndroidManifest.xmlfile, listing the configuration changes you want to handle yourself versus allowing Android to handle for you.

2. Implement onConfigurationChanged()in your Activity, which will be called when one of the configuration changes you listed in android:configChangesoccurs.

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 Rotation/RotationThreesample 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.