Mark Murphy - Beginning Android

Android has a number of ways for you to handle screen rotation, so your application can properly handle either orientation. All these facilities do is help you detect and manage the rotation process — you are still required to make sure you have layouts that look decent on each orientation.

By default, when there is a change in the phone configuration that might affect resource selection, Android will destroy and re-create any running or paused activities the next time they are to be viewed. While this could happen for a variety of different configuration changes (e.g., change of language selection), it will most likely trip you up mostly for rotations, since a change in orientation can cause you to load a different set of resources (e.g., layouts).

The key here is that this is the default behavior. It may even be the behavior that is best for one or more of your activities. You do have some control over the matter, though, and can tailor how your activities respond to orientation changes or similar configuration switches.

Since, by default, Android destroys and re-creates your activity on a rotation, you may only need to hook into the same onSaveInstanceState()that you would if your activity were destroyed for any other reason (e.g., low memory). Implement that method in your activity and fill in the supplied Bundlewith enough information to get you back to your current state. Then, in onCreate()(or onRestoreInstanceState(), if you prefer), pick the data out of the Bundleand use it to bring your activity back to the way it was.

To demonstrate this, let’s take a look at the Rotation/RotationOneproject. It, and the other sample projects used in this chapter, which are also found in the source code section of the Apress web site, use a pair of main.xml layouts, one in res/layout/and one in res/layout-land/for use in landscape mode. Here is the portrait layout:

android:orientation="vertical"

android:layout_width="fill_parent"

android:layout_height="fill_parent"

>

android:layout_width="fill_parent"

android:layout_height="fill_parent"

android:layout_weight="1"

android:text="Pick"

android:enabled="true"

/>

android:layout_width="fill_parent"

android:layout_height="fill_parent"

android:layout_weight="1"

android:text="View"

android:enabled="false"

/>

while here is the similar landscape layout:

android:orientation="horizontal"

android:layout_width="fill_parent"

android:layout_height="fill_parent"

>

android:layout_width="fill_parent"

android:layout_height="fill_parent"

android:layout_weight="1"

android:text="Pick"

android:enabled="true"

/>

android:layout_width="fill_parent"

android:layout_height="fill_parent"

android:layout_weight="1"

android:text="View"

android:enabled="false"

/>

Basically, it is a pair of buttons, each taking up half the screen. In portrait mode, the buttons are stacked; in landscape mode, they are side-by-side.

If you were to simply create a project, put in those two layouts, and compile it, the application would appear to work just fine — a rotation (Ctrl-F12 in the emulator) will cause the layout to change. And while buttons lack state, if you were using other widgets (e.g., EditText), you would even find that Android hangs onto some of the widget state for you (e.g., the text entered in the EditText).

What Android cannot automatically help you with is anything held outside the widgets.

This application is derived from the Pick demo used in Chapter 24. There, clicking one button would let you pick a contact, then view the contact. Here, we split those into separate buttons, with the “View” button only enabled when we actually have a contact.

Let’s see how we handle this, using onSaveInstanceState():

public classRotationOneDemo 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(savedInstanceState);

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

protectedvoid onSaveInstanceState(Bundle outState) {

super. onSaveInstanceState(outState);

if(contact!= null) {

outState. putString("contact", contact. toString());

}

}

privatevoid restoreMe(Bundle state) {

contact = null;

if(state!= null) {

String contactUri = state. getString("contact");

if(contactUri!= null) {

contact = Uri. parse(contactUri);

}

}

}

}

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