SVG Tiny 1.2 brings AJAX to the world of mobile SVG

For the SVG Open 2007 conference

Keywords: Mobile AJAX , SVG , ODP , Mobile TV

Mr Andrew Sledd

Ikivo AB
Östermalmsgatan 87C
Stockholm
Sweden
andrew.sledd at ikivo.com

Mr Torkel Hambraeus

Ikivo AB
Östermalmsgatan 87C
Stockholm
Sweden
torkel.hambraeus at ikivo.com


Abstract


The programming paradigm AJAX is increasingly used when creating applications for the web. The basis of the paradigm, consisting of asynchronous communication and updating of only changed data on a web page, is well suited for the mobile domain both due to the reduction of amount of transferred data as well as the reduced processing power needed. The paradigm can be used in conjunction with different application environments among them SVG Tiny 1.2. Since SVG Tiny 1.1 has been very successful on the mobile domain with a high level of market penetration it is expected that the new standard 1.2 will open up the mobile domain for SVG based AJAX solutions. A typical application using AJAX on a mobile device is discussed in the paper.


Table of Contents


1. Introduction
2. AJAX support in SVG
3. Typical AJAX application
4. A practical example
5. What does the future look like?
Bibliography

1. Introduction

AJAX (Asynchronous JavaScript and XML) is a programming paradigm that has evolved on the world wide web. The goal with AJAX is to relieve the user from the feeling of utilizing a page by page build up application where any user action results in loading a new full page and instead give the user the feeling of an interface with high responsiveness, similar to a local application. The improvement is achieved by applying a programming paradigm with two key components:

When using scripts in traditional web to retrieve data the same script is used both for requesting the data and managing the received data. The script is thereby blocked while it is awaiting the new data. The impact of the first principle of AJAX, asynchronous scripting, is that one script is used to requests the data and sets up a callback script that takes care of the data when it appears. This prevents a blocking situation during the transfer of data and enables the system for other processing which means a smoother running application.

The second principle of AJAX, retrieval of only that data which has changed, avoids reloading of entire pages. Only the data changed is transmitted and used to modify the existing page. The benefit is that a lesser amount of data is transferred from the server to the client since the entire page is not reloaded, only new data needs to be transferred. The user will not see a complete reload of the page, animations on the page will not be interrupted thereby increasing the feeling of smoothness in the appearance of the application.

AJAX has been successfully implemented on the stationary web in conjunction with HTML. The paradigm can be extended and enhenced into the mobile domain and used together with other XML languages such as SVG. By its nature AJAX is well suited for the mobile domain. Mobile devices are constrained by connections with low or costly bandwidth. The bandwidth needed in an AJAX application is lower than that of a traditional web application since redundant information is not retransmitted. The devices themselves have limited processing power and thereby are benefited by only having to do limited changes to the data model. AJAX also fulfills this requirement since the data model held locally is modified in the response request cycle, rather than being disposed only to create room for a completely new model containing mostly the same data as the old. Adding functionality in scripts gives cross platform compatibility which is a desired feature in the diversified mobile environment which contains different operating systems and hardware configurations.

There are already application environments targeting mobile devices and more are under development. Some of the more familiar environments are XHTML, FlashLite and JAVA. All of these offer platform independent application development and allow client server type of applications. The market penetration ranges from good to fair. The differences between the environments is however large. XHTML is a XML language and being a W3C standard has the advantage of not being encumbered with IPRs. The community for XHTML development on the stationary web is large and developers are readily available for the mobile web application development.

FlashLite is a mobile version of the familiar Flash system on desktop computers. The system is proprietary and although the system has been successful on the stationary web it has only gained success in certain geographical regions on the mobile web.

JAVA is well spread in the mobile world. In difference to the other two this is a programming language and targets a different segment of the development community than the others. Programs need to be installed prior to execution and prohibiting the easy “click, download and run” cycle that is possible with the others environments. The JAVA extensions JSR287 and JSR290, which are under development, bring parts of the SVG and XHTML world to the JAVA programmer. The packages give the JAVA application access to the graphics of SVG and also to the document object model, DOM. However these JSRs do not remove the necessity to install the client application.

