3. Application and Games Delivery
In the beginning, the mobile content delivery world
centered around ringtones and wallpapers. To deliver this kind of
content, we should rely on what we have seen before: if we deliver the
proper MIME type, the file will be saved by the mobile phone. For
current devices, ringtones are generally MIDI or MP3 files, while there
are other audio formats suitable for low-end and older devices. A
wallpaper can be a JPG, an animated GIF, or even a Flash Lite file for
compatible devices.
Note:
You can use any dynamic image resizing library to generate a
wallpaper with the right dimensions for the device. The best solution
is to have three templates of the same image to avoid deformation: a
vertical, a horizontal, and a square version of the same image, in a
large size. Then, using the WURFL properties, you can use the correct
version and resize it as needed.
The next content that appeared on the market was games, followed
by applications (the difference is not technical).
Applications delivery can be useful:
If you are creating a game or application store
If you are developing a mobile website for a current
application
If you have a richer version of your mobile website available
as a widget or application
If you are providing a shortcut for your website embedded as
an application
The formats that you can deliver from a website are:
We cannot deliver iOS native applications for iPhone, iPad, or
iPod directly to users, as the App Store is the unique public way to
install and deliver applications for this OS. However, we can link to
the App Store native application with the app we want the user to buy or
download onscreen.
There are similar restrictions on delivering webOS
applications.
For widgets and Android, Symbian, and Windows Mobile applications,
we just need to use the right MIME type when delivering the file. No
special mechanism is used.
You may be wondering how you can charge for content
using the user’s bill or available credit. There is no simple or
standard solution for this; to do it universally you would have to
have a contract with every carrier in every country in which you wish
to sell your content, and every carrier has its own charging
method. The classic method is to send an HTTP request to the carrier’s
server with an XML or any other standard file defining the user’s ID
or phone number, the content type, and the amount to charge for the
content. The server responds with a status code indicating whether the
payment has gone through or if there has been a problem. This method
implies that we receive the user’s ID or phone number in a
header. More modern methods involve sending a redirect with parameters
from your website to the carrier’s site, where the user will be
prompted to pay for the content. If the payment goes through, the user
will then be redirected again back to your server, where you provide
the content. The GSM Association’s OneAPI is trying to standardize this
process across carriers. More information about this API can be found
at http://gsma.securespsite.com/access. You can, of course, use other classic payment methods, like
PayPal or credit card processing. PayPal offers Mobile Checkout, an API for mobile
commerce. If you have a PayPal account, go to API Permissions and
enable mobile checkout. More information is available at http://www.mobilexweb.com/go/paypal. Google Checkout is also available for mobile devices,
and it requires no additional setup if you already have an account: it
will work with mobile devices automatically. Bango (http://www.bango.com) also
offers mobile billing through operators, even for users connecting via
WiFi, in over 150 countries.
|
4. Java ME
Java ME was the preferred language for games and
applications for years. Its usage is declining, but it is still the most
widespread platform in the world. It is compatible with Nokia,
non-Android Motorola, LG, Samsung, Sony Ericsson, BlackBerry, and many
other devices.
A Java ME project is shipped as a JAR (Java
ARchive) file, which is just a ZIP file containing the application
(compiled classes and resources). It must be delivered using the MIME
type application/java-archive. Many
phones accept this file type directly, although the best (and 100%
compatible) way of delivering Java ME games or apps is to first deliver
a JAD (Java Application Descriptor) file. The JAD
file is just a text file served with the MIME type text/vnd.sun.j2me.app-descriptor that contains
metadata about the application, similar to OMA Download’s download
descriptor files (in fact, OMA download took this approach from
Java).
So, the device first downloads the JAD file and shows the
information to the user (name of the application, size, format, etc.).
If the user accepts, the JAR file is then downloaded and installed. The
Java ME developer usually generates the JAD file, and we receive it in
its final state. However, as it is a text file, we can generate it
ourselves or change it using a server-side script.
Note:
If you are delivering games or advanced applications, it is
common to create different versions for different device sets, to deal
with portability problems and differences between platforms. In this
situation, you will need to be sure to deliver the right JAD and JAR
file versions for the current device, if they exist.
At the time of this writing, there are two major versions of the
Java ME platform for mobile devices: MIDP 1.0 and MIDP 2.0. There are
more subversions and differences in APIs and configurations, but this is
beyond the scope of this book. If we’re providing the same application
or game in both versions (e.g., basic and advanced versions), we should
first check the device’s compatibility with Java ME and then deliver the
correct JAD and JAR files. WURFL has properties to check if MIDP 1 or
MIDP 2 is available.
4.1. Serving JAD files
Let’s analyze a part of the MIDP 1.0 version of the JAD file
sent to the device when a user tries to download Opera Mini 3:
MIDlet-Version: 3.1
MIDlet-1: Opera Mini 3, /i.png, Browser
MIDlet-Data-Size: 10240
MIDlet-Description: Opera Mini
MIDlet-Icon: /i.png
MIDlet-Info-URL: http://mini.opera.com/
MIDlet-Install-Notify: http://mini.opera.com/n/13045Bviprdome_en
MIDlet-Jar-Size: 58800
MIDlet-Jar-URL: opera-mini-3.1.13045-basic-en.jar
MIDlet-Name: Opera Mini 3
MIDlet-Vendor: Opera Software ASA
Content-Folder: Applications
MicroEdition-Configuration: CLDC-1.0
MicroEdition-Profile: MIDP-1.0
The emphasized parts of the code are the ones that we need to
care about when delivering Java ME applications.
Note:
There are a lot of other standard and vendor-specific JAD
attributes that can be defined, from virtual keyboard support on
touch-screen devices to digital signatures.
MIDlet-Jar-URL defines the
relative or absolute URL of the JAR file. We can insert the JAR file
directly here, or, if we want to secure and log the download, we can
use a URL to a dynamic script including a URL parameter included in
the JAD generation.
MIDlet-Install-Notify is the
same as the installNotifyURI
parameter in OMA Download. It is an optional parameter that defines a
URL that will receive by POST the
same codes as in OMA Download (from 900 to 906), as seen in Table 10-6.
Note:
There is another optional JAD attribute, MIDlet-Delete-Notify, that defines a URL
that will receive by POST a
notification when the user deletes the application from the device.
Using this attribute is not recommended; it is not reliable, and the
user may not want to connect to the Web when deleting an
application.
Starting with MIDP 2.0 (the version compatible with almost all
Java ME devices on the market today), the standard added new codes
that we can receive in the MIDlet-Install-Notify URL. The added status
codes are shown in Table 3.
Table 3. Additional MIDP 2 status codes
| Code | Message | Description |
|---|
| 907 | Invalid
JAR | The JAR (executable
package) is invalid and could not be installed. |
| 908 | Invalid Configuration
or Profile | The device is not
compatible with the versions of the libraries used in the
package. |
| 909 | Application
Authentication Failure | A security problem has
occurred. |
| 910 | Application
Authorization Failure | A security problem has
occurred. |
| 911 | Push Registration
Failure | A push notification
registered in the JAD file is invalid. |
| 912 | Deletion
Notification | The user has deleted
the application from the device (used when MIDlet-Delete-Notify was
defined). |
| 913 | Required Package Not
Supported by the Device | A package or API marked
as required by the application is not available on the
device. |
In the MIDlet-Icon and
MIDlet-1 parameters, you can find
an icon URL (the same path appears twice). This deserves an
explanation.
4.1.1. Icon definition
A Java ME application (called a
MIDlet, because it is a MIDP application) can
define an icon to be placed in the applications menu of the mobile
device once it has been installed. This icon is placed inside the
JAR archive, and we define it in the JAD file. What’s the problem?
Every platform has its own preferred icon size. Even on different
devices based on the same OS, the icon size can change. In addition,
the developer wants the user to have the best possible experience
(as do we), and a broken, small, or pixelated icon creates a bad
user experience.
There are two solutions:
The Java developer creates n packages
for each device or group of devices.
The Java developer creates one or more packages with all
the possible icon sizes inside the JAR and then we, as the web
developers, use a device library to dynamically define in the
JAD which icon is the best for the current device.
4.2. Custom properties
Java ME allows us to define custom properties in the JAD file as
string values. Each property can then be read by the Java ME
application when it’s executed. A custom property is just a
key:
value line in the JAD file. This technique
must be coordinated with the Java ME developer. These values cannot be
changed by the user and are fixed with the application until it is
deleted or updated.
This can be useful for providing any of the following:
A download ID for future identification
User agent or device information that the server knows but
Java ME does not
A username or user ID for transactions
Key codes for nonstandard keys that the server knows but
Java ME does not
IP or server addresses
Other useful or dynamic parameters
4.3. Java ME for BlackBerry
Newer BlackBerry devices accept the same JAD and JAR
files that we’ve been examining. However, the most compatible way to
serve Java ME files on these devices is to use BlackBerry’s own format
for JAR files: COD files.
BlackBerry uses the same JAD files, with two new mandatory
attributes: RIM-COD-URL and
RIM-COD-Size. The COD file must be
served as application/vnd.rim.cod,
and it is generated using a free tool from RIM that converts a JAR
into a COD file.
5. Flash Lite Content
Flash Lite movies, games, or applications are just SWF
files. The problem with this format is that a SWF file is not “an
installed application”; it is managed like any other document on the
device, as a file in the filesystem. For Flash Lite content to be
installed as an application, it should be contained in another format,
such as:
- Nokia Flash Lite (NFL)
Nokia provides a packager for Flash Lite for Series 40
devices.
- Symbian SIS
There are many Flash packagers for Symbian that can embed
Flash content in a Symbian native format.
- Widget for Symbian
For compatible devices, you can embed a Flash application in
a widget.
- Capuchin
The Capuchin Project is an API compatible with Sony Ericsson
devices that allows the usage of a SWF file inside a Java ME
application.
The NFL format is just a ZIP file with a .nfl
extension, served as application/vnd.nokia.flashlite-archive, with
a minimum of three files inside: a SWF, an icon file, and a descriptor.inf text file. The contents of the
text file look something like this:
FL-Version: 1.0
FL-Icon: image.png
FL-Name: Super Game
FL-Root: supergame.swf
Note:
An XML-based file that represents a bookmark is available on
some Nokia, LG, and Sony Ericsson devices. Check for support in the
Accept header by looking for the
MIME type application/x-wap-prov.browser-bookmarks.
6. iPhone Applications
If you have your own application that has already been
accepted for distribution via the App Store, or if you want to provide
users with a link to buy or download an application, game, ebook, music
file, movie, or TV show, you can use a special iTunes link that will
open iTunes or the App Store automatically, displaying the desired
content.
You can create one of these links using the web service
iTunes Link Maker, available at http://www.apple.com/itunes/linkmaker. You can select
which country’s App Store to look for the content in, and then search
for the content you want to link.
Note:
Android Market, one of the application stores for the Android
OS, has its own URL scheme for linking to an application or searching
the store from a website. The format is market://search?q=<search>,
using the application name in the
<search> field.
For example, to provide a link that the user can visit to buy the
movie Terminator Salvation, we can use the code
provided by the iTunes Link Maker:
<a href="http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewMovie?id=338372479
&s=143441&uo=6" target="itunes_store"><img height="15" width="61" alt=
"Terminator Salvation (Director's Cut)" src="http://ax.phobos.apple.com
.edgesuite.net/images/badgeitunes61x15dark.gif" /></a>
