Now that we 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. We will be deep into code before too long, but for now we will discuss the available options and continue to examine things from a requirements perspective, building to a proposed 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 numerous, but we will make the simple decision to use MySQL, a popular open source database. Not only are there multiple mobile workers, but the organization we are 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 has been decided to host the MySQL database in a data center, where it is accessed via a browser-based application. For this sample application, the dispatcher system is super simple and written in PHP.
Data storage requirements on the mobile device are quite 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 out a ContentProvider, so we've made the decision 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. While more complex and sophisticated protocols can be employed, such as Simple Object Access Protocol (SOAP), this application simply requests an XML file of assigned jobs and submits an image file representing the captured signature. 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 correctjob list, and the dispatchers can assign jobs to workers in the field.
Figure 12.2 The Field Service Application and dispatchers both leverage PHP transactions.
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 Cambridge. Because of these requirements, we have 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 are easy to access and not secured.
We have identified the functional requirements, defined the data elements necessary to satisfy those objectives, and selected the preferred deployment platform. It is time to examine the Android application.
Was this article helpful?