The document provides an overview of best practices for developing mobile applications using J2ME. It discusses keeping applications simple, small, and within the memory limitations of mobile devices. It recommends offloading computations to servers and managing network usage. It also suggests simplifying user interfaces to be suitable for small screens and limiting inputs. Overall, the document outlines strategies for optimizing J2ME applications for resource-constrained mobile environments.

1. U NIT III
Mobile application development
J2ME

2. Overview
 Introduction
 Traditional computing Vs small computing devices
 J2ME Best Practices and Patterns
--Keep Applications Simple
-- Keep Applications Small
--Limit the Use of Memory
--Off-Load Computations to the Server
--Manage Your Application’s Use of a Network connection
--Simplify the User Interface
-- Use Local Variables
--Don’t Concatenate Strings
--Avoid Synchronization
--Thread Group Class Workaround
--Minimize Network Traffic
--Be Careful of the Content of the startApp() Method
 Display class
 Command class
 Item class

3. Introduction
 A small computing device has a radically different
hardware configuration than traditional computing
devices such as desktop computers and servers
 It is for this reason that you must take into account
the device’s hardware configuration when designing
your J2ME application.

4. Traditional computing Vs small
computing devices
 Traditional computing devices are under continuous power from the power grid,
while some small computing devices such as cellular telephones rely on battery
power that diminishes during the course of operation
 Unlike traditional computing devices, mobile small computing devices connect to a
network via a radio or infrared connection whose quality varies depending on the
distance of the device from a network receiver and the strength of the signal
generated by the device.
 programs and data are stored in a small computer device’s memory, commonly
referred to as primary storage. These are lost when the device drops power.
 Data transmission between a mobile small computing device and a traditional
computing device is slow in comparison to a hard-wired network connection
because radio and infrared technology offers a narrower transmission bandwidth
than that found in hard-wired network connections.

5. J2ME Best Practices and Patterns
 Many users of your J2ME application expect the same
response from J2me application as they experience from
desktop computer applications
 J2ME developers have come up with the best way to
solve complex J2ME programming problems.
these techniques are called best practices and patterns.
Best practices are proven design and programming
techniques used to build J2ME systems.
Patterns are routines that solve common programming
problems that occur in such systems.

6. Keep Applications Simple
 Due to resource constraint design a J2ME application by dividing the application into
pieces.
 The divisions of a J2ME application are much finer divisions than those found in a
typical application.
Ex :A common division of a J2ME application is a menu option rather than a menu object
or
menu method of an object. Each menu option is its own MIDlet.
Menu option MIDlets are packaged in the same MIDlet suite along with other MIDlets
related to the application
The best practice is to keep your application design simple. Limit your design
to minimum functionality required to meet user expectations. Place each functional
component in its own MIDlet where possible, and package the application’s MIDlets in
the same MIDlet suite. This enables the device’s application manager to manage MIDlets
and the resources used by MIDlets.

7. Keep Applications Small
 The size of your J2ME application is critical to deploying
the application efficiently.
 Anyone who uses a J2ME application expects the
application to download quickly to the small computing
device and run among other applications on the device.
 A smaller application meets these expectations because
fewer bytes need to be downloaded and stored in memory
on the device.
 The best practice is to remove unnecessary components of
your application in order to reduce the size of the overall
application

8. Limit the Use of Memory
 Design your application to manage memory efficiently. There are two types of memory
management that should be used in the J2ME application. These are overall memory
management and peak time memory management.
 Overall memory management is designed to reduce the total memory requirements of an
application.
 Peak memory management focuses on minimizing the amount of memory the application uses
at times of increased memory usage on the device.
 A primary way to reduce total memory requirements of your application is to avoid using
object types. Instead, use scalar types, which use less memory than object types.
 Always use the minimum data type suited for storing data.
For example, some developers use an int as a binary flag where only one of two values is assigned
to the variable.
A boolean value requires less memory and therefore should be used in place of an int.

9. Limit the Use of Memory
 Peak time memory management requires you to manage garbage collection.
Allocate an object immediately before the object is used in the application
rather than at the beginning of your application.
Allocating memory at the beginning of the application reserves memory long
before the object will be used within the application. This memory could be
utilized by other parts of the application until the application requires the
object.
 Set all references to objects to null once the application no longer needs the
object. This decreases the memory application of the object to the minimum
memory necessary to store an object reference.
 Always reuse objects instead of creating new objects. This reduces both
memory allocation and the need for processing power.
 Reducing the likelihood of exceptions is another technique for lowering
