his article walks through creating a Java mobile application for a J2ME-enabled mobile camera device. While it does not cover all of the neccesary aspects in depth, it does describe how to build the basic structure for the application. The completed Java mobile application will enable the user to do:
- Take a picture.
- Fill out a form to provide some information about the picture.
- Send the picture and information to a server as data.
Then the mobile application can access this data on the server, allowing the user to view and edit it later. A possible use case for this application would be an insurance adjuster in the field assessing an auto claim. The adjuster would use a mobile camera device to take a photo of the damage, add vital information to it (client name, account number, VIN, date, etc.), and send the data to a central server at the insurance company.
To provide this functionality, the application will be part of a larger architecture that includes the following:
- The mobile application
- A deployment server
- A server-side gateway script
- A server-side database
The code for the application will employ the following mobile Java technologies:
- J2ME (Java 2 Micro Edition), now Java ME (Java Micro Edition): targets mobile devices and embedded systems
- MIDP (Mobile Information Device Profile): targets devices with an intermittent network connection and low memory, such as mobile phones
- Midlet: an application written for MIDP
MIDP is composed of the following main concepts:
- User interface: User Interface includes two levels: the high level (text input, date input, list of items, etc.) is based on widgets; the low level is based on a canvas (at the pixels level).
- Local storage of data: The local storage of data (RMS: Record Management System) is a simple record-oriented database to persistently store information.
- Communication: The communication is based on a generic framework (GCF: Generic Communications Framework) that supports HTTP, HTTPS, sockets, etc.
- Multimedia: MIDP supports sound, vibrator, backlight, camera control, and video.
The target J2ME-enabled camera devices for the application have a number of constraints that will shape the scope of the application. Table 1 lists the main constraints a developer must understand and some solutions to address them.
Table 1. Main Constraints of Mobile Devices |
Constraints | Suggested Solutions |
---|---|
Limited memory (JAR file) |
|
Limited memory (heap memory) |
|
Limited processor power | Profile slow-running code to find the bottlenecks. |
Limited storage |
|
Limited bandwidth | Use a different type of connection (for example, intermittent connections). |
Limited screen size | Employ mechanisms such as zoom, scrollbars, etc. |
Of course, a small mobile application that uses common features will run up against fewer constraints.
Building the Structure of the Application
The common procedure for deploying a mobile Java application is to use a WAP/XHTML site and insert a link to the application in a page on the site. Users then download the application by opening this link. A developer can send this link by SMS (Short Message Service) as well.
The gateway script for the project has to receive data from and return data to the mobile application. This gateway script can be written in Java, PHP, ASP, or any such scripting language. The script will store data in a traditional database with SQL requests.
The application uses the Mobile Media API (MMAPI) to enable the picture-taking function on the device, but not all mobile devices support MMAPI for taking a pictures. To find out whether or not a device supports this feature, you can use this method:
public static boolean isSupported() { String supports = System.getProperty("supports.video.capture"); if (supports == null || !supports.equals("true")) return false; else return true;}
If it returns true, the device can take snapshots. If not, the mobile application will:
- Store data
- Display data
- Take a photo
- Send the photo to a web server
The server will have to receive data sent by the mobile application, store them in a database, and then return data to the mobile application.
Storing Data
To save data, you have to use RMS (Record Management System). As a persistent storage space, RMS ensures that the stored values remain even when the mobile phone is turned off. Data are stored in a recordstore (« data », in this example), which is a collection of records. Each record is a byte array. Listing 1 is an example of the source code for storing data.
Data are stored in the ConfigurationData class. The getData() method returns the data, and the setData() method stores the data. The setDefaultValues() method returns the default value.
The main methods are save() and read(). To save data, you open the recordstore « data ». If it fails, the recordstore doesn’t exist and you have to add the record. If the record exists, you update the record. To read data, you open the recordstore. If it doesn’t exist, you create one. If there is no record or if you have just created one, you just return the default value. Otherwise, you return the first record of the record store.
Displaying Data
To use the stored data, you use a form. In this example, you display the data in a user component, a TextField. To initialize its value, you call the intialize() method. This method calls the stored data by calling getData().
When the data is updated in the form, the user activates the « OK » command, which calls the returnValues() method. The first step is to save the data in the storage class (« ConfigurationData »). Then you save and reload data in the recordstore.
If the user activates the « Cancel » command, you open the screen « menu ». Listing 2 shows the code.
Taking a Photo
To use the camera, the first step is to use the locator (« capture:// video ») in the createPlayer() method. After getting the control « VideoControl », you can start the display by calling the start() method. (See Listing 3 for the complete code for taking a photo.) Pressing the FIRE key starts a thread, in which the mobile phone takes a snapshot by calling the getSnapshot() method. When the picture is taken, data are stored in a byte array (data[]). Then you can convert this array into an image you can display.
To tailor the code to a specific device, you have to specify the encoding. The encodings list depends on the model of the mobile device you’re targeting. You can get this list by using the FormEncodings class, which displays the encodings list supported on your target device. The split() method splits the encodings list with a space separator (see Listing 4).
Sending Data via HTTP
To send data via HTTP, you again have to use a thread. You open and send data in the run() method. During the upload process, you can use a FormWait class to display a gauge. To upload a photo, you have to use the POST method (HttpConnection.POST). The data to send are stored in the dataToSend byte array and sent in the « os.write » line.
The web server returns the content length, and then you read data with the read() method (see Listing 5 for the complete code).
A Foundation to Build On
With all the previous steps completed, you have built the main structure of the mobile application, complete with a deployment server, a server-side gateway script, and a server-side database. If you decide to build upon this skeleton and implement a more robust application, you should take into account are few important factors not discussed in this article:
- Extremely low memory and communication problems with the mobile network
- Support for specific behaviors, such as variations of the locator to take snapshots and not returning content length from the web server.
- Porting the mobile application to each mobile device model you support