Mobilize Your Java Applications with Java ME Technologies

Mobilize Your Java Applications with Java ME Technologies

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:

  1. Take a picture.
  2. Fill out a form to provide some information about the picture.
  3. 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
ConstraintsSuggested Solutions
Limited memory (JAR file)
  • Reduce the size of the resources (especially images).
  • Reduce the number of classes in the JAR file.
  • Limited memory (heap memory)
  • Minimize the use of memory.
  • Eliminate instantiation of objects wherever possible.
  • Mark as available all the large allocations of memory.
  • Limited processor powerProfile slow-running code to find the bottlenecks.
    Limited storage
  • Use the JAR file for storage.
  • Read from the network.
  • Limited bandwidthUse a different type of connection (for example, intermittent connections).
    Limited screen sizeEmploy 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("");  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


    About Our Editorial Process

    At DevX, we’re dedicated to tech entrepreneurship. Our team closely follows industry shifts, new products, AI breakthroughs, technology trends, and funding announcements. Articles undergo thorough editing to ensure accuracy and clarity, reflecting DevX’s style and supporting entrepreneurs in the tech sphere.

    See our full editorial policy.

    About Our Journalist