Mobile Developer's Guide To The Galaxy Edition 2

Don’t Panic
Mobile Developer’s Guide to
the Galaxy

n
o
iti
de nd
ed
en 2
d
t
ex

Developer’s Guide
Table of Contents
5 Introduction

7 Application Environments Overview
7 Native Applications
9 J2ME / Java ME
9 Flash Lite
10 BREW
11 Widgets
12 Websites
12 SMS Text Messaging

13 Programming Android Apps
13 Android App Characteristics
14 Do the Development
15 Distribution

16 Programming iPhone Apps
17 Prerequisites for iPhone Development
17 Implementation
18 Testing
20 Distribution

21 Programming J2ME / Java ME Apps
22 Prerequisites for Mobile Java Development
23 Implement your App
24 Testing
25 Cover’em All: Porting
28 A Question of Trust: Signing

3

29 Distributing Your J2ME Application

30 Bringing Your Content to the Mobile Web
30 Why a mobile web page?
32 Some History on the Mobile Web
34 How to adapt content for the mobile user
36 Satisfy the Interpreter of Your Content: The Browser
38 Let’s do some pigeonholing: Device categories
42 Use GPS in the Browser
42 Testing your Mobile Website
44 Learn More – On the Web

45 Implementing Rich Media
45 Streaming
45 Progressive download
47 Ringtones
47 Mobile Video
48 Media Converters

39 Now what — Which Environment Should I Use?

52 Epilogue

53 About the Authors
55 Imprint/Contact

This Developer Guide is licensed under the
Creative Commons Some Rights Reserved License.

4

Developer’s Guide
Introduction
This guide is aimed at developers who (want to) realize their ideas
on mobile handsets. We try to outline typical problems and how to
overcome them.
Developing for mobile handsets is a schizophrenic experience – on one
side there is the never-ending stream of innovations and new tech-
nologies, on the other side it can take a painfully long time until new
technologies are actually used by the end customers.
The most important issues for mobile application developers are frag-
mentation and distribution. Thankfully solutions for those problems
do exist.

Development is a passion – have fun in
the mobile world!

5

Developer’s Guide
Application Environments
You can choose between different environments for realizing your mo-
bile vision. This section describes the most common environments and
outlines differences between them. A more detailed description follows
in the environment specific chapters later onwards.

Native Applications
There are a lot of mobile operating systems used in the market today
– some are Open Source, some are not. Most important OS are (al-
phabetically) Android, BlackBerry, Maemo, Moblin, OS X, Symbian and
Windows Mobile. All these OS allow you to create native applications
for them without establishing a business relationship with the respec-
tive vendor. Most mass market phones are, however, equipped with em-
bedded operating systems that cannot be programmed for by outsiders.
Examples include but are not limited to Nokia Series 40, Samsung SGH
and Sony Ericsson Java Platform phones.

Main benefits for programming native applications include the best
possible integration of your application and often a very good perfor-
mance. Typical drawbacks are the required effort and the complexity of
supporting several native platforms (or the limitation of your app to
only one platform). Also most mass market handsets cannot be pro-
grammed natively.

7

The following table provides an overview about the main mobile
operating systems:

OS Language(s) Remarks
Android Java, C Open Source OS (based on Linux)
developer.android.com

Blackberry Java Is also J2ME compatible, but the
native APIs provide better integration.
na.blackberry.com/eng/developers

LiMO C, C++ Open Source OS (based on Linux)
www.limofoundation.org

Maemo C, C++ Open Source OS (based on Linux)
www.maemo.org/development

Moblin C, C++ Open Source OS (based on Linux)
www.moblin.org

OS X / iPhone Objective-C, C Requires Apple Developer Account
developer.apple.com/iphone

Symbian C, C++, others Open Source OS
Some Series 60 compatible phones
support further languages like Python.
Most Symbian phones support J2ME.
www.symbian.org

Web OS HTML, CSS, Widget style programming, OS is
JavaScript based on Linux
developer.palm.com

Windows C#, C You can choose between the .NET
Mobile Compact Framework and programming
Windows Mobile directly. Most Windows
Mobile phones also come with a J2ME
compatible JVM preinstalled.
developer.windowsmobile.com

8

J2ME / Java ME
Around 80% of all mobile handsets shipped in 2008 support the mo-
bile Java standard (J2ME/Java ME), so Java is by far the most widely
distributed application environment. In contrast to many other en-
vironments, J2ME is a standard rather than a product, which can be
implemented by anyone (who pays Sun the corresponding license fees
that is). Standardization is the strength of J2ME but at the same time
it is the source for many fragmentation problems.
On many handsets with embedded operating systems, J2ME is the only
way to realize client side applications. The main problem is the frag-
mentation, meaning the little differences between the implementations
and handsets.

Flash Lite
Flash Lite is the mobile edition of Flash, which pretty much is the same
as an older version of Adobe’s web Flash product. Flash Lite gains trac-
tion and is especially favored by many designers, since they know the
tools already.
Flash Lite features a powerful UI but it lacks a good integration
into the host device, although this is improving. Programming Flash
Lite is relatively easy thanks to its Action Script language that is
very similar to Java Script. The drawback is its poor performance and
small market share in comparison to J2ME.

9

BREW
The Binary Runtime Environment for Wireless (BREW) is a programming
environment pushed forward by Qualcomm1. BREW services are offered
by more than 60 operators in 28 countries, but it’s most popular within
the US with CDMA devices launched by Verizon, US Cellular, Metro PCS
among others2. Today, BREW applications are developed using native
C code. The next evolution of the BREW client, Brew Mobile Platform
(Brew MP), supports applications written in Flash, TrigML or native C
code3.
1) brew.qualcomm.com
2) brew.qualcomm.com/brew/en/about/brew_today.html
3)
brew.qualcomm.com/brew/en/developer/overview.html

10

Widgets
There are several widget environments that you can choose from. Main
benefit of these environments is the simple programming, main draw-
back is that you need to ensure that your customers will install both
– the widget player as well as your widget. More and more devices
feature, however, a preinstalled widget player – not necessary for the
environment that you have chosen, though.
The other significant drawback is that widgets do only allow a very low-
level access to the handsets functionality.

