We’ve established that our mobile worker will be carrying two things: a set of hand tools and an Android device. Fortunately, in this book we’re not concerned with the applicability of the hand tools in his toolbox, leaving us free to focus on the
capabilities and features of a field service application running on the Android plat- form. In this section, we define the basic and high-level application requirements.
12.1.1 Core requirements of the application
Before diving into the bits and bytes of data requirements and application features, it’s helpful to enumerate some basic requirements and assumptions about our field service application. Here are a few items that come to mind for such an application:
The mobile worker is dispatched by a home office/dispatching authority, which takes care of prioritizing and distributing job orders to the appropriate technician.
The mobile worker is carrying an Android device, which has full data service—a device capable of browsing rich web content. The application needs to access the internet for data transfer as well.
The home office dispatch system and the mobile worker share data via a wire- less internet connection on an Android device; a laptop computer isn’t neces- sary or even desired.
A business requirement is the proof of completion of work, most readily accom- plished with the capture of a customer’s signature. Of course, an electronic sig- nature is preferred.
The home office wants to receive job completion information as soon as possi- ble, as this accelerates the invoicing process, which improves cash flow.
The mobile worker is also eager to perform as many jobs as possible, because he’s paid by the job, not by the hour, so getting access to new job information as quickly as possible is a benefit to him.
The mobile worker needs information resources in the field and can use as much information as possible about the problem he’s being asked to resolve.
The mobile worker may have to place orders for replacement parts while in the field.
The mobile worker will require navigation assistance, as he’s likely covering a rather large geographic area.
The mobile worker needs an intuitive application—one that’s simple to use with a minimum number of requirements.
There are likely additional requirements for such an application, but this list is ade- quate for our purposes. One of the most glaring omissions from our list is security.
Security in this kind of an application comes down to two fundamental aspects.
The first is physical security of the Android device. Our assumption is that the device itself is locked and only the authorized worker is using it. A bit nạve perhaps, but there are more important topics we need to cover in this chapter. If this bothers you, just assume there’s a sign-in screen with a password field that pops up at the most inconvenient times, forcing you to tap in your password on a small keypad. Feel better now? The second security topic is the secure transmission of data between the
Android device and the dispatcher. This is most readily accomplished through the use of a Secure Sockets Layer (SSL) connection whenever required.
The next step in defining this application is to examine the data flows and discuss the kind of information that must be captured to satisfy the functional requirements.
12.1.2 Managing the data
Throughout this chapter, the term job refers to a specific task or event that our mobile worker engages in. For example, a request to replace a hard drive in a computer at the bookstore is a job. A request to upgrade the firmware in the fuel-injection system at the refinery is likewise a job. The home office dispatches one or more jobs to the mobile worker on a regular basis. Certain data elements in the job are helpful to the mobile worker to accomplish his goal of completing the job. This information comes from the home office. Where the home office gets this information isn’t our concern for this application.
In this chapter’s sample application, there are only two pieces of information the mobile worker is responsible for submitting to the dispatcher:
The mobile worker communicates to the home office that a job has been closed,
or completed.
The mobile worker collects an electronic signature from the customer, acknowl- edging that the job has, in fact, been completed.
Figure 12.1 depicts these data flows.
Of course, additional pieces of information exist that may be helpful here, such as the customer’s phone number, the anticipated duration of the job, replacement parts required in the repair (including tracking numbers), any observations about the con- dition of related equipment, and much more. Although important to a real-world application, these pieces of information are extraneous to the goals of this chapter and are left as an exercise for you to extend the application for your own learning and use.
The next objective is to determine how data is stored and transported.
List of jobs sent to a
specific mobile worker Jobs
Home office/dispatcher Mobile worker
Each job contains Job id
Customer name Address City, State, Zip Product needing repair URL to product information Comments
Job status (updated by mobile) Signature (updated by mobile)
Figure 12.1 Data flows between the home office and a mobile worker
12.1.3 Application architecture and integration
Now that you know which entities are responsible for the relevant data elements, and in which direction they flow, let’s look at how the data is stored and exchanged. You’ll be deep into code before too long, but for now we’ll focus on the available options and continue to examine things from a requirements perspective, building to a pro- posed architecture.
At the home office, the dispatcher must manage data for multiple mobile workers.
The best tool for this purpose is a relational database. The options here are numer- ous, but we’ll make the simple decision to use MySQL, a popular open source data- base. Not only are there multiple mobile workers, but the organization we’re building this application for is quite spread out, with employees in multiple markets and time zones. Because of the nature of the dispatching team, it’s been decided to host the MySQL database in a data center, where it’s accessed via a browser-based application.
For this sample application, the dispatcher system is supersimple and written in PHP.1 Data storage requirements on the mobile device are modest. At any point, a given mobile worker may have only a half-dozen or so assigned jobs. Jobs may be assigned at any time, so the mobile worker is encouraged to refresh the list of jobs periodically.
Although you learned about how to use SQLite in chapter 5, we have little need for sharing data between multiple applications and don’t need to build a Content- Provider, so we’ve decided to use an XML file stored on the filesystem to serve as a persistent store of our assigned job list.
The field service application uses HTTP to exchange data with the home office.
Again, we use PHP to build the transactions for exchanging data. Though more com- plex and sophisticated protocols can be employed, such as SOAP, this application sim- ply requests an XML file of assigned jobs and submits an image file representing the captured signature. In fact, SOAP is simple in name only and should be avoided. A better solution that’s coming on strong in the mobile and web space is the JSON for- mat. This architecture is depicted in figure 12.2.
The last item to discuss before diving into the code is configuration. Every mobile worker needs to be identified uniquely. This way, the field service application can retrieve the correct job list, and the dispatchers can assign jobs to workers in the field.
Similarly, the mobile application may need to communicate with different servers, depending on locale. A mobile worker in the United States might use a server located in Chicago, but a worker in the United Kingdom may need to use a server in Cam- bridge. Because of these requirements, we’ve decided that both the mobile worker’s identifier and the server address need to be readily accessed within the application.
Remember, these fields would likely be secured in a deployed application, but for our purposes they’re easy to access and not secured.
1 See Manning’s PHP in Action for details on PHP development: www.manning.com/reiersol/.
We’ve identified the functional requirements, defined the data elements necessary to satisfy those objectives, and selected the preferred deployment platform. The next sec- tion examines the high-level solution to the application’s requirements.