There are also application environments under development. Both the third generation partnership program, 3GPP and the Open Mobile Alliance, OMA, are developing rich media application environments for the mobile domain. They both use SVG Tiny 1.2 as the backbone for the application environment and have added an update mechanism. The update mechanism allows changes to be performed on the data model without reloading the entire model, but in difference to AJAX, where the requests are driven from the client, these environments are pushing out changes from the server. The environments have defined the formats of the updates and limited them to simple insert/replace/delete operations on the data. The updates are also designed to handle synchronous changes of different parts of the data model. Since both specifications also require support for scripting the there is a backdoor open to combine the updates with the AJAX paradigm.

SVG is a technology well suited for the mobile domain with the tiny profile. SVG Tiny has been deployed on more than 300 million devices world wide. Vector graphics in 3GPP networks is mandated to be SVG. Devices with SVG support are evenly spread over the world and not contained to certain geographical areas. The scalability and platform independence is intrinsic in SVG. SVG 1.1 has been interpreted by the market as an advanced drawing format, allowing not only stationary graphics but also animations to be created in a space efficient manner. The advancement of SVG Tiny from 1.1 to 1.2 has provide the missing pieces needed to move SVG Tiny from a simple graphics viewer to an applications environment for AJAX applications.

2. AJAX support in SVG

From the introduction it can be concluded that an environment for AJAX applications must contain the following standardized components:

Whereas SVG Tiny 1.1 only contained the last one of these components the advancement to SVG Tiny 1.2 provided the remaining three. The data model is in SVG Tiny 1.2 provided by the uDOM that, even though the uDOM is a sub-set of full DOM, contains sufficient methods for manipulating all data in the model.

The communication methods that are essential for AJAX are the http request methods. These are provided in the SVGGlobal interface of the uDOM. This interface contains the functions getURL, postURL and parseXML. The basic client server communication is thereby provided and the received data can be processed in a standard way using the parseXML method.

The inclusion of a uDOM in SVG Tiny 1.2 gives the possibility to add generic scripting, the glue that binds together the components of an AJAX application. All modification of the data model and steering of the communication is provided by the scripting. The SVG Tiny specification provides bindings to multiple scripting languages but in the mobile world EMCA script has a predominant role and the bindings to this language are the most important for this user group.

3. Typical AJAX application

Applications that benefit from the AJAX paradigm are applications that:

Most, if not all, web application contains user interaction and all web applications contain client server interaction. What need to be explored to decide if the application is suitable for the AJAX paradigm is if the changes to the data model are sufficiently small so that the work in updating the model does not exceed the work in downloading a new page straight away. It turns out that many popular mobile web applications only do limited changes to the data model. Examples of such applications are MobileTV applications, On Device Portals, Music Portals and shared photo libraries.

The basis of these applications is a user interface that manages interaction with the server. For the MobileTV case data such as updating an electronic program guide is a typical example. The interface and the displayed TV image should be retained while the list of coming programs is updated, by adding new information and removing old information that is no longer valid. Reloading the entire page to perform such an update would be very disturbing to the user.

4. A practical example

AJAX style programming can be used in a multitude of applications as discussed above. A practical use case is a so called On Device Portal, ODP. An ODP is a navigation page on a mobile device that acts as an interface to functions and information on the web. The functions can be news tickers, advertisements, music portals etc. The exact functionality included in an ODP is the choice of the application developer and the ODP can be used to give the mobile device a special appearance; the right look and feel.

One of the key requirements on the ODP is that the user experience is equal to a fully local application. Blank screens while loading pages are not acceptable and data retrieval cannot block the application usage. Asynchronous communication is thereby an implicit requirement. In its structure an ODP application is similar to any menu driven system where the activation of a menu item results in an action. The figure below shows an example of an ODP screen shot.

ODP.png

Figure 1: Sample of ODP application

The ODP could be created in any of the aforementioned environments. The reason for choosing SVG together with ECMA script is that SVG offers full graphics capabilities, which is necessary to give the ODP a high quality look. The inherent scaling of SVG allows the same ODP to be deployed over a number of different devices while retaining the same look. This is favorable in mobile services where the heterogeneous flora of devices requires graphics that scales well.

The ODP application is structured basically according to the diagram in figure 1

ProgStruct.png

Figure 2: ODP program structure