All these environments use XML, a script language (e.g. JavaScript)
and a page description language (like HTML) for realizing a widget.
The following table gives you an overview about popular widget frame-
works:

Environment Language(s) Remarks
Nokia Web XML, www.forum.nokia.com
Runtime HTML, CSS,
Widgets JavaScript
Starmobi XML, CSS, The Starmobi JavaScript API allows
JavaScript you to script apps similar to J2ME,
German only.
www.starmobi.de/index.php?id=developer

W3C / XML, Vodafone, China Mobile and other
Vodafone HTML, CSS, companies try to push the W3C widget
Widgets JavaScript standard for mobile adoption.
widget.vodafone.com/dev

Samsung XML, innovator.samsungmobile.com
HTML, CSS,
JavaScript

11

Websites
Webpages are supported by all phones, so in principle this should be
the environment of choice to get the widest possible reach (after SMS
texting). The only problem is the sheer number of browsers and their
varying feature sets. Some browsers are very powerful and support CSS
as well as JavaScript, others are less sophisticated XHTML only. Thank-
fully the old WAP standard with its WML pages does not play any sig-
nificant role nowadays.
Main problems for web pages are that they are only available online and
that they cannot access device features today. Main benefits are the
easy development and a deployment that lies solely in your hands.

SMS Text Messaging
Almost everybody who has a mobile phone is also texting. Texting pro-
vides the limitation that any interaction needs to be pressed into 160
characters and that it can be quite costly to send out text messages in
bulk. On the positive side it enjoys a global audience of any age.

12

Developer’s Guide
Programming Android Apps
The Android platform is one of the latest systems for the mobile mar-
ket. Created by Google and the Open Handset Alliance in late 2007,
Android is an operating system and an application development envi-
ronment with complete tooling support and a variety of preinstalled
applications.

Until the end of 2009, 18 models from different vendors will be avail-
able. The first adopter was HTC with its Dream device and other vendors
like Samsung and Huawei followed up quickly.

Android App Characteristics
An Android application is a mix of activities and services. An activity
is a piece of functionality with an attached user interface. A service is
used for tasks which should run in the background and is therefore not
tied directly to a visual representation. The communication between
the two and other system entities like broadcast receivers is done by
intents. An intent bundles data like the user’s touch position with a
semantic meaning. These intents are a way of triggering all kinds of
behavior in the platform. The intent of showing a web page will open
the browser activity, for example.

Your application will always be signed, either with a debug signature
or a real one. Your signature may be self signed, so forget about sign-
ing fees!

13

Do the Development
The main programming language for Android is Java5. But beware that
not the complete Java library is supported and that a lot of platform
specific API is present. You find answers to your What and Why ques-
tions in the Dev Guide1 and to your How questions in the reference
documentation2.

To get started you will need the Android SDK3 and you will want a
decent Java IDE. The SDK is available for Windows, Mac OS X and Linux
and contains tools to build, debug and analyze applications. So you
have no constraints on your development platform.
As for the IDE, you can install the helpful ADT plugin for Eclipse which
will coordinate building and deploying. But as the complete build cycle
of Android is Ant based you can basically use any IDE you like. To aid
the development, you have a lot of tools at your disposal:

— android: Create an initial project or manage virtual devices.
— adb: Scan devices at your USB bus, connect and interact with
them by moving files etc.
— emulator: Start it with a virtual device and it will emulate the
defined features. It takes some time to startup so do it once and
not on every build.
— ddms: Look inside your device or emulator, watch log messages
and control emulator features like network latency and GPS
position. Have a look at the memory consumption or simply kill
some processes. If this tool is running, you can also connect the
Eclipse debugger to a process running in the emulator.
— traceview: Analyze special trace logs which you can activate
with Debug.startMethodTracing(“myApp”); and see
which method did what at which time.

14

Distribution
After you have created the next killer application and tested it, you
should put it in the Android Market. It is the one place to reach all
customers and developers of the Android platform alike. Browse for
new exciting apps and sell your own. To upload your application to
the Android Market, make sure that you have defined a versionName,
versionCode, an icon and a label in your AndroidManifest.xml.
To upload your application, start at market.android.com/publish. You
are required to register with the service with your Google Account and
a $25 registration fee. The only accepted payment service is Google
Checkout.
Once your registration is approved you can upload your application,
add screenshots and descriptions to finally publish it.
1) developer.android.com/guide/index.html
2) developer.android.com/reference/packages.html
3) developer.android.com/sdk/1.6_r1/index.html

15

Developer’s Guide
Programming iPhone Apps
The iPhone is a highly interesting and very popular development plat-
form for many reasons, a commonly named one being the App Store.
When it was introduced in July 2008, the App Store took off like no
other marketplace did before. Within a year its users have downloaded
over 1.5 billion apps, which makes the App Store very interesting for
mobile developers.
Additionally, the iPhone SDK offers high-level APIs for a wide range
of tasks which helps to cut down on development time on your part.
New APIs are added in every major update of iPhone OS, such as MapKit
in iPhone OS 3.0.

16

Prerequisites for iPhone Development
In order to develop iPhone (and iPod Touch apps), you will need the
iPhone SDK, which can be downloaded at developer.apple.com/iphone.
This requires a membership, which is available for free. If you plan to
test your apps on your device or distribute your apps on the App Store,
you need to sign up for an account starting at 99USD a year.

The iPhone SDK contains various applications that will allow you to
implement, test and debug your apps. The most important applications
are:

— Xcode, the IDE for the iPhone SDK
— Interface Builder, to build user interfaces for iPhone app
— Instruments, which offers various tools to monitor app execution
— iPhone Simulator, which allows the developer to test his or her
apps quicker than by deploying to a device

The iPhone SDK will work on any Intel-based Mac running Mac OS X
10.5 (Leopard) or 10.6 (Snow Leopard). A guide to get you started and
introduce you to the tools is included, as is a viewer application for
API documentation and sample code. References and guides are also
available online at developer.apple.com/iphone/library/navigation.

Implementation
Usually, you will want to use Apple’s high-level Cocoa Touch APIs when
developing for the iPhone. This means that you will write Objective-C
code and create your user interfaces in Interface Builder, which uses
the proprietary XIB file format. Objective-C is, as the name suggests, a
C-based object-oriented programming language. As a strict superset of
C, it is fully compatible with C, which means that you can use straight
C source code in your Objective-C files.
If you’re used to other object-oriented languages such as C++ or Java,
17

