This post was written by Ajit
Jaokar, who is a R/WW guest blogger on Mobile Web 2.0 and digital
convergence.
In my last post, I spoke
of the differences between browser applications on the web and on the mobile device. This
topic is important because the Mobile Web is all about extending the concept of web
applications to mobile devices. However, as I pointed out in my last post, it’s not
a ‘straight convert’ – i.e. any application running on the Web can’t
run on a mobile device as is.
In this post, I am going to explore browser applications further – specifically
in respect to accessing device APIs.
To be truly useful, any application running on a mobile device must have access to
some features of the device itself. Traditionally, browser applications running on the
device did not have access to device APIs (with the exception of some proprietary APIs
created by specific vendors). In contrast, non browser applications running on the device
have had much better access to device APIs.
Non-browser apps on a mobile device
Broadly, you can class non-browser applications running on a mobile device into two
categories:
- operating system applications, like Symbian applications (www.symbian.com); and
- downloaded applications, like Java ME applications (previously called
J2ME)
Note that for simplicity we are ignoring messaging applications like SMS and SIM applications, which have a totally
different architecture.
So to understand what we are missing with mobile browser applications, we have
to understand what features ‘operating system applications’ and
‘downloadable applications’ provide. In other words, what can they do which
browser applications traditionally can’t do?
Let’s look at Java applications – i.e. downloaded applications. As you can
expect, they run on a JVM (Java virtual machine) and can be downloaded to the device
– either ‘over the air’ or synchronised from a PC. Operating system
applications (like symbian applications) also have access to similar functionality. In
fact because they operate lower down the stack, they have access to more
features
Security
Before we discuss APIs, the previous discussion highlights another issue –
security. An application running on a device poses a number or risks: privacy risks
(access to phone book), financial risks (if the device is being used as a payment
mechanism), risks to minors (due to the ability that a device can be tracked) and so
on.
Java ME solves this issue by ‘security domains’. There are four security
domains: manufacturer domain (i.e. the device manufacturer like Nokia (www.nokia.com), operator domain (the mobile operator like
Vodafone (www.vodafone.com), trusted third party
domain (i.e. applications which are trusted) and finally the untrusted domains (everyone
else!)
Device APIs: Java ME as a model for upcoming mobile browsers
Let’s look at the Java ME model in more detail. The documentation can be
downloaded from
http://jcp.org/aboutJava/communityprocess/final/jsr118/
Most of it pretty much standard but the most interesting bits are found in a section
at the very end called ‘The Recommended Security Policy for GSM/UMTS Compliant
Devices’. The APIs are listed below in two groups. They are self explanatory (in
this context, MIDlet is the actual program running on the device).
Network/cost-related API groups:
- Phone Call this group represents permissions to any function that results in a
voice call. - Net Access this group represents permissions to any function that results in
an active network data connection (for example GSM, GPRS, UMTS, etc.); such functions
must be mapped to this group. - Messaging this group represents permissions to any function that allows
sending or receiving messages (for example, SMS, MMS, etc.) - Application Auto Invocation this group represents permissions to any function
that allows a MIDlet suite to be invoked automatically (for example, push, timed MIDlets,
etc.) - Local Connectivity this group represents permissions to any function that
activates a local port for further connection (for example, COMM port, IrDa, Bluetooth,
etc.)
User-privacy-related API groups:
- Multimedia recording this group represents permissions to any function that
gives a MIDlet suite the ability to capture still images, or to record video or audio
clips. - Read User Data Access this group represents permissions to any function that
gives a MIDlet suite the ability to read a user’s phone book, or any other data in
a file or directory. - Write User Data Access this group represents permissions to any function that
gives a MIDlet suite the ability to add or modify a user’s phone book, or any other
data in a file or directory.
This then, gives us an idea of the possible functionality an application running on
the phone should implement (such as access to the phone book). At the moment, most of the
browser vendors don’t offer access to device APIs and the only options possible are
proprietary. The exception to that is Opera – which was one of the first to announce
this. I expect other vendors will follow.
Ajit Jaokar’s blog about mobile web 2.0 is Open Gardens.