memory usage of your application.

10. Off-Load Computations to the Server
 Small computing devices are designed to run applications that do not require intensive
processing because processing power common to desktop computers is not available on these
devices. This means that you must design your J2ME application to perform minimal
processing on the small computing device.
 There is an alternative that lets you combine the convenience of a small computing device with
an application that requires intense processing.
 The alternative is to build a client-service J2ME application or web services J2ME application.
There are two levels of operation in a client-service application. These are the client level and
the server level.
 The small computing device runs the client level that provides user interface and presentation
functionality to the application. The server-side level processes client requests and returns the
result to the small computing device for presentation to the user. Nearly all processing occurs
on the server side of the application.
 Processing on the client is limited to displaying the user interface, capturing a user request,
opening and maintaining a network connection to the back-end systems, sending (request) and
receiving information , and presenting incoming information to the user of the small
computing device.

11. Manage Your Application’s Use of a
Network connection
 Besides lightening the processing load on the small computing device,
you must also be
concerned about the availability of a network connection
 Some small computing devices are mobile, wireless devices where a
network connection is not always available, and even when available,
the connection might be broken during transmission due to the
positioning of the transmitter and receiver
ex : when moving from one cell to another in a cellular telephone
network
 Although you cannot avoid a break in communication, you can take
steps to reduce the impact on the user of your application. Begin by
keeping transmissions short—transfer the minimum information
necessary to accomplish a task.

12. Manage Your Application’s Use of a
Network connection
 Consider using store-forwarding technology and a server-side agent whenever your
J2ME application requests a lot of information.
 A server-side agent is software running on the server that receives a request from a
mobile device and then retrieves requested information from a data source, which
is very similar to the business logic layer of web services technology. The results of
the query are then held by the agent until the mobile device asks for the nformation,
at which time the information is forwarded to the mobile device.
 The request from the mobile device consists of a small amount of data. The agent
can accumulate large amounts of data from database management software to fulfill
the request and then forward small amounts of data to the mobile device
 Ex: Let’s say your application is designed to retrieve email messages from a server.
Instead of retrieving all emails in an inbox, you can retrieve the “From,” “Subject,”
and “Data received” fields from the last ten emails that were placed in the inbox.
Your J2ME application can present these fields on the screen and then give the user
the options to select an email to read, select a preview for an email, delete an email,
or retrieve the next ten emails. Here the agent stores all the mails of Inbox and only
few are forwarded to the user (store and forward technique)

13. Manage Your Application’s Use of a
Network connection

14. Simplify the User Interface
 Most desktop applications have a standard set of graphical user
interface objects such as text boxes, combo boxes, radio buttons,
check boxes, and push buttons. These objects are accessible to the
user through a mouse, keyboard, and other input devices commonly
associated with a desktop computer.
 However, small computing devices use a variety of user display and
input devices.
 Due to constraint variations of display in small computing devices
the best practice is to
--Limit the amount of user input into your application to simple
menu selections and an occasional few fields of text or numbers,
depending on the design of the small computing device.
--The rule of thumb: a user should be able to interact with your
application by using a thumb while holding the device in one hand.

15. Use Local Variables
 Limited resource is the theme that echoes through design considerations
for applications that run on small computing devices.
 Therefore, it is critical to evaluate processing requirements of each routine
within your application.
 The objective is to exclude routines that increase processing overhead if a
less processing-intense routine can accomplish the same task.
 Data storage is a key area within an application for reducing excessive
processing.
 In many applications, developers assign values to data members of a class
rather than using a local variable.
 Accessing a data member of a class requires more processing steps than
accessing the same data if the data is stored as a local variable.
accessing a local variable is less processing intense than accessing a class
member.
The Best practice is to use Local variables instead of class members where
ever it is possible

16. Don’t Concatenate Strings
 Concatenating strings is another processing drain that can be avoided by designing an
application to eliminate concatenations or at least reduce the number of concatenations to
the minimum necessary to achieve the objective of the application.
 Concatenation also increases the application’s use of memory in addition to increasing the
application’s processing requirements, which becomes apparent by comparing
processing a string with processing a concatenated string. And the strings require sequential
memory locations which is tedious in small computing devices
 Therefore, the best practice is to reduce processing time and memory usage by avoiding
concatenating strings.
 An alternative is to concatenate strings before the string is loaded into the small
 computing device.
 If there is a need to concatenate strings, use a StringBuffer object. This makes efficient use
of memory when strings are appended to the buffer, although there is additional processing
overhead.

