}
});
viewButton = (Button)findViewById(R.id.view);
viewButton.setOnClickListener(new View.OnClickListener() {
public void onClick(View view) {
startActivity(new Intent(Intent.ACTION_VIEW, contact));
}
});
viewButton.setEnabled(contact!=null);
}
}
The onCreate() implementation delegates most of its logic to a setupViews() method, which loads the layout and sets up the buttons. The reason this logic was broken out into its own method is because it is also called from onConfigurationChanged().
Forcing the Issue
In the previous three sections, we covered ways to deal with rotational events. There is, of course, a radical alternative: tell Android not to rotate your activity at all. If the activity does not rotate, you do not have to worry about writing code to deal with rotations.
To block Android from rotating your activity, all you need to do is add android:screenOrientation="portrait" (or "landscape", as you prefer) to your AndroidManifest.xml file, as shown (from the Rotation/RotationFour sample project):
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.commonsware.android.rotation.four"
android:versionCode="1"
android:versionName="1.0.0">
<application android:label="@string/app_name">
<activity android:name=".RotationFourDemo"
android:screenOrientation="portrait"
android:label="@string/app_name">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
</application>
</manifest>
Since this is applied on a per-activity basis, you will need to decide which of your activities may need this turned on.
At this point, your activity is locked into whatever orientation you specified, regardless of what you do. The following screen shots show the same activity as in the previous three sections, but using the previous manifest and with the emulator set for both portrait and landscape orientation. Note that the UI does not move a bit, but remains in portrait mode as can be seen in Figures 26-3 and 26-4.
Figure 26-3. The RotationFour application, in portrait mode
Figure 26-4. The RotationFour application, in landscape mode
Making Sense of it All
All of these scenarios assume that you rotate the screen by opening up the keyboard on the device (or pressing <Ctrl>-<F12> in the emulator). Certainly, this is the norm for Android applications.
However, we haven’t covered the iPhone Scenario.
You may have seen one (or several) commercials for the iPhone, showing how the screen rotates just by turning the device. By default, you do not get this behavior with the T-Mobile G1 — instead, the screen rotates based on whether the keyboard is open or closed.
However, it is very easy for you to change this behavior, so your screen will rotate based on the position of the phone: just add android:screenOrientation="sensor" to your AndroidManifest.xml file (as seen in the Rotation/RotationFive sample project):
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.commonsware.android.rotation.five"
android:versionCode="1"
android:versionName="1.0.0">
<application android:label="@string/app_name">
<activity android:name=".RotationFiveDemo"
android:screenOrientation="sensor"
android:label="@string/app_name">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
</application>
</manifest>
The “sensor”, in this case, tells Android you want the accelerometers to control the screen orientation, so the physical shift in the device orientation controls the screen orientation.
At least on the G1, this appears to only work when going from the traditional upright portrait position to the traditional landscape position — rotating 90 degrees counter-clockwise. Rotating the device 90 degrees clockwise results in no change in the screen.
Also note that this setting disables having the keyboard trigger a rotation event. Leaving the device in the portrait position, if you slide out the keyboard, in a “normal” Android activity, the screen will rotate; in a android:screenOrientation="sensor" activity, the screen will not rotate.
PART 5
Content Providers and Services
CHAPTER 27
Using a Content Provider
Any Uri in Android that begins with the content://scheme represents a resource served up by a content provider. Content providers offer data encapsulation using Uri instances as handles — you neither know nor care where the data represented by the Uri comes from, so long as it is available to you when needed. The data could be stored in a SQLite database, or in flat files, or retrieved off a device, or be stored on some far-off server accessed over the Internet.
Given a Uri, you can perform basic CRUD (create, read, update, delete) operations using a content provider. Uri instances can represent either collections or individual pieces of content. Given a collection Uri, you can create new pieces of content via insert operations. Given an instance Uri, you can read data represented by the Uri, update that data, or delete the instance outright.
Android lets you use existing content providers or create your own. This chapter covers using content providers; Chapter 28 will explain how you can serve up your own data using the content provider framework.
Pieces of Me
The simplified model of the construction of a content Uri is the scheme, the namespace of data, and, optionally, the instance identifier, all separated by slashes in URL-style notation. The scheme of a content Uri is always content://.