Mark Murphy - Beginning Android

packagecom.commonsware.android.search;

importandroid.app.SearchManager;

importandroid.content.Intent;

importandroid.widget.ArrayAdapter;

importandroid.widget.ListAdapter;

importjava.util.ArrayList;

importjava.util.List;

public classLoremSearch extendsLoremBase {

@Override

ListAdapter makeMeAnAdapter(Intent intent) {

ListAdapter adapter = null;

if(intent. getAction(). equals(Intent.ACTION_SEARCH)) {

String query = intent. getStringExtra(SearchManager.QUERY);

List results = searchItems(query);

adapter = newArrayAdapter( this,

android.R.layout.simple_list_item_1, results);

setTitle("LoremSearch for: " + query);

}

return(adapter);

}

privateList searchItems(String query) {

List results = newArrayList();

for(String item : items) {

if(item. indexOf(query) - 1) {

results. add(item);

}

}

return(results);

}

}

While this implements search, it doesn’t tie it into the Android search system. That requires a few changes to the auto-generated AndroidManifest.xmlfile:

package="com.commonsware.android.search">

android:value=".LoremSearch" />

android:name=".LoremSearch"

android:label="LoremSearch"

android:launchMode="singleTop">

android:resource="@xml/searchable" />

The changes needed are as follows:

1. The LoremDemomain activity gets a meta-dataelement, with an android:nameof android.app.default_searchableand a android:valueof the search implementation class ( .LoremSearch).

2. The LoremSearchactivity gets an intent filter for android.intent.action.SEARCH, so search intents will be picked up.

3. The LoremSearchactivity is set to have android:launchMode="singleTop", which means at most one instance of this activity will be open at any time so we don’t wind up with a whole bunch of little search activities cluttering up the activity stack.

4. The LoremSearchactivity gets a meta-dataelement, with an android:nameof android.app.searchableand a android:valueof an XML resource containing more information about the search facility offered by this activity ( @xml/searchable).

android:label="@string/searchLabel"

android:hint="@string/searchHint" />

That XML resource provides two bits of information today:

• What name should appear in the search domain button to the right of the search field, identifying to the user where they are searching ( android:label)

• What hint text should appear in the search field, to give the user a clue as to what they should be typing in ( android:hint)

Given all that, search is now available — Android knows your application is searchable and what search domain to use when searching from the main activity, and the activity knows how to do the search.

The options menu for this application has both local and global search options. In the case of local search, we just call onSearchRequested(); in the case of global search, we call startSearch()with true in the last parameter, indicating the scope is global.

Typing in a letter or two then clicking Search, will bring up the search activity and the subset of words containing what you typed, with your search query in the activity title bar. You can get the same effect if you just start typing in the main activity, since it is set up for triggering a local search.

The Android SDK is more than a library of Java classes and API calls. It also includes a number of tools to assist in application development.

Much of the focus has been on the Eclipse plug-in, to integrate Android development with that IDE. Secondary emphasis has been placed on the plug-in’s equivalents for use in other IDEs or without an IDE, such as adb for communicating with a running emulator.

This chapter will cover other tools beyond those two groups.

Android comes with a Hierarchy Viewer tool, designed to help you visualize your layouts as they are seen in a running activity in a running emulator. For example, you can determine how much space a certain widget is taking up, or try to find where a widget is hiding that does not appear on the screen.

To use the Hierarchy Viewer, you first need to fire up your emulator, install your application, launch your activity, and navigate to the spot you wish to examine. As you can see from Figure 37-1, for illustration purposes, we’ll use the ReadWrite demo application we introduced back in Chapter 18.

Figure 37-1. ReadWrite demo application

You can launch the Hierarchy Viewer via the hierarchyviewerprogram, found in the tools/directory in your Android SDK installation. This brings up the main Hierarchy Viewer window shown in Figure 37-2.

Figure 37-2. Hierarchy Viewer main window

The list on the left shows the various emulators you have opened. The number after the hyphen should line up with the number in parentheses in your emulator’s title bar.

Clicking on an emulator shows, on the right, the list of windows available for examination as you can see in Figure 37-3.

Figure 37-3. Hierarchy Viewer list of available windows

Note how there are many other windows besides our open activity, including the Launcher (i.e., the home screen), the Keyguard (i.e., the “Press Menu to Unlock” black screen you get when first opening the emulator), and so on. Your activity will be identified by application package and class (e.g., com.commonsware.android.files/...).

Where things get interesting, though, is when you choose a window and click Load View Hierarchy. After a few seconds, the details spring into view, in a perspective called the Layout View (see Figure 37-4).

Figure 37-4. Hierarchy Viewer Layout View