A JSX presentation would address point 3. JSX would be a tool that would faciliate the AJAX experience of mobile devices.
JSX (or whatever it will be called) will not be using AJAX calls hopefully. However canonical AJAX itself is important if there is no JS<->Aplix Java VM bridge, in order to provide a better user experience than page changing POSTs to a local Web server.
We do this to present and publicise Aplix’s work on ‘JSX’.
In order to foster discussion, talk about a JSAPI standardisation?
JSX is a product initiative by Aplix to improve the mobile web. This presentation sets out to explain why we think JSX is needed, what problems it solves, and how it works.
Everyone is talking about the unparalleled power of the web and its ability to connect individuals, form communities, and mediate between service providers and their customers. This power is changing the technology landscape for nearly everyone who has a PC.
There is naturally a desire to have that same power extended to mobile. After all, a mobile is an inherently connected device and should be naturally suited as a platform for connected applications. There are already more phone subscribers than there are internet-connected PC users, and the next billion mobile subscribers in the developing world will extend that gap significantly. In theory, there is huge potential in the extension of web technologies and services to mobile.
The reality falls a long way short of that promise right now. Even in the most advanced markets (eg Japan) the mobile web is a shallow shadow of the mainstream web. A viable ecosystem exists but technically the systems in use provide a very limited subset of the capabilities of the mainstream web. In other markets the situation is worse; the vast majority of sites and services make no concession to mobile clients, and are unusable or do not work at all. User experience is poor; accessbility problems – already significant – are magnified; content and devices do not interoperate or perform well; and in certain respects the open ecosystems of the regular web are simply not there. These basic problems began several years ago with the first introduction of WAP, and although the industry is working to solve them, progress is painfully slow.
Now, however, there is a new urgency.
There is an attitude shift towards the role of the mainstream web, with the widely held view that it will soon become the dominant way to deliver services to the desktop. The major technology players (Google, Adobe and Microsoft) have all made very significant announcements recently about technologies to support “Rich Internet Applications”. The web is changing from being one medium for service delivery to the medium for service delivery.
Corresponding to this, there is an attitude shift towards the role of the mobile web. Soon, as with all desktop technologies, it will come to mobile in a big way. There is still much work to do, but eventually we all know it is inevitable. Therefore, the major technology companies, service providers, manufacturers and carriers are turning their attention to two questions:
Before we look at the specific barriers to proliferation of the mobile web, it’s worth thinking a bit about why it’s so important.
Many services (mail, chat, weather, news, games, shopping etc) require some interactive application on the phone. (Certain services can work very effectively using only the interactive apps that are already there, such as SMS-based search. But we’re not focusing on that set right now.)
Broadly, there are two ways to provide that interactivity: one requires an client application to be downloaded by the user and installed on the phone. The client application is usually written in Java, but Smart phones also allow client applications to be native (that is, written in a language such as C or C++, and delivered to tbe phone as real executable native code). The other way is to provide the interactivity as a “web application” – this is really just a website, but to the user of the phone it needn’t necessarily look like it is running within the phone’s browser.
Each approach has advantages and disadvantages. Java has proven to be a very successful medium for content delivery, especially for applications such as games that require a very high level of interactivity.
However, just as on the desktop, web applications are an extremely important complement to locally resident applications, and listed here are the characteristics that make them so powerful. Some developers claim that they can be much more productive with web development technologies – especially if they are adapting an existing website aimed at the desktop. For some applications, the power comes from the ability to hook up with existing services already on the web – look at all of the new applications that have been developed, for example, based on the Google maps API. Some say that web apps scale better, because you can access a thousand different websites, but there would be no way you could install a thousand different clients onto your phone.
The issue that service providers cite most often, however, is this: every single day you can improve the user experience. The user doesn’t have to install a new client to get the benefit – it’s just there the next time he visits the site. This is a huge deal for users, service providers and developers and is one of the practical issues that is fuelling the proliferation of web-based services and applications on the desktop.
So, lets think about what the barriers are to replicating the success of desktop web apps on the mobile.
The barriers really fall into two categories. The first category listed here is the factors I would classify as “maturity issues” – they arise because the industry (producers and consumers alike) is young and certain things take time to get right, or achieve practical scale. These issues will get solved over time, through a combination of technical maturity, creation of the right economic conditions, user awareness and supplier consolidation.
The second category of barriers are the genuine technical barriers – even if the other issues went away, these technical problems would still remain. These are the technology issues that companies like Aplix are aiming to solve.
The single most significant barrier is that web apps, in any standardised browser environment, have no way of getting to the mobile platform – such as to communicate with GPS to get location, or to read contacts data from the PIM database. Web applications run in a “sandboxed” environment which allows them to interact with the user and talk back to the website they originally came from.
The reason this is important is that many web apps only become relevant on mobile when this is possible. Take the example of Flickr; I can already upload photos from my PC, but if I had it on my phone, I could upload photos taken on the phone directly, without having to transfer them. In addition, I can tag the photos with my location at the time they were taken. If I couldn’t do either of those things, there would be no point in having the Flickr app on the phone – I’d just download the photos to my PC when I got home. So for a Flickr mobile web app to be relevant, it has to be able to access pictures I’ve taken, and obtain location information if it’s available.
Another technical barrier relates to persistence of offline working. Unlike my PC, a phone doesn’t have a permanent broadband connection. I will want many of my phone apps to work when I’ve not connected, and even if I am, I don’t want to wait for (and pay for) the web page to be downloaded again every single time I access it. (There is also a need for offline working on the desktop, but it is much more critical on a phone.)
Another technical problem relates to data interoperability. Phone manufacturers have invested a lot of effort in providing synchronisation systems to sync phone data (eg contacts) between phone and PC. But on my PC I now use a web-based contact manager, and email system, and calendar. There’s no way for those web apps to interoperate with the databases on the phone – so I can’t get the phone to wake up and sound an alarm when I’m due to go to an appointment.
There’s another set of issues I would associate with the process of taking existing desktop technology and deploying it on an embedded device – issues to do with performance, footprint, reliability, usability, etc. Some of these sound like simple issues to do with maturity, but some have hard technical problems underlying them – like how to get adequate performance and battery life when executing javascript, and how to do on-the-spot editing of Japanese text when the content is inside a web page.
Here are some examples of applications that we would normally think of as web applications on the desktop internet.
Right now, none are possible with the mobile web, because each of them needs access to the platform in particular ways; sometimes just to replicate the functionality of the desktop app, and sometimes because that platform connection is the very reason you’d want the mobile version in the first place.
Mobile local search is an example that is often cited – the ability to perform a local search for services, and show them on a map. Of course, this is possible today with an installed java or native application – but search is an application we associated with the web more than any other. Google introduces new features into its search interface every week – and a web interface allows us to take advantage of them without even noticing anything has changed.
A mobile flickr client is another good example where the mobile client offers an entirely new set of features as compared with the desktop interface. The phone is the camera – so capture, tag and upload can be a single effortless operation – provided the app can access the necessary features on the platform. It can even “geotag” photos if it has GPS.
Social networking – such as with Facebook – can also take on a new dimension if fully enabled by a mobile web app – there’s a list here of the kinds of features you can enable if the intrinsic phone functionality is linked to the functionality of the application.
OK, so now we can turn our attention to this one specific product – JSX.
The primary aim is to address directly the single most important issue – the ability for a web application to access features of the underlying platform. We’ll talk about the particular way we’ve chosen to solve this next.
In doing this, however, JSX begins to address a couple of the other issues. JSX provides a way of making JavaScript APIs deployable, and in doing so it ensures that multiple APIs can coexist within an single web application without interfering. It does this mainly so that the “platform” APIs themselves are deployable, but a side-effect is that that any web APIs can use the framework to coexist without interference. It is hoped that this will help to kickstart an ecosystem of web API development for mobile.
The other subsidiary benefit is that these APIs or enablers deployed using JSX technology are largely interoperable between platforms and browsers; and in those cases where they’re not, the enablers can be used to mask underlying platform differences so they are invisible to the web apps themselves. This begins to ease the fragmentation problem.
What JSX provides is a connection between the web application environment (that is the browser, usually) and the Java runtime that is present on nearly every handset today. What it allows the web developer to do is deploy a java library along with the web application – so the code in the web application can make calls to the java library. The real power of this comes from the fact that the java library can access platform features, through a wide range of standardised java platform APIs defined as profiles (commonly known as JSRs). There are profiles that allow a java library to access:
In practice, a web application developer won’t want to develop a java library each time a new web page wants to access the location data (say); and a user won’t want to install that library each time he visits a new site that uses it. (That would take away from one of the main aims of web apps, which is to avoid the need for the user to perform this kind of installation.) So, JSX expects in fact that a series of JavaScript APIs will be developed, and each of them only needs to be deployed to the device once, no matter how many different web sites make use of them. So we’ve built JSX so that it supports the deployment of JS APIs (which are a combination of a Java library, and a JS wrapper that instances the library), and the management and coexistence of those APIs.
The concept behind JSX is really quite simple. It hooks into the browser (or other environment – it’s not limited to the browser) in the same way that a traditional browser plugin works.
A web page invokes JSX by referencing an asset of a particular type – in this case a java library we’ll call a “JSX control” – and the browser invokes a specific registered handler for that content type (in the same way as it would for a particular image or media type). In our case the registered handler is the JSX plugin. This instances a Java VM, which loads the library referenced by the web page.
The JSX plugin responds when scripts in the web page make function calls on it – in fact what it does is forwards the function calls to the Java VM, which in turn makes corresponding calls into the java library. In effect, therefore, the JSX plugin allows the API exported by the java library to be made visible to the web app programmer.
Obviously, the JSX plugin takes care of all of the details associated with mapping language types between JavaScript and Java, handling language exceptions and other errors when they occur, and so on. It also handles the (extremely important) issue of mapping the security context of the web app to a security context for the java VM, so arbitrary web pages do not get to make unauthorised calls to sensitive Java APIs.
Here’s a diagram showing how JSX, the VM and the web app fit together.
As mentioned before, it is likely that developers will deploy JS APIs that reference JSX controls, rather than have them directly referenced by their applications. In order to support this, it has to be possible for both the JSX control and the JS module that binds to it to be deployable.
Of course, within a browser it is already possible to reference a JS API simply by referring to it in a tag. However, referencing many JS modules this way can be problematic when there are complex apps that could give rise to multiple inclusion, conflicts in the global namespace, load-order dependencies between modules, and contention for certain events (such as the onload event).
The community is beginning to address this problem by defining frameworks to allow modules to be developed independently and then combined within an application without conflict. JSX includes such a framework, which additionally takes care of the installation of java libraries, and persistent storage of permissions associated with those libraries.
With this framework in place, there are further clear benefits to JSX. The biggest single benefit is that these new APIs (say a location API, or a PIM API) do not need to be embedded in the phone and, more important, do not need to be defined by a single committee as is the case with JSRs in Java. Now, any interested party can define their own APIs to suit their own purposes, so long as the underlying functionality needed is available via a Java profile. These APIs can evolve to meet changing requirements.
Of course, it would be great if industry bodies got together to define useful JS APIs – and some are already doing this (like the W3C). However, exploiting JSX does not have to wait for this to happen. APIs can be created and deployed by publishers, carriers or manufacturers as needed, and superseded by standard APIs once they become available.
So, what are the benefits of JSX to a content developer?
Most important, they get the ability to make web apps integrate properly with the platform, but avoid the user-install and management problems associated with java apps. Wherever a given Java profile is available, the corresponding features become available to web applications.
It means that the developer can avoid using browser-specific APIs, which fragment the application. Opera are deploying some Opera-specific APIs to provide access to the platform, but apps developed to these obviously won’t work in any other browser. The developer also has the opportunity to develop middleware that further hides platform differences from the application.
Finally, the JSX mechanism has no dependency on HTML or any other specific details of the markup language. Any environment that uses JavaScript or a similar language can use JSX – for example, SVG or SMIL players, or widget engines – and the developer can begin to create common middeware that spans these multiple environments.
The benefit to the browser manufacturer is that web applications can become fully fledged applications alongside native apps. This vastly increases the relevance of the browser environment for carriers and developers.
By using JSX, the browser manufacturer avoids the need to define proprietary APIs.
The browser manufacturer can also benefit from a simplified porting process. For each of the platform interfaces that exists (ie PIM, location, etc) there would normally need to be a porting and integration effort for each handset model that the browser is ported to – and this can be costly and timeconsuming when there are co many interfaces and so many device models. With JSX, this effort can be largely avoided because all of the hard work has already been done by the VM supplier.
Also, by contrast with Liveconnect (which is a very deep integration between JS and Java), JSX does not require any disruptive changes to the browser or its scripting engine. Any browser that already supports DOM scripting of handlers can support JSX without modification.
The benefits to the carrier derive from the greater value that can be delivered to the user via web applications. Anything that makes the network more valuable to the user, and promotes connectivity and communication, brings value to the carrier.
Carriers are often concerned about security, and opening the platform to web apps is clearly something that raises potential security hazards. It is essential to have an effect and robust security framework in place, so that only trusted web sites can gain access to sensitive platform information or services. JSX leverages the significant investment into security infrastructure in the Java VM, and will provide a security model (that is, permissions and trust model) that is familiar to carriers.
Carriers are also wary of the potential for fragmentation arising from the multiple Rich Internet Application (RIA) technologies that are coming about. JSX provides a means of unifying at least parts of the application and service architecture around a platform standard that is independent of Microsoft, Adobe and Nokia.
Finally, JSX with its JS module framework, should be able to kickstart a mobile web API ecosystem, which ultimately will reduce the costs of creating and deploying web-based mobile services, and benefit users and carriers alike.
So, how are we bringing JSX to market?
Essentially, JSX is offered as an optional extension to our hugely successful JBlend product. In order to deploy the product, some inetgration work is needed between the browser and the JSX plugin.
We will offer pre-built plugins for those environments that are sufficiently open and standardised for us to do the work independently; and we’ll offer an SDK so that OEMs can integrate with their chosen browser and environment where required.