17. Avoid Synchronization
 It is very common for developers to invoke one or multiple threads within an
operation. Invoking a thread is a way of sharing a routine among other operations.
 When ever the same code is being executed for all operations. Deadlocks and other
conflicts might arise when multiple operations use the same routine. These
problems are avoided by synchronizing the invocations of a thread
 The best practice to increase performance is to avoid using synchronization where
possible. Synchronization requires additional processing steps that are not
necessary when synchronization is deactivated.
 However, you must consider the performance trade-off with possible conflicts
among operations that use the same threaded routine.
 As a general rule, avoid using synchronization unless there is a high likelihood that
conflicts among operations will occur.

18. Thread Group Class Workaround
 A common way of reducing the overhead of starting a new
thread is to create a group of thread objects that are assigned
threads as needed by operations within an application.
 Less processing is required to assign a thread to an existing
thread object than to create a new thread object.
 Grouping thread objects is made possible by the ThreadGroup
class, but J2ME does not support this class.
 You can work around it, however, by creating your own
grouping using the Collection class. You can store groups of
thread objects in a collection and then use standard collection
methods to start and stop threads in the collection and assign
threads to particular thread objects within the collection.

19. Minimize Network Traffic
 Developing a J2ME application is a balancing act between deciding whether processing
should be performed by the small computing device or by a server.
 The choice depends upon many factors, including the amount of transmission that must occur
for each process.
 A good practice is to off-load as much processing as is reasonable to a server and minimize
the number of processes that need to be invoked by the J2ME application in order to reduce
network transmissions.
 Collect all the information from the user that is required by the process at one time,
and then forward the information to the server when invoking the process.
example,
your application might be used to retrieve a list of customers that the user may later filter
to remove unwanted customers or reorder the customer list into a more appropriate sequence.
You can reduce the number of processes and network transmission by requiring the user to
select the filter and sequence as part of the request for the customer list . In this way, the
database server can create the customer list in the desired order without having the user make
subsequent requests to manipulate the customer information.

20. Be Careful of the Content of the startApp()
Method
A MIDlet consists of required methods, each of which is
callable by the small computing device’s application
manager.
One of those methods is
startApp(), which is called each time the MIDlet is
invoked. Intuitively you might assume that the startApp()
method is called once during the life of the MIDlet and
therefore is a perfect place within your application to store
code that is to execute once each time the MIDlet is
invoked.
Therefore be careful in using startApp( ) as it is called
each time a midlet is invoked

21. Display & Displayable
-- A Displayable class is a UI element that can be shown on the
device's screen.
-- A Display class abstracts the display functions of an actual device's
screen and makes them available to you.
--Display provides methods to gain information about the screen and
to show or change the current UI element that you want displayed
-- MIDlet shows a Displayable UI element on a Display using the
setCurrent(Displayable element) method of the Display class.
-- The Display can have only one Displayable element at one time.
-- The current element that is being displayed can be accessed using
the method getCurrent(), which returns an instance of a isplayable
element.

22. J2ME
Command class
22
The Command class represents the semantic meaning of an
action.
Command objects are presented in the user interface.
The action itself is implemented in a CommandListener object.
The CommandListener is associated with a Displayable or an
Item.
Once the Command is called – the CommandListener is invoked,
and the action is performed by invoking commandAction ()
method.

23. J2ME
Command class
23
An object called a listener is notified when the user
invokes any command in a Displayable
The listener is an object that implements the
CommandListener interface
To register the listener with a Displayable use:
public void setCommandListener(CommandListener l)
Implementing a CommandListener is a matter of
defining a single method:
public void commandAction(Command c, Displayable s)

24. J2ME
24
Command Types
BACK -Moves the user back to a previous screen
CANCEL -Cancel pending changes
EXIT - A command used for exiting from the application
HELP -Show application instructions
ITEM - command used for items (focused item or element )
OK - Confirm a selection
SCREEN -Generic type for specific application commands
STOP - Stops a running operation

25. Item
Item
-- An Item is a component that can be added to a Form.
ChoiceGroup, DateField, Gauge,ImageItem, StringItem and
TextField are all subclasses of Item.
-- Events of Items are processed with the class
ItemStateListener.
-- ItemStateListaner will send message when an event occur.
-- The recipient of this message is the method
itemStateChanged()

26. Important Questions
1.Explain best practices and patterns of j2ME
2.Explain the Traditional computing devices vs Small computing devices
3. Explain Command class
4.Explain Exception Handling in J2ME