Objective-C’s syntax might take some time getting used to, but is ex-
plained in detail at developers.apple.com1. What seperates Objective-C
most from these languages is its dynamic nature, lack of namespace
support and the concept of message passing vs. method calls.

A great way to get you started is Apple’s guide “Your First iPhone Ap-
plication”, which will explain various concepts and common tasks in
an iPhone developer’s workflow2.

Check out some of the sample code that Apple provides online3 to find
out more about various APIs that are made available to you.

Testing
As performance in the iPhone Simulator may be superior to actual
devices by several orders of magnitude, it is absolutely vital to test on
devices. If possible, test your application on various different models,
since the addition of the iPhone 3GS to the lineup brought with it a
faster CPU, GPU and more RAM and may thus behave differently than
previous iPhone generations.
1)
developer.apple.com/iphone/library/referencelibrary/GettingStarted/Learning_
Objective-C_A_Primer/index.html#//apple_ref/doc/uid/TP40007594
2) developer.apple.com/iphone/library/documentation/iPhone/Conceptual/

iPhone101/Articles/00_Introduction.html
3) developer.apple.com/iphone/library/navigation/SampleCode.html

18

You can distribute builds of your application to up to 100 testers
through Ad-Hoc Provisioning, which you can set up in the Program
Portal1. Each iPhone (and iPod touch) has a unique identifier (UDID –
universal device identifier), which is a string of 40 hex characters based
on various hardware parts of the device.

If you choose to test using Ad-Hoc-Provisioning, simply follow Apple’s
detailed set-up instructions2. Every single step is vital to success, so
make sure that you execute them all correctly.

The iPhone SDK does not include support for unit testing out of the
box, but fortunately Google added support in Google Toolbox for Mac
(GTM)2 with detailed instructions available in their wiki4. Also, iPhone
developer Gabriel Handford has improved on this work and released his
project, GHUnit as open source5. GTM runs the test cases using a shell
script during the build phase, while GHUnit runs the tests on the device
(or in the simulator), allowing the developer to attach a debugger to
investigate possible bugs.
1) developer.apple.com/iphone/manage/overview/index.action
2) developer.apple.com/iphone/manage/distribution/distribution.action
3) code.google.com/p/google-toolbox-for-mac
4) code.google.com/p/google-toolbox-for-mac/wiki/iPhoneUnitTesting
5) github.com/gabriel/gh-unit

19

Distribution
In order to reach the broadest possible audience, you should consider
distributing your app on the App Store. There are other means, such
as the Cydia Store for jailbroken iPhones, but the potential reach isn’t
nearly as large as the App Store’s.

In order to prepare your app for the App Store, you will need a 512x512
version of your app’s icon, up to five screen shots of your app as well
as a build of your app that has been properly signed. Log in to iTunes
Connect1 and upload your app according to the onscreen instructions.
After Apple has approved your application, which usually shouldn’t
take more than 2 weeks, your app will become available in the App
Store and will be available to customers.
1) itunesconnect.apple.com

20

Developer’s Guide
Programming J2ME / Java ME
Apps
Programming J2ME apps is a fun and rewarding experience. The ca-
pabilities of the Java platform are constantly evolving thanks to the
Java Community Process1 that standardizes new APIs (like the Wire-
less Messaging API) and even whole platforms (like the Mobile Service
Architecture).

For realizing your idea in Java you need to follow these steps:

1. Prerequisites
2. Implement
3. Test
4. Port
5. Certify
6. Distribute

These steps are detailed in the following sections.
1) www.jcp.org

21

Prerequisites for Mobile Java
Development
A mobile Java application (MIDlet) is compiled, obfuscated, preveri-
fied and packaged. To implement your application you need a couple
of things:

— the Java SDK1 (not the Java Runtime Environment) and an IDE of
your choice, e.g. Eclipse2 possibly with Mobile Tools for Java
(MTJ), NetBeans3 with its mobility pack or IntelliJ4.
— an Emulator, e.g. the Wireless Toolkit5, the Micro Emulator 6
or a vendor specific emulator.
— Depending on your setup you may also need an obfuscator like
ProGuard7. If you build applications professionally you will
probably also want to use a build tool like Maven8 or Ant9.
— You may want to check out J2ME Polish, the Open Source frame-
work, for building your application for various devices10.

A complete installation and setup guide is out of scope of this guide,
please refer to the respective documentation of these tools. Beginners
often like NetBeans with an installed mobility pack.
Also download and read the JavaDocs for the most important technolo-
gies and APIs.
You can download most JavaDocs from www.jcp.org but there are a
couple of useful vendor specific APIs that needed to be tracked down
manually from the vendor’s pages (Nokia UI-API or Samsung APIs, for
example).
1) java.sun.com 6) www.microemu.org
2) www.eclipse.org 7) proguard.sf.net
3) www.netbeans.org 8) maven.apache.org
4) www.jetbrains.com 9) ant.apache.org
5) java.sun.com/products/sjwtoolkit 10) www.j2mepolish.org

22

Implement Your App
The J2ME environment is pretty much straight forward, the basis is
formed by the Connected Limited Device Configuration (CLDC) and the
Mobile Internet Device Profile (MIDP), which are both quite easy to un-
derstand. Similar to the good ol’ fashioned Applets you extend javax.
microediton.midlet.MIDlet in your main class and then you are ready
to go.

You can create the UI of your app in different ways:
— Highlevel LCDUI components: use the components found in
the javax.microedition.lcdui package, e.g. Form or List.
— Lowlevel LCDUI: use javax.microedition.lcdui.Canvas for
controlling every pixel of your UI.
— SVG: Scalable vector graphics defined in JSR 287
jcp.org/en/jsr/detail?id=287.

There are also different products out there to help you with the UI
development:
— J2ME Polish: compatible with the highlevel LCDUI framework,
separates the design in CSS, you can also use HTML for the user
interface (www.j2mepolish.org).
— LWUIT: a Swing inspired UI framework (lwuit.dev.java.net).
— Mewt: Use XML for defining the UI (mewt.sourceforge.net).
— TWUIK: A powerful “Rich Media Engine”
(www.tricastmedia.com/twuik)

