system.
To create a new project, run android create project. This will require a few additional parameters, notably:
• -k to supply the package name to use with your application (e.g., -k com.commonsware.android.sample)
• -n to supply the name of the project, which will determine the name of the APK file (e.g., -n MyProject)
• -a to supply the name of the activity class (e.g., -a MyMainActivity)
• -t to supply the target ID for use with this project, following the same target system used when creating AVDs, described in the preceding section “Getting Started, Virtually” (e.g., -t 3)
• -p to indicate where the project files should be generated (e.g., -n MyProject)
To update an existing project, run android update project. This will replace your build.xml file and do a few other odds and ends to convert a project to be built using the Android 1.5 build system. As with android create project, you will want to provide a few additional parameters on the command, including:
• -t to supply the target ID for use with this project, following the same target system used when creating AVDs, described in the preceding section “Getting Started, Virtually” (e.g., -t 3)
• -p to indicate where the project files should be generated (e.g., -n MyProject)
Make Your Demands Heard
In addition to using the target ID system to indicate what level of device your project is targeting, you can use a new AndroidManifest.xml element to specify hardware that is required for your application to run properly.
You can add one or more <uses-configuration> elements inside the <manifest> element. Each <uses-configuration> element specifies one valid configuration of hardware that your application will work with.
At the present time, there are five possible hardware requirements you can specify this way:
• android:reqFiveWayNav to indicate you need a 5-way navigation pointing device of some form (e.g., android:reqFiveWayNav='true')
• android:reqNavigation to restrict the 5-way navigation pointing device to a specific type (e.g., android:reqNavigation='trackball')
• android:reqHardKeyboard to specify if a hardware (physical) keyboard is required (e.g., android:reqHardKeyboard='true')
• android:reqKeyboardType, probably used in conjunction with android:reqHardKeyboard, to indicate a specific type of hardware keyboard that is required (e.g., android:reqKeyboardType='qwerty')
• android:reqTouchScreen to indicate what type of touchscreen is required, if any (e.g., android:reqTouchScreen='finger')
Add and Subtract
Since the Android M5 SDK in the summer of 2008, Google Maps has been available to application developers willing to agree to the terms and conditions. However, since Google Maps is not part of the open source Android project, there was always the possibility that some Android devices would not have Google Maps on them. For example, anyone porting Android via the open source project to existing hardware on a “homebrew” basis would unlikely be in a position to license Google Maps.
To accommodate this and similar scenarios with other possible technology, Android 1.5 has introduced a more formal add-on mechanism. You can see this with the target ID system, whereby some targets have Google Maps and others do not. If a device manufacturer decides to add some APIs to their devices that are unique to them, presumably they could use this same add-on system to help developers target their devices. This also opens up the possibility for other platform-level optional components, particularly ones that might need to be licensed, such as the oft-rumored Adobe Flash add-on.
Slide and Scroll
Android 1.5 introduces some new widgets, notably SlidingDrawer and HorizontalScrollView.
SlidingDrawer introduces a container akin to the one on the home screen used to hold the application icons. You control the image to use for the drawer “handle” and the contents to go in the drawer. You can also control the orientation, to determine if the drawer opens from the bottom or the side. Then, you can add listeners to monitor the state of the drawer, or toggle the state yourself, if desired.
As the name suggests, HorizontalScrollView works just like the original ScrollView except that it scrolls horizontally, not vertically.
Squeezably Soft
With the May 2009 debut of the HTC Magic, we now have Android phones lacking hardware keyboards. This makes text entry rather difficult… except that Android 1.5 added in support for soft keyboards. Soft keyboards also help for internationalization, as the user is not limited to the particulars of whatever hardware keyboard their device may actually have.
Soft keyboards take effect automatically, for basic functionality. The EditText widgets in your layout will cause the soft keyboard to spring up, assuming the device either does not have a QWERTY keyboard (e.g., HTC Magic) or is being held with the keyboard closed (e.g., T-Mobile G1 in portrait mode) as seen in Figure A-1.
Figure A-1.
You can tailor the behavior of the soft keyboard in your layouts or via Java code. For example, in the screenshot shown previously, you will see a “Next” button in the lower-right corner. By default, Android will take a guess as what to use this “action button” for — in this case, it moves you to the next field. You can add attributes to your layout to control what the caption is for this button, and what actually occurs when the action button is tapped. So, for example, if you are allowing people to enter a URL to visit in a Web browser, you might rename the action button to “Go” and have it launch the Browser application upon the typed-in URL.
You can also provide light control over what sort of keyboard is displayed by indicating what sort of text entry is supposed to occur in the EditText. For example, you can indicate that the android:inputType is textEmailAddress, which will ensure an @ key is available without having to use a soft shift key.
