
HOME
stuff you never thought you wanted to know.
|
|
|
|
|
|
Programming mobile handheld devices.
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
Google
Manage your website ads with DFP
Google AdSense for Domains - not so great
Let Google Handle Email for your Domain Name
Page Rank banned by Google
Google's highest ranked web pages
SEO intelligent spam causes irrelevant search results
Google Sandbox
Google ranking factors
How to not give out page rank in web page links
Web Server Programming
Simple Java web server
Simple Python web server
Configuring Apache webserver with .htaccess file
Windows
Turn off the loginscreen in XP, after installing .NET .
Turn off xp login screen unread mail count
What is .NET
Web (webmastering)
Introduction to Cascading style sheets (CSS)
The value of Alexa traffic rank
HTML META tag, not a search engine optimization tool
Create a maintainable webpage with modularization
The www prefix in your domain name
What is RSS and cool things RSS can be used for
MySql backup and restore with phpMyAdmin
Mix Computer related text
Doing business (making money) with Information Technology
Business with Computer Science
Research in Computer Science
Current and future possibilities of Medical Informatics
Tasks that make sense to have automated
Programming handheld mobile devices (overview)
Security tips for the web surfer
Price and Capacity in computer hardware
Java RMI Tutorial.
Microsoft Word
Page numbering in Word
Numbering headers or outlines in Word
Create a List of Figures
Turn off the default collapsing menus in Word
Turtlmeat.com 2004-2011 ©
|