There is a rich open source scene in the J2ME sector. Interesting proj-
ects can be found via blog on opensource.ngphone.com. You will also
find many interesting projects on Sun’s page1, for example the Bluetooth
project Marge2.
1)mobileandembedded.dev.java.net 2)marge.dev.java.net

23

Testing
Thanks to the fragmentation, testing your applications is absolutely
vital. Test as early and as often as you can on real devices. Testing on
emulators cannot substitute testing on real devices – you cannot com-
pare your machine with 3GHz Dual CPU, 4 GB of RAM and broadband
internet connection with typical mobile phones. Some emulators are
quite good (my personal favorites are BlackBerry and Symbian), but
there are some things you have to test in real:

— UI: the experience of the user interface can differ in real
sunlight when you’re out and about. It’s a mobile device –
most users will be on the move!
— Location: if you use location information within your app:
move – both fast and slowly.
— Multimedia: support for audio, video playback and recording
facilities can differ dramatically between devices and their
respective emulators.
— Internet connectivity: establishing internet connections
can take an incredible amount of time. Connection delay and
bandwidth depend on the network, its current strength and
the number of simultaneous users.

Thankfully some vendors provide subsidized or even free remote
access to selected devices:

— Nokia: apu.ndhub.net
— Sony Ericsson: developer.sonyericsson.com/site/global/
techsupport/virtuallab/p_virtual_lab.jsp
— Samsung: innovator.samsungmobile.com/bbs/lab/view.
do?platformId=2

24

If you require to test network connectivity on a number of carriers or
if you need to access certain devices of a specific carrier, you can use
Device Anywhere1 for your testing needs.
Mob4hire2 provides crowdsourcing services. Of course there are various
testing companies as well, that provide testing and QA services, e.g.
Absolute Quality3 or Mobiquest4.
Unit testing can be done with MoMEUnit5 or CLDC Unit6, coverage test-
ing with Cobertura for J2ME7.

Cover‘em All: Porting
One of the strengths of the mobile Java environment is that it is
backed by a standard, so it can be implemented by various vendors
that compete with each other. The downside is that a standard has to
be interpreted, and interpretation causes differences. Different imple-
mentations also suffer from different bugs, which makes things not
really easier. In the next sections we outline different strategies for
porting your J2ME applications to all J2ME handsets and to different
platforms.

Direct Support
The best but hardest solution is to code directly for differ-
ent devices and platforms. So you create a J2ME app for MIDP
devices, a native BlackBerry app, a native Windows Mobile
app, a Symbian app, an iPhone app, a Web OS app, and so on. As you
can imagine, this approach has the potential to bring the very best
user experience, since you can really adapt your application to each
platform. At the same time your development costs will skyrock. We
advise to use another strategy first until your idea has been proven to
be a success.
1) www.deviceanywhere.com 5) momeunit.sourceforge.net
2) www.mob4hire.com 6) snapshot.pyx4me.com/pyx4me-cldcunit
3) www.absolutequality.com 7) www.cobertura4j2me.org
4) www.mobiquest.net

25

Least Common Denominator
You can prevent many porting issues by limiting the functionalities
of your application to the least common denominator. In the J2ME
world this means CLDC 1.0 and MIDP 1.0. Depending on the target
region for the application you might also consider to use either the
extensions Java Technology for the Wireless Industry (JTWI, JSR 185)
or the Mobile Service Architecture (MSA, JSR 205). Both extensions
are supported by many modern devices and provide a lot more power,
though in some regions like Africa, South America or India you should
be aware that you are limiting the number of your potential users by
taking this step.
Using the least common denominator typically is easier, as there are
less functionalities to care about. However, the user experience may
suffer when limiting your application in this way. Also this approach
won’t help you to port your app to different platforms like Android or
the iPhone. In short: use the least common denominator for simple
applications, but be careful to use this approach for complex applica-
tions.

Player Based Solutions
There are various player solutions on the market which mostly provide a
consistent set of APIs across various platforms. The player itself has been
ported to different platforms and it interprets or executes the applica-
tion code. Cool player solutions include PhoneGap1 and Gear2.

Player technologies provide an easy and compelling way to realize so-
lutions across a variety of platforms. One drawback can be that player
concepts often need to use the least common denominator for realizing
a consistent API across platforms, it can be difficult or not possible at
all to use platform or device specific functionalities in your applica-
tion.
1) www.phonegap.com
2) digitalapes.net/en/applications/gear

26

Porting Frameworks
Porting frameworks automatically adapt your application to different
devices and platforms. Such frameworks typically feature the following
ingredients:

— Client library that simplifies development
— Build tools chain that converts code and resources to
application bundles
— Device database that provides information about devices
— Cross compilers to port your application to different
platforms

In the J2ME world there are various frameworks to choose from: Xpress
Suite from JavaGround1 provides porting against revenue sharing. Cel-
sius from Mobile Distillery2 is licensed per month. Bedrock from Me-
tismo3 provides a suite of cross compilers on a yearly license fee. J2ME
Polish from Enough Software4 is available under both the GPL Open
Source license and commercial ones. Going the other direction (from
C++ to Java ME) is also possible with the MoSync Open Source solution
from Mobile Sorcery5. Good porting frameworks allow you to use plat-
form and device specific code in your project, so that you can provide
the best user experience. In other words: A good framework does not
hide device fragmentation, but makes the fragmentation manageable.
1) www.javaground.com 4) www.j2mepolish.org
2) www.mobile-distillery.com 5) www.mosync.com
3) www.metismo.com

27

A Question of Trust: Signing
The mobile Java standard differentiates between signed and unsigned
applications. Some handset functionalities are only available to trusted
applications. Which features are affected and what happens if the ap-
plication is not signed but uses one of those features largely depends
on the implementation. On one phone the user might be asked once
to allow this functionality, on another he’ll be asked every time the
feature is being used and on the third one you won’t be able to use the
feature at all without signing.

