telos EDV Systementwicklung GmbH
Mobile Application Development
telos offers application development services for mobile devices like cellphones and PDAs for several years now. Even though it takes a lot of experience and knowledge to create professional and reliable software for these environments, this article provides a hands-on introduction for beginners on how to write a small mobile application in the Java programming language.
If you require a professionally developed custom application, please don't hesitate to contact our sales department for further details.
The days when mobile phones are used just for making phone calls are over. Cell phone advertisements leaves you with the impression that making calls and receiving short messages are only miscellaneous features of those multimedia phones with functions like bluetooth, MMS, gaming, organizer, downloadable ringtones and of course with the ability to customize the welcome logo.
The reason for this feature boosting is apparent. The phone vendors need to sell new devices on a mature and saturated market. Now that almost every person has bought a "ringing box", the industry needs to focus on replacement. The challenge is to get people, who already own a working cellphone, into the shop to buy a new one. But the phone manufacturers are not the only ones looking for new sources of revenue. As the rates for phone calls slowly drop the GSM providers are desperately looking for new hip gadgets especially designed for their younger customers. Games, logos and ringtones to download are currently the deals and it is understood that the providers charge for each of those downloads.
On the other hand the latest music hits don't sound and games don’t run well on antiquated phones. This explains why all major GSM providers are interested in bringing new feature-rich multimedia phones to the market.
One of these features, contained in almost every newer phone, is the ability to run custom applications written in a popular programming language called Java. Such programs can be downloaded and removed, just like on an ordinary PC. Tens of millions of Java-enabled devices are currently shipped. According to 
Nokia, the clearly defined goal of this technology is to allow the GSM providers to offer so-called value-added services to their subscribers.The tools, which are needed to develop Java phone applications, can be obtained free of charge and are available to everyone.
Finding a suitable, small, usable, easy-to-implement application is not easy, thus we finally decided to implement the "Knaus-Ogino method". This is a simple form of natural family planning which attempts to determine the fertile days of a woman by averaging the length of the monthly cycle and estimating the most probable days of ovulation. This application - which should of course be taken with the necessary sense of humor - demonstrates various aspects of the Java programming environment for mobile devices:
- How to built a simple application
- How to create a simple user interface
- Using a database, i.e. a persistent storage
- Working with the calendar
Using this application is straight forward. At the top of the screen a calendar date can be selected. At the very bottom of the screen a day can be marked as being the first day of a monthly period. This needs to be done for at least 5 months in a row. In the middle of the screen an indicator shows if the day is "safe". One of the interesting aspects about this application is that the actual appearance of the user controls fully depend on the device. The date field may be a text field or a full calendar on which the user can select a day. This is not specified because the application uses a high level function for entering a date value. This is necessary if the software is written to support a wide range of phones with totally different screen size and hardware resources.
All we need to write our own java application can be downloaded free of charge from the internet, like many other Java development tools. Here is what we need and where to get it:
Installing this couple is rather straight forward as long as you install the JDK first. There are about half a dozen development environments out which support mobile applications. One of the more interesting packages is Eclipse and a plug-in module called EclipseMe. Since discussing these tools is by far beyond the scope of this introduction, we use the puristic WTK toolbar which comes with the wireless toolkit we have just installed. It contains a stripped down development environment, even without a text editor, but we can simply use wordpad for this job.
First of all, it is just like any other Java application. It is a set of compiled class files except that one more protocol is involved in the code generation process which takes the output of a regular Java compilation and produces so-called preverified classes. This step is needed to allow a simpler implementation of the run-time system of the phone itself. Fortunately, one of the few things the wireless toolbar does for us is to make the compilation process automatic. Little helpers, like an emulator, are provided, too, to let a phone predict the requirements of an application before downloading the whole code to the phone.
All class-files are bundled together with a file called manifest file into a .jar-archive making a complete download package consisting of these two files. To each .jar-archive belongs a .jad-file consisting of necessary information like data size. The manifest file is a simple text file discribing the application.
There are numerous ways to get the application running on the mobile. The providers prefer a download over the air and for an extra-high rate and there are in fact phones which do not allow any other way of loading a custom software. If this is the case, we can create a rudimentary WML page and put the code on some server which is able to deliver WAP content. However, especially the more advanced models allow to download applications via a PC connection. Nokia for instance lets the user do this right from the PC Suite with a mouse click.
The basic outline of a mobile application is pretty much dictated by the runtime system requirements and the API concepts. There is simply no choice but to follow the object-oriented design found in all other Java programs, too. All applications need to provide a main class derived from
javax.microedition.midlet.MIDlet
This is where the entry points are defined. An application can be in the following states:
- Active: The application is running and may use system resources
- Paused: The application is temporarily paused because another application needs all resources, e.g. an incoming phone call
- Destroy: The application has been terminated and all resources except for persistent memory need to be cleared
As with all other major frameworks, which provide graphics and user interaction, it is important to forget about a main program from which all activities are started. Instead we provide handlers for various events generated by the system and starting the application is just one of them. For our example we have chosen an application which is simple enough to be self-explaining. Hence, the following sections only describe a couple of aspects which are somewhat particular.
One aspect of our application is that certain data needs to survive the end of the program. Once the starting day of a monthly cycle has been entered it should not be forgotten for the next run. Otherwise the user would need to enter all data everytime he - or she - uses the application. Mobile devices are battery-powered and therefore there is a running risk of suddenly running out of power which results in a premature termination of all active software. In order to cooperate with this the MIDP API provides a very basic database management system RMS. Essentially this is a mechanism for making a sequence of bytes persistent and assigning a unique identification to it which can be used to later retrieve the data again. Inserting and especially deleting records is not exactly trivial because the API requires that for sorting and comparing data elements a separate class is provided or - to be more precise - a separate interface is implemented. Once a record is found it can be retrieved - but not so its ID. However, this ID is needed to delete it. Developers discussed a number of rather clumsy solutions for this problem, so we hope our approach using a comparator class is a bit more straight forward and robust.
Dates are represented in Java using milliseconds passed since January 1st 1970. Since we do need to calculate with whole days a lot but are not at all interested in a millisecond resolution the application translates all dates into: Days passed Jan. 1st 1970. This reduces the size of the data storage for a date from “long” to “int” and it is much more handy for the calculations we need to do. In addition int-operations perform much faster than long-operations on most platforms and this consideration is worth thinking about on a mobile phone without that Pentium IV inside.
http://www.telos.info/
