Android application tour Have you ever downloaded an application’s source code, excited to get access to all of

12.2 Android application tour Have you ever downloaded an application’s source code, excited to get access to all of

that code, but once you did, it was a little overwhelming? You want to make your own changes, to put your own spin on the code, but you unzip the file into all of the vari- ous subdirectories, and you just don’t know where to start. Before we jump directly into examining the source code, we need to pay a little attention to the architecture, in particular the flow from one screen to the next.

12.2.1 Application flow In this section we will examine the application flow to better understand the relation

among the application’s functionality, the UI, and the classes used to deliver this func- tionality. Doing this process up front helps ensure that the application delivers the needed functionality and assists in defining which classes we require when it comes time to start coding, which is soon! Figure 12.3 shows the relation between the high-level

Splash Screen

Main Screen

Refresh Jobs

Manage Jobs

#7 Show Job Details

Capture Signature (Launch Google Maps)

Look up Product Info

No

(Launch Browser)

Job Closed?

Yes

Display Signature

(Launch Browser)

Figure 12.3 Application flow

Android application tour

classes in the application, which are implemented as an Android Activity as well as interaction with other services available in Android.

Here is the procession of steps in the application:

1 The application is selected from the application launch screen on the Android device.

2 The application splash screen displays. Why? Some applications require setup time to get data structures initialized. As a practical matter, such time-consuming behavior is discouraged on a mobile device; however, it is an important aspect to application design, so it is included in this sample application.

3 The main screen displays the currently configured user and server settings, along with three easy-to-hit-with-your-finger buttons.

4 The Refresh Jobs button initiates a download procedure to fetch the currently available jobs for this mobile worker from the configured server. The download includes a ProgressDialog, which is discussed later in this chapter.

5 The Settings button brings up a screen that allows the configuration of the user and server settings.

6 Selecting Manage Jobs lets our mobile worker review the available jobs assigned to him and proceed with further steps specific to a chosen job.

7 Selecting a job from the list of jobs on the Manage Jobs screen brings up the Show Job Details screen with the specific job information listed. This screen lists the available information about the job and presents three addi- tional buttons.

8 The Map Job Location button initiates a geo query on the device using an Intent . The default handler for this Intent is the Maps application.

9 Because our mobile worker may not know much about the product he is being asked to service, each job includes a product information URL. Clicking this button brings up the built-in browser and takes the mobile worker to a (hope- fully) helpful internet resource. This may be an online manual or an instruc- tional video.

10 The behavior of the third button depends on the current status of the job. If the job is still marked OPEN, this button is used to initiate the closeout or com- pletion of this job.

When the close procedure is selected, the application presents an empty can- vas upon which the customer can take the stylus (assuming a touch screen–capable Android device, of course!) and sign that the work is complete.

A menu on that screen presents two options: Sign & Close or Cancel. If the Sign & Close option is selected, the application submits the signature as a JPEG image to the server, and the server marks the job as CLOSED. In addition, the local copy of the job is marked as CLOSED. The Cancel button causes the Show Job Details screen to be restored.

11 If the job being viewed has already been closed, the browser window is opened to a page displaying the previously captured signature.

C HAPTER 12 Putting it all together–the Field Service Application

Now that we have a pretty good feel for what our requirements are and how we are going to tackle the problem from a functionality and application-flow perspective, let’s examine the code that delivers this functionality.

12.2.2 Code road map The source code for this application consists of 12 Java source files, one of which is the

R.java file, which you will recall is automatically generated based on the resources in the application. This section presents a quick introduction to each of these files. No code is explained yet; we just want to know a little bit about each file, and then it will

be time to jump into the application, step-by-step. Table 12.1 lists the source files in the Android Field Service Application.

Table 12.1 The source files used to implement the Field Service Application Source Filename

Description

Splash.java

Activity provides splash screen functionality.

ShowSettings.java Activity provides management of username and server URL address. FieldService.java

Activity provides the main screen of the application. RefreshJobs.java

Activity interacts with server to obtain updated list of jobs. ManageJobs.java

Activity provides access to list of jobs.

ShowJob.java Activity provides detailed information on a specific job, such as an address lookup, or initiates the signature-capture process.

CloseJob.java Activity collects electronic signature and interacts with the server to upload images and mark jobs as CLOSED.

R.java Automatically generated source file representing identifiers in the resources. Prefs.java

Helper class encapsulating SharedPreferences .

JobEntry.java Class that represents a job. Includes helpful methods used when passing JobEntry objects from one Activity to another.

JobList.java Class representing the complete list of JobEntry objects. Includes methods for marshaling and unmarshaling to nonvolatile storage.

JobListHandler.java Class used for parsing XML document containing job data.

The application also relies on layout resources to define the visual aspect of the UI. In addition to the layout xml files, an image used by the Splash Activity is placed in the drawable subfolder of the res folder along with the stock Android icon image. This icon is used for the home application launch screen. Figure 12.4 depicts the resources used in the application.

In an effort to make navigating the code as easy as possible, the Field Service Application resource files are presented in table 12.2. Note that each of these is clearly seen in figure 12.4,

Figure 12.4 Resources

which is a screen shot from our project open in Eclipse.

used in the application

Android application tour

Table 12.2 Resource files used in the sample application Filename

Description

android.jpg

Image used in the Splash Activity .

icon.jpg Image used in the application launcher. fieldservice.xml

Layout for main application screen, FieldService Activity . managejobs.xml

Layout for the list of jobs, ManageJobs Activity .

refreshjobs.xml Layout for the screen shown when refreshing job list, RefreshJobs Activity . showjob.xml

Layout for job detail screen, ShowJob Activity .

showsettings.xml Layout for configuration/settings screen, ShowSettings Activity . splash.xml

Layout for splash screen, Splash Activity .

strings.xml Strings file containing extracted strings. Ideally all text is contained in a strings file for ease of localization. This application’s file contains only the application title.

An examination of the source files in this application tells us that we have more than one Activity in use. In order to enable navigation between one Activity and the next, our application must inform Android of the existence of these Activity classes. If you recall from chapter 1, this registration step is accomplished with the AndroidManifest.xml file.

12.2.3 AndroidManifest.xml Every Android application requires a manifest file to let Android properly “wire things

up” when an Intent is handled and needs to be dispatched. Let’s look at the AndroidManifest.xml file used by our application, which is presented in listing 12.1.

Listing 12.1 The Field Service Application’s AndroidManifest.xml file

<?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android"

package="com.msi.manning.UnlockingAndroid"> <application android:icon="@drawable/icon">

<activity android:name=".Splash"

Splash Activity is

android:label="@string/app_name">

the entry point

<intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" />

</intent-filter> </activity>

Intent filter for main

<activity android:name=".FieldService" >

launcher visibility

</activity> <activity android:name=".RefreshJobs" > </activity>

Application’s

<activity android:name=".ManageJobs" >

defined

</activity>

Activity list

<activity android:name=".ShowJob" > </activity> <activity android:name=".CloseJob" >

C HAPTER 12 Putting it all together–the Field Service Application

</activity> <activity android:name=".ShowSettings" > </activity>

Application’s defined Activity list

</application> <uses-permission android:name="android.permission.INTERNET"> </uses-permission> </manifest>

Required permission for internet access