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.