Platinum Sponsors
Gold Sponsors
Silver Sponsors
Partners
Partner events
Carol Hamer
(2640) Customizing Applications for a Range of Handsets
Technical short talk 20 min
Thursday, 2008-06-26, 11:30 - 11:50, Arena 9
Carol Hamer - Greenliff AG (+books published through Apress) (speaker)
Topics
Abstract
One common challenge in mobile development is trying to get a fairly simple
application to run on as many handsets as possible. If the goal is to use a
mobile application to promote and sell products and services (rather than
selling the application itself to the user), then it's critical to make sure
that the application will run on as many handsets as possible, from the high end
down to the low end. MIDP makes this easy if you don't care what the
application's user interface looks like. Unfortunately, the look-and-feel
matters quite a lot if you want your program to entice users to buy your product
or service. The user interface needs to be attractive and branded according to
the specifications of a graphic designer. This is impossible with MIDP's
built-in lcdui classes, so essentially you have to draw your own GUI onto a
blank canvas. It's tricky because the devices (and especially their screens)
vary in size and capabilities, but it's not impossible. In this talk I explain
how to do it.
1. Analyzing the differences among platforms and choosing a target range:
Depending on what your application needs to do, you will probably have to
restrict your application to a range of handsets that have the right
capabilities. Within your target range, you need to be aware of which aspects
vary the most from handset to handset so that you can design your program to be
easy to customize from one platform to the next. This includes making business
decisions such as weighing the difficulty of accommodating a given handset
series against the importance of that handset series to the market.
The differences that require the greatest customization effort are the most
obvious ones: the screen size, the MIDP version, and the optional APIs (JSRs or
proprietary APIs) available on the device. However there are other differences
that usually need to be taken into account such as hardware differences
(especially computing power and memory) as well as software (VM) related
differences in behavior, and even handset bugs.
2. Programming a custom user interface:
To build a basic user interface from scratch requires writing functionality for
widget navigation, for the widgets themselves, for custom fonts, text placement,
scrolling, softkeys, and more. Using third-party libraries (such as J2ME
Polish) can be a good solution for some applications.
3. Building and testing a series of binaries:
In practice you generally build a separate binary for each handset model that
your application supports. That means that you will have hundreds of different
binaries to deliver. It's not too hard to write an automated build process
(using ant) that reads the handset data from a database or file and can create
all of the binaries from a single code base. However, it's not enough to test
your application on the emulator or one handset and assume that the build script
is sufficient for the rest. During the development phase, the developer should
have access to a set of at least five or ten handsets that are representative
(in terms of different manufacturers and different levels of computing power) to
catch and correct problems as early as possible.
During the testing and debug phase, the application should be run on every
target handset (either through in-house testing or through a handset testing
service), and the developers need to be able to have access to the handsets in
order to correct platform-specific bugs.
Media Partners