Most implementations also differentiate between the certification
authorities who have signed an application:
Applications signed by the manufacturer of a device enjoy the highest
security level and can access every handset they desire. Applications
signed with a carrier certificate are on a similar level.
Applications signed by JavaVerified1, Verisign2 or Thawte3 are on the
lowest security level. The mad thing is that not every phone carries all
necessary root certificates. And some well known vendors even strip
away all root certificates. The result is quite a mess, so consider sign-
ing your application only when required, e.g. when deploying to an
app store or when you absolutely need access to security constrained
features. You can of course consider working together with a testing
and certification service provider and let they do the job for you. The
largest one here would be Intertek NSTL4, others are Absolute Quality5
or Mobiquest6.
4) www.nstl.com
1) www.javaverified.com
5) www.absolutequality.com
2) www.verisign.com/code-signing
6) www.mobiquest.net
3) www.thawte.com/code-signing

28

Distributing Your J2ME Application
Unlike the iPhone, you can install J2ME applications directly on your
phone – either over bluetooth or over the air (OTA) using a webserver.

Thanks to the universal app stores, nowadays distribution is easier
than ever. They manage the payment, hosting and advertisements and
receive a revenue share for that.

— Ovi1 targets Nokia users worldwide and provides a 70% revenue
share for the developer (of gross sales, net of refunds and
returns, less applicable taxes and, where applicable, fixed
operator billing costs).
— Java Store2 plans to sell Java based content.
— The Samsung App Store3 distributes application for Samsung
handsets.
— LG also distributes apps on www.lgapplication.com
— Handmark provides a carrier and vendor independent mobile
store.4
— Carriers also get into the game, e.g. Sprint5 or O26. Basically
almost everyone has announced an app store.
— GetJar is one of the oldest distributors for free mobile
applications7.

There are various vendors who provide solutions for provisioning of
Java applications over Blueooth, including Waymedia8, Futurlink9 and
Broadburst10.
1) 6)
publish.ovi.com www.o2litmus.com
2) 7)
store.java.com www.getjar.com
3) 8) www.waymedia.it
applications.samsungmobile.com
4) 9)
www.handmark.com www.futurlink.com
5) 10) www.broadburst.com
softwarestore.sprint.com

29

Developer’s Guide
Bringing Your Content to the
Mobile Web
Why a mobile web page?
When discussing the mobile internet, the first question is: Why shall I
setup a special website for mobile devices?
On one hand there are automatic adaptation engines (like Google or
Opera Mini), which automatically generate mobile versions of any web-
site. On the other hand, the mobile browsers are getting more powerful
and capable of displaying any website (e.g. iPhone)
Both approaches are solving the problem technically but ignore the
primal difference:

The usage context and its meaning for the content
The usage pattern at a desktop computer is often described as „Hunt &
Gather“. The mobile usage is totally different. When using internet on
the mobile handset, the user is usually on the move. He wants to know
more about his surrounding or just fill some minutes. Therefore, mobile
internet usage is often described as „Quick Enjoyment“.
Applications have to take these differences into account. For example,
a search mask for stationary users has to offer comprehensive options,
on the mobile handset it has to be more straight-forward, focused on
the certain action.
These adjustment cannot be realized by a machine. This is one reason
why it is indispensable to create special mobile versions of web-
sites.

30

But the user’s requirements regarding the content are not the only
aspect that has to be taken into account, mobile developers also have
to think about:

The usability on mobile hardware
The mobile user has no mouse, often he has no real keyboard and the
size of the screen is very limited. This means the content of a mobile
website has to be arranged accordingly: Images should not be too
large, all relevant elements should be easily accesible although the
user is not able to move a cursor freely along the site.
It is best to test the usability of a site under real-life circumstances:
Take your mobile handset to a busy public place and try to find all
relevant info of your application by just using one hand. You will see
very quickly where your mobile site shall still be trimmed.
But apart from things like markup, image formats and navigation, you
should never forget about the most valuable good of the mobile user:
Battery power. Complex websites with a lot of JavaScript, CSS and
Flash elements need a lot of processing power which means battery
power.

31

Some History on the Mobile Web
WAP: The stone age of mobile internet
In the beginning, everybody in the business expected the mobile
internet to be a cashcow. The WAP technology made it possible to
send small texts on monochrome displays and b/w images in the WBMP
format to the user’s cellphones, the industry charged him for that by
inventing complicated data transfer rates or strange subscription mod-
els. Many players expected to get rich by selling information which was
already available for free on the internet.
The Wireless Markup Language WML which was used by that time was
another reason why the expected breakthrough did not happen as fast
as some were thinking: While the different internet browsers (Internet
Explorer and Netscape) allowed a „dirty“ html, WML requested a valid
XML structure and proper UTF-8 encoding. The usage of images was
limited to black and white pictures which were a lot less sexy than
what the users knew from their home computers.
The first tries to lift the mobile internet to the next level were
made by NTT DoCoMo by inventing CHTML and Microsofts Windows
CE which worked best with HTML/3.2. But both of them were
just interludes which were replaced by XHTML/MP 1.0.

Current Situation
Today, 99% of all mobile browsers are still supporting XHTML/MP 1.0,
for many low-end devices this language still delivers the best results.
On the other hand, the so-called Full Web Browsers have to support
HTML/4.0, but they still have their differences when it comes to con-
tent-type or doctype and choose different views for distinguishing be-
tween mobile and desktop websites.

32

How to adapt content for the mobile
user
Static Version
Of course you can simply ignore the possibilities of automatic opti-
mization and leave it up to the user: Create different versions of your
content, let the user start with the most low-level version and let him
decide manually which variation is the most comfortable one for his
device and usage patterns in a next step.
But since you are dealing with a user who is on the move and does not
want to spend a lot of time with finding out how to see properly what
you are delivering, this is probably not the best way to go…

Automatic adaptation technologies
To adapt the content to different devices, you basically need two com-
ponents: One logic that detects the device, knows about its browser
and its characteristics — a device database. The second component
interpretes these characteristics and adjusts the content accordingly.

The most popular Open Source device database is the WURFL project1
which offers comprehensive information via XML. A lot of tools deliver
APIs for detecting the browser, delivering its properties and adjusting
the content, the markup and the images. One example for an Open
Source project which adjusts content is MyMobileWeb2, financed by
public funds and Telefonica.
1) wurfl.sf.net)
2) mymobileweb.morfeo-project.org

34

But of course there are also purely commercial providers. Again, some
are concentrating on device data and detection, others are focusing on
offering software platforms which adjust the content accordingly.

