Programming mobile handheld devices
written by Jon Berg <jon.berg|a|turtlemeat.com>

Effective use of limited resources
Resource requirements For desktop application development it is usual to develop applications that use framework that include a lot of functionality that you do not use. Examples of such are the .Net framework from Microsoft, and J2SE from Sun Microsystems. When applications made with these the performance is often not an issue since they will run on machines equipped with plenty of hardware. Some megabytes in memory requirements or some extra clock cycles are not an issue, and ease of developing applications is often higher prioritized. A modest personal PCs today got at least a 1GHz processor, 256 Mb Ram, some gigabytes of disk storage. Mobile devices can have as little as a 20 MHz processor and 100 Kb of memory [2]. This makes a huge gap in the available resources found on desktop systems and handheld mobile systems.

J2ME vs. J2SE
The great thing about letting developers for mobile devices develop in somewhat the same environment as they do for desktop applications is that it allows a great deal of knowledge to be reused. The application developers do not have to learn a whole new programming language and a new set of programming libraries. This makes adaptation to the new mobile device environment easy and a more flat learning curve.

One of the fundamental thoughts of Java is "write once, run anywhere". This great news is with some modifications. Handheld mobile devices are more limited with concerns to processing power, memory and network bandwidth will put limitations on what applications can be run. The main transitions a developer must do to start programming on these new devices are to learn the limitations in the programming environment and to scale the application down so the applications demand for resources match the mobile handheld device.

In theory most AWT-based J2SE applications run on PersonalJava and J2ME Personal profile without modifications [2]. This represent what is meant by code portability of Java, but it fails when it comes to performance since the applications are not made for the resource constraint environment.

Design paradigms for wireless mobile devices
Application developers for handheld mobile devices have to make applications that will run and also give the user a feel of a responsive application. All the limitations discussed puts a lot of constraints on what systems can be built on these devices and how the systems should be built. There is no final solution on how things should be designed and what type of applications would work in the wireless mobile device environment. A thin client model is a model that can be very attractive for mobile devices. Also the client server model can be useful.

The thin client [8] model consists of an application server computer where the actual
applications are run and a client. The application server then sends the view to the client. The view is data that represents the user interface. The client only has a very small program installed that is capable of showing a user interface from the view data. The client contains very little or no application logic. When the client interacts with the user interface the actions are sent back to the application server where the actual computation happens. The power of this model is that the program that has to be installed on the client is very small. Using a web browser and interacting with a webpage can be considered an example of this. The webpage must contain some application logic for this definition to be valid. An example is a web banking application; the banking application logic is performed in the back-end system of the bank server and the client only get the webpage as the interface to interact with the bank application.

The client-server architecture [9] splits an application in two parts where a part of the operations run the client and other parts run on the server. The client-server model is similar to the thin client, but there are some differences. A thin client is always getting the view of the application from the server. In a client-server architecture the client may get data (as in a database) from the server and use it for processing done on the client side. In a client-server architecture the client may send some heavy-duty processing to a server and get the result back. The client-server architecture is a more generic concept that can be used for many types of dividing workload between machines. A thin client model is about splitting out the graphical user interface from the application processing.

These concepts runs back to the early 80's where computers where expensive and had limited processing power. It was rational to buy a few expensive servers that did the heavy work and a lot of cheap terminals that people used to work on towards the servers. The situation for handheld mobile devices is somewhat similar as it was in the 80's when it comes to capacity limitations for the hardware.

J2ME optimizations
Since the device has limited hardware it is important to optimize the application to get it as small and fast as possible.

Lightweight libraries
A lot of existing Java code can be used in J2ME applications, but as pointed out this code is not scaled down to fit the limited hardware it has to run on for handheld mobile devices. If applications are created with 3rd party libraries these should be created or optimized for use with J2ME. Example of tasks one would use libraries for are Xml parsing, database operations, cryptography, messaging and User Interface. Libraries that use proprietary APIs from the supplier of the device could also be considered, these are often very small and fast. The drawback with using software that is specially designed for a few devices is that they reduce portability. If software based on such libraries is to be used on other devices that do not support the APIs the library is based on the software has to be rewritten. Proprietary APIs may increase the development cost and limit the market potential for a software product.

Minimize application footprint
Mobile devices have limited storage and memory. It is important to get the actual file
that represents the application software as small as possible to minimize the amount of storage required to install the software. It is also important to minimize the memory requirement during runtime. [10] Many current MIDP devices limit the application sizes to 50K or less. [2] Techniques used to minimize the application footprints are to optimize the packing process and partition the application. Optimizing the packing process involves stripping out any unnecessary code. Stripping out library files that are not used can be done automatically by with programming tools. Packing of the code can also be archived with obfuscation tools, that replace long names of classes, methods and variables with short ones. Partitioning the application reduces runtime memory footprint because only classes that are actually used are loaded into memory. Partitioning can also be archived by partitioning an application into several MIDlets. [2] Other techniques to get smaller code is strip out any code you do not use that is generated by programming tools like anonymous classes and inner classes. These are often used to implement event listeners, but by moving them into one class that implements all these interfaces you optimize it into one class. An example of this is that one empty class compiles into a file that is 200 bytes. One should also always try to maximize the use of pre-installed classes; it is a waste to make your own collection classes like Vector or Hashtable.

Garbage Collection
A lot of the user friendlyness for the programmer in Java comes from the automatically memory management also known as Garbage Collection. In an automatic memory management system the system controls the allocation and deallocation of memory. This eases a lot of the work for the programmer. In programming languages like C++, the programmer has to manually call new and delete for creation and deletion of space for objects in memory. It is also a source for errors, since complex code and algorithms can result in deleting objects before they should, or not deleting them at all which in turn leads to memory leak. There is some overhead in performing the memory management. In desktop systems this may not be noticeable. In a handheld device with little memory the garbage collector must run more often to reclaim memory. This takes up precious CPU time. [2] To minimize the work for the garbage collector one should try to reuse existing objects, use arrays and the StringBuffer class, close network and RMS records quickly after use, free resources used in native libraries. When concatenating a lot of String objects one should use StringBuffer since this is a lot more effectively than repeatedly using the "+" operator. The garbage collector does not work inside device native libraries. One must refer to the documentation on what methods native libraries use to properly close resources.

Linux
Setup Software Raid 1 with LVM
Setup Linux with Desktop

Turtlmeat.com 2004-2011 ©