The dynamic process when starting the application is as follows:

  1. The data stored locally on the device is loaded to present the initial screen of the ODP.
  2. The start-up script makes http-request to get updates for images and fragments that needs to be updated.
  3. User input is served by executing scripts in responses to menu activations.
  4. Eventually the user terminates the application and the application closes.

The actions resulting from menu activations can be divided into the following categories:

The first action is the traditional web application approach were every action requesting new data results in a new page being loaded from the server. The second type of action is the one of interest to the AJAX programmer. There are different means in which the data can affect the presentation on the device. In the first, most straight forward, the data returned from the request is in a format that can be directly inserted into the data model. In the second the data is in raw or application specific format that needs processing prior to usage in the data model.

The code example below show the general layout of an SVG based ODP application. The code contains the sections script, listeners and handlers, and graphics.

<svg version="1.2" baseProfile="tiny">
					
<!-- Script section -->
					
<script type="application/ecmascript" > <![CDATA[

    <!-- Callback script function replacing a node in the tree. -->
    function replaceNewsLine(cbData){

      if(cbData.success)
        {
	  var newsLineG   = document.getElementById("newsLineG");
          var newNewsLine = parseXML(cbData.content, document);
	  var oldNewsLine = document.getElementById("newsLine");
	  newsLineG.removeChild(oldNewsLine);
	  newsLineG.appendChild(newNewsLine);
        }
      else
        requestStatus = "Error"
      }

    <!-- Event handling function setting up the data download -->
    function requestNewsLine(event){
      getURL("http://channel.news.mobil", replaceNewsLine);
    }
    

  ]]>
</script>
				
			
<!-- Listeners and Handler section -->
				
<ev:listener ev:observer="updateButton" ev:event="click" ev:handler="uC" />
<handler xml:id="uC" type="application/ecmascript">
			requestNewsLine(evt);
</handler>
				
				
<!-- Graphics section -->
				
<!-- Group containing menu item 1 -->
<g id="newsLineG">
	<text id="newsLine">  <!-- Here goes the newsline text -->  </text>
</g>
				
<g id="updateButton">
	<!-- Here goes the graphics describing the update button. --> 
</g>
				
</svg>

			
		

The example here contains scripts of the first type. That is scripts that retrieve data which can be directly inserted into the data model. The coding in this case becomes very straight forward and most of the logic is placed on the server which needs to prepare the data in the correct format for insertion into the data model.

5. What does the future look like?

SVG Tiny 1.2 together with a script engine offers an application environment that is useful for mobile devices. For the market to grow it is necessary that the coming generations of mobile devices are fitted with SVG Tiny 1.2 engines and with scripting support. Such engines are available today from various vendors. Ikivo, Bitflash, and Opera among others offer such solutions for the mobile domain. The SVG uDOM contains support for modifying the data model and handling the communication with the server. This is the backbone functionality in web applications and allows creation of many useful applications. However the demand for increased functionality arises quite fast and a few more functions are desirable to be able to create even more advanced applications. Allowing scripts to interact with the device is a desirable feature. This would allow the application to launch other device applications such as the calendar, messaging tools etc. The ability to store information in between consecutive runs of and is also a desirable feature. This would allow the storage of user preferences and thereby make the start up of the application more user friendly. Not the least, a method to exit the application gracefully is needed. Currently there are no standardized APIs for these functions in the scripting API and applications that make use of these functions must rely on proprietary solutions. To maintain the highly desirable interoperability requirements it is desirable that these extensions are standardized in some open standard and do not evolve into a number of proprietary standards.

Extensions along these lines does however raise questions about how to handle security issues. Allowing scripting and access to device functionality in the same application opens up a new set of security concerns. In the near future the framework will have to rely on security mechanism already present on the device. It is expected to in the future see a number of mobile AJAX solutions based on SVG.

Bibliography

[SVG]
Scalable Vector Graphics (SVG) Tiny 1.2 Specificaiton W3C candidate recommendation 10 august 2006 http://www.w3.org/TR/SVGMobile12/
[ECMA]
ECMA 262, ECMA Script Language Specification 3rd Edition. European Computer Manufacturers Association. http://www.ecma.ch/ecma1/STAND/ECMA-262.HTM

XHTML rendition made possible by SchemaSoft's Document Interpreter™ technology.