Examples for commercial device data and device detection
providers:

— dotMobi1 offers several APIs to access their device database
DeviceAtlas2 and intelligent detection
— DetectRight3

Some commercial content adaptation software providers:

— Sevenval4, a platform independent technology which works via
HTTP and markup. This solution is available as a Service or can
be installed on Linux systems.
— Volantis Mobility Server5 is running on a variety of Java-based
web application servers and SQL-compliant databases. There are
two versions available: one Open Source Community version and
one professional version.
— Mobile Interaction Server6 is running on BEA, IBM WebSphere,
JBoss, Tomcat and Caucho Resin.
1) www.mtld.mobi 4) www.sevenval.com
2) www.deviceatlas.com 5) www.volantis.com
3) www.detectright.com 6) www.mobileaware.com

35

Satisfy the Interpreter of Your Content:
The Browser
Markup
Of course it would be great if there would be one universal markup
standard — unfortunately this is not the case. There are many stan-
dards, so be sure of validating your markup by using one of these tools:

— W3C Markup Validator: validator.w3.org
— W3C mobileOK checker: validator.w3.org/mobile
— dotMobi testing tool: mobiready.com
— Korean MobileOK Test & Validation Service: v.mobileok.kr

As a genereal advice, it is always good to stick to UTF-8 encoding. You
certainly can also consider going low-level and create a XHTML MP/1.0
site with WCSS/1.0 and without JavaScript.

Page Width
Always use dynamic layout. Avoid static width settings in pixels, better
use percentage values. Even when using device databases, the brows-
ers still have different display methods (fullscreen, landscape, por-
trait) and only some allow displaying a scrollbar.
The web is dynamic, so is the hardware landscape — keep your layout
dynamic as well!

Images
Not everybody has a mobile data flatrate, so do not use images too
excessively, avoid any unnecessary images. To reduce data and proces-
sor workload, the images should always be scaled on the server and
not by the browser. ImageMagick offers the possibility to easily scale
your images1.
1) www.imagemagick.org

36

When thinking about the image format, GIF and JPEG are still the
most solid choice. Of course PNG offers more flexibility, but when it
comes to transparency, you cannot always be sure to what degree it
is supported. And some operators still use image proxies which might
not be able to handle this.

Tables
For stationary web, tables are no longer used for webdesign. In the
mobile environment they are still an effective way to create simple
layouts — just avoid unnecessary nested tables and colspan / row-
span.
Even though it breaks the rules for valid XHTML MP/1.0, some brows-
ers need the attributes cellpadding=“0“ and cellspacing=“0“ for not
displaying unmeant spaces. CSS is simply not capable to assure this
with all browsers.

CSS
Do not use CSS excessively. CSS interpretation is sometimes not
properly implemented and shortens battery life. If you stick to the
WCSS/1.0 set, you are on the safe side.
When determining sizes, avoid to define them in pixels, use percent-
age values.

Fonts
Do not deal too arbitrarily with fonts: all browsers just dispose of a
limited set of font-types. Better focus on the font size. Use relative
values (small/medium/large) rather than fixed values (pixels) — the
browser knows best how many pixels to use for displaying a large, a
medium or a small font.

Cookies
You can of course use cookies and should do so, but only when really
needed. And never trust too much in them: although it might work
fine during one session, the cookie might get lost afterwards. This is

37

why you should always offer alternatives like an URL based parameter
or a personalised bookmark for permanent settings.

Script / AJAX
According to www.device-trends.com, 93% of the mobile web users
who visited the associated websites, were using a browser which sup-
ports JavaScript, 70% were able to handle AJAX. So it would be wrong
not to use the possibilities of these technologies. But you should make
sure that your side works fine without them as well.

Let’s do some pigeonholing:
Device categories
You have no idea what kind of devices your visitors mostly use? Then
you should start low-level and implement a tool which detects the
devices who are accessing your site.

Several providers are offering this kind of analysis software:

— AdMob www.admob.com
— Bango www.bango.com
— Sevenval www.device-trends.com
— TigTags www.tigtags.com/mobile_analytics/mobile_site_tracking

Some providers also offer access to the collected data which give you
an idea of which devices are actually using the mobile web:

— AdMob metrics.admob.com
— mobiForge mobiforge.com/designing/story/
effective-design-multiple-screen-sizes
— Opera www.opera.com/smw
— Sevenval www.slideshare.net/sevenval/tag/devicetrends

38

When using this data, keep in mind where they come from and how
they have been generated: In which region have they been collected,
are they really reflecting the users’ mobile web usage or just the pure
general market share of the devices? Does the data maybe only reflect
the user base of certain operators or techology platform? Is it about
page impressions, visits or unique users?
Never trust any report blindly. Use several sources and make your own
picture out of it.

Simple Devices
Probably the vast majority of your users will access your site with a
basic handset like described by the W3C in the Default Delivery Con-
text1 or by Luca Passani in his baseline device description2.

To fit their needs, these are our recommendations:

— XHTML MP/1.0
— screensize: 176x144
— GIF or JPEG image format
— max. 20kb page size (incl. images, CSS)
— basic Table Support, without „rowspan“,“colspan“ - no nested
tables
— minimal CSS (WCSS 1.0)

Of course even these basic characteristics exceed the possibilities of
many older handsets, but people who tend to use the mobile internet
usually own handsets who should properly display pages that follow
the guidelines above. Surfing the internet with much older devices is
no fun anyway.
1) www.w3.org/TR/mobile-bp/#ddc
2) www.passani.it/gap/#baseline

39

Full Web Browser-supported Devices
Full Web Browsers are characterized by their capability to display any
website. These are all webkit based browsers, Opera Mobile, Microsoft
Internet Explorer, Netfront (version 3.4 and later), UCWEB or Fennec.
Devices who use a Full Web Browser do not necessarily require any
technological concessions regarding website design, but we suggest to
follow these guidelines:

— HTML/4.0 Strict
— GIF or JPEG Images, PNG without alpha transparency
— basic table support, without „rowspan“,“colspan“ - no nested
tables
— keep CSS simple, tables are not bad
— script is allowed, but not needed (avoid unneeded script or
animation effects -think of the battery)
— if available, use AJAX to get content

40

Touch Devices
Here it is referred to modern devices with a powerful browser like the
iPhone or Android handsets. The touch-sensitive UI offers the possibility
to move more freely within a website. At the same time, it makes it
more complicated to chose one line from a list or any other smaller
element within a page.

If your mobile site complies with the following requirements, any
touch device user shall be able to navigate properly:

— HTML/4.0 Strict
— GIF, JPEG, PNG (with alpha transparency)
— full table
— script is allowed, but not needed
— use CSS, especially the so-called webkit styles for rounded
corners
— if available, use AJAX to get content
— keep the linited battery life in mind
— use a large font size (as example 18px) for links and clickable
lists
— set a default viewport (<meta name = “viewport” content
= “width = device-width”>)

41

Use GPS in the Browser
Devices like the iPhone (firmware version 3 and later), the Blackberry
(firmware 4.2. and later) and browsers with Google Gears allow you to
use the GPS information from within the browser. The W3C published
a specification about this1, but unfortunately this is supported by all
devices. Nevertheless you can still use a simple Java API which is laid
over the different implementations2.
For further information about how to use GPS location information for
web-based Apps and services, check out mobiforge3.

Testing your Mobile Website
There are several ways to test your mobile website:

User-Agent / Browser
Several desktop browsers offer the opportunity to change the user-
agent and emulate a device detection for automatic adaption. For Fire-
fox users, the User-Agent Switcher is available on addons.mozilla.org/
en-US/firefox/addon/59. mobiForge offers a configuration file for this
Add-On which contains some properties of mobile handsets4.
1) dev.w3.org/geo/api/spec-source.html
2) code.google.com/p/geo-location-javascript
3) www.mobiforge.com/developing/blog/location-location-location
4) www.mobiforge.com/developing/blog/user-agent-switcher-config-file

42

Emulators / SDKs
The better option to test your mobile site are emulators or SDKs of the
manufacturers. I made good experiences with the following tools:

— Apple iPhone: developer.apple.com/iPhone/program
— Palm Pre: developer.palm.com
— Android: developer.android.com
— BlackBerry: www.blackberry.com/developers/downloads/
simulators
— Windows Mobile: msdn.microsoft.com/en-us/windowsmobile
— Opera Mini: www.opera.com/mini/demo

More emulators can be found on mobiforge.com/emulators/page/
mobile-emulators

Remote and Real Device Testing
As mentioned in the other chapters in this guide, the best is always to
test your product on as many real devices as possible under real-life
conditions. The alternatives are always remote testing (by using ser-
vices like www.deviceanywhere.com or Nokias RDA1 and crowdsourcing
the testing with the help of www.mob4hire.com for example.
1) apu.nbhub.net

43

Learn More — On the Web
If you want to dig deeper and learn more about how to satisfy the
mobile user with your web-based service, check out these websites:

— Mobile Best Practices / W3C
www.w3.org/TR/mobile-bp
— dotMobi Mobile Web Developer‘s Guide / dotMobi
mobiforge.com/starting/story/dotmobi-mobile-web-
developers-guide
— The Wireless Wireless FAQ / Andrea Trasatti and others
www.thewirelessfaq.com
— Global Authoring Practices for the Mobile Web / Luca Passani
www.passani.it/gap

And always remember:
The mobile website is not the small website, it is the mobile one!
Keep it simple.

44

Developer’s Guide
Implementing Rich Media
„So many handsets, so many standards”— Again this is true for the list
of supported media formats on mobile phones. The majority of them is
found in the table on page 46, however multiple variations are possible
amongst handsets even within one vendor or phone type firm.

Streaming
Depending on your choice of offering streaming or downloadable
contents, there are some restrictions. To offer streaming content, the
easiest setup is to use Apple’s open source Darwin streaming server1
which can serve streaming video and audio with highest compatibility
(except for Windows Mobile) and reliable Realtime Streaming Proto-
col (RTSP). For Windows Mobile, Windows Media Server2 is the easiest
choice (available as a free download). Typical frame rates are 15 fps
for MP4 and 25 fps for 3gp with up to 48 kbps for GPRS (audio only),
200 kbps for Edge, 300 kbps for 3G/UMTS. RTSP is a protocol which is
designed for low-bandwidth mobile devices. If you need a PC player to
read 3gp rtsp streams, use QuickTime or Real player.

Progressive download
To avoid setup of streaming servers, a good alternative is to offer
progressive downloads, for which your media files can be served from
any web server if you hint your files. Hinting is the process of marking
several locations in the media, so a mobile player can start playing the
file as soon as it has downloaded a small part of it (typically first 15
seconds). So far the most reliable open source hinting software found

45

Video Audio Typical
OS/Brand Container Protocol
Codec Codec Resolution
Windows .wmv or
http:// H264
MP3 or 320x240
Mobile .mp4 AAC 176x220

Symbian, .3gp or rtsp:// H263 AMR_nb or 176x144
Nokia .mp4 AAC

iPhone/ .mp4 http:// H264 AAC or 320x240
iPod AAC+ 320x480

Android .mp4 http:// H264 AAC lc 320x480

Blackberry MPEG4
.avi / .mp4 http:// AAC lc 480x320
=<OS 4.2
Blackberry .avi / .mp4/ rtsp:// MPEG4 AAC lc 480x320
=>OS 4.3 .3gp

ADPCM or 352x288
Palm OS .flv / . mp4 http:// MPEG4
MP3
Other 3G .3gp rtsp:// H263 AMR_nb 176x144
Devices

46

is Mp4box3. Use mp4box –hint –latm for mobile phone compatible
hinting (note: -latm is only needed by AAC audio codecs). mp3 files do
not need to be hinted.

Ringtones
To use audio as a ringtone or within a J2ME application, make sure that
the audio format is supported by your target devices. Within J2ME .wav
or .mid is the best choice for maximum compatibility, however the file
size might restrict you as it is uncompressed. There are more than 10
file formats for ringtones, but we suggest to use the MP3 format, 64 or
128kbps, max 30 seconds and a file size of between 300kb and 500kb
or AAC/AAC+ 24 kbps (mono) or 48kbps (stereo) on high-end phones
to ensure maximum compatibility.

Mobile Video
To display video streams on a mobile device, the video player needs to
connect to the streaming server. This sounds easier than it usually is.
First of all, for many players a special APN (Access Point Name) needs
to be configured. If this configuration is not correct, the videoplayer
will not be able to connect with the server.
But even if the APN is configured well, some operators are blocking the
RTSP protocol. This leads to the situation that the streaming will work
within the operator portal and probably even on youtube, but your own
server cannot be reached. Actually you cannot really do anything about
this, you are totally depending on the user’s know-how: He needs to
manually set the APN to an open Internet connection.
But even if you do not use RTSP, there are strange things that might
happen when streaming video on the mobile handset: If a Blackberry
device processes video via WiFi, even large videos usually are displayed
consistently. But if GPRS is used for data transmission, the content is
processed by the RIM servers which define maximum values that may

47

vary from server to server4. As a consequence, content might behave
differently even if the same device, same operator and same APN are
used.
And now? Don’t panic! Offer video to your users if you like to, but
inform them if something is going wrong and if you use a device data-
base, give them the option to chose manually.

Media converters
To convert existing media of any kind to mobile phone compatible
formats and adjust the frame rate, bitrate and channels at the same
time, FFMPEG is a must have (open source) media format converter5.
Make sure you build or get the binary with H263, AAC and AMR encoder
support included. For MAC users, QuickTime pro (paid version) is a
good alternative to encode and hint 3gp files. A good alternative for
converting video is “Super” from eRightSoft6. If you are looking for a
complete server solution with a Java / Open Source Background, check
out Alembik7.

1) developer.apple.com/darwin/projects/streaming
2) en.wikipedia.org/wiki/Windows_Media_Services
3) gpac.sourceforge.net
4) www.blackberry.com/btsc/search.do?cmd=displayKC&docType=kc&externalId=KB10264
5) www.ffmpeg.org
6) www.erightsoft.com/SUPER.html
7) alembik.sourceforge.net

48

Developer’s Guide
Now what - which Environment
Should I Use?
The short and crystal clear answer: it depends.
The longer answer: think about your target users, about their needs,
about their devices and their dataplans. And about your vision and
the requirements for your idea. Remember that you are not necessarily
restricted to a single application environment. A practical approach is
to use the environment that you are most comfortable with and then
move on to other environments for increasing the market reach of
your app. Sometimes it also makes sense to combine different environ-
ments, for example by providing a mobile website for casual users and
a J2ME app for your power users.

49

The following table provides a very rough overview about the indi-
vidual strengths and limitations of each application environment.
Green stands for good coverage, yellow for limited and red for bad
coverage of the respective topic:

rs
pe
lo
ol eve
D
De bili e
la fflin

n
of
ra ch

io
lin ity

s
vic ty

at
a

Av / O
In Re

On ctiv

Sp To

nt
me
t

e
e

d
ke

ee
ai

ag
te
r
Ma

Fr
SMS

BREW

Flash Lite

Widgets

Native Blackberry

Native Symbian

iPhone

Windows Mobile

Android

J2ME

Web

50

You can also compare application development with web development
in a more general manner:

App Development Web Development

Approval process 2–8 weeks in app stores Instant updates

Portability Complex Easy

Complexity Complex Easy

Monetization Sale, Advertisements, in Advertisements
app purchase

Web development beats application development in many but one
crucial area: monetization. Internet services are mostly free and the
only reliable business model is often advertisements. In contrast, app
stores shine in this area. All stores support charging for application,
the iPhone app store nowadays also supports in app purchases. And of
course you can embed advertisements in your application as well.
If you need to earn money today, it will be easier with an application
unless you want to earn money purely with ads.

51

Developer’s Guide
Epilogue
Thanks for reading this second release of our mobile developer’s guide.
We hope you’ve enjoyed this and we helped you to clarify your options.
Don’t be put down by the difficulties in entering the mobile arena —
once you’re in the water, you can and will swim.
Would you like to contribute to this guide? Please send your feedback
to developers@enough.de!

52

Developer’s Guide
About the Authors
Robert Virkus / Enough Software
Robert works in the mobile space since 1998. He experienced the Java
fragmentation first hand by developing and porting a mobile sports
betting client on the Siemens SL42i phone, which happened to be the
first mass market phone with an embedded Java Virtual Machine. With
this experience he launched the Open Source J2ME Polish project in
2004 that aims to overcome the device fragmentation barrier. He is
the founder and CEO of Enough Software, the company behind J2ME
Polish.
www.enough.de www.j2mepolish.org

Roland Gülle / Sevenval
Roland joined the mobile industry in 2001. At Sevenval he is respon-
sible for the development of the adaptation technology and the FITML
Platform which allows developers to create mobile internet portals.
Roland is an active member of the the Mobile Web Initiative (MWI) and
several open source projects.
www.7val.com

Thibaut Rouffineau / WIP
Community and passion builder with a mobile edge, Thibaut has been
conversing with the mobile developer community for the past 4 years as
the head of developer engagement at Symbian, where he spearheaded
the migration to open source. Today he is the VP for Developer Partner-
ships at WIP (Wireless Industry Partnership).
www.wipconnector.com

53

Michel Shuqair / 24access Solutions
Michel built his experience with Telecoms since 1999 where he closely
watched the mobile development space evolving from Japan. Start-
ing with black and white WAP applications, iMode and SMS games, he
is now leading the mobile social network m.wauwee.com with over
850,000 members and supported by a team of Symbian, iPhone, Black-
berry and Android specialists with headquarter in Amsterdam.
www.24access.nl

Alexander Repty / Enough Software
Alexander has been developing software for Mac OS X since 2004. When
the iPhone SDK was released in 2008, he was among the first registered
developers for the program. Since then, he has worked on a number
of apps and written a series of articles on iPhone development. He
has been working as an iPhone developer for Enough Software since
October 2008.
www.enough.de www.alexrepty.com

54

published by
Enough Software GmbH + Co. KG
Sögestrasse 70
28195 Bremen
Germany
www.enough.de

Contributing parties:

www.7val.com www.enough.de www.wipconnector.com

Mobile Developer's Guide To The Galaxy Edition 2

More Related Content

What's hot (17)

Similar to Mobile Developer's Guide To The Galaxy Edition 2 (20)

More from Avenga Germany GmbH (20)

Recently uploaded (20)

Mobile Developer's Guide To The Galaxy Edition 2