Web Technologies Technical Overview

From Symbian Developer Community

Web programming for mobile is attractive owing to the large number of developers and designers who are skilled in Web development, and many feel that ‘Web programming’ has a much shallower learning curve compared with C++.

This article discusses the type of applications that can be developed using Web technologies. It discusses the support for Web technologies on Symbian-based devices and covers widgets, mobile browser optimization and Web development tools. While it is for a technical audience, the aim is not to provide information in great detail, but instead to refer to external resources where appropriate.

The target readers for this article are software engineers or managers with some technical background, who want to explore the capabilities of Web technologies on the Symbian platform.

Technical Overview of Web Technologies on the Symbian Platform

Web technologies can be used on the Symbian platform in two different ways. The user can launch a Web browser, type in the URL (or use a bookmark) and view the Web page inside the browser. This can be a time-consuming task on mobile devices without a QWERTY keyboard and small screen, so an alternative is to package up Web application functionality (pages, scripts etc), install them locally on the device and run them outside the browser as a standalone application.

These small applications are called widgets. They can be started from the application menu like any other application and typically perform small, focused tasks, or can be included on the phone's home screen.

This is illustrated in the pictures below. Figure 1 shows the Symbian developer forums page in a WebKit-based mobile browser. Figure 2 shows the widget as it appears in the Applications menu, in the same manner as native apps. Figure 3 shows the widget based user interface for developer.symbian.org forums.

Widget operation is enabled by the Web Runtime (WRT). Web Runtime is a set of components in addition to the WebKit browser, allowing widget installation, loading, network and device access etc.

Widgets may use a network connection to get ‘live’ data from a server via AJAX (Asynchronous Javascript And Xml) calls. Also, widgets have access to the device APIs which are not available when running in the web browser (e.g. GPS, access to contacts, calendar or sending SMS messages). One example using GPS API is the Forum Nokia Route Widget.

Both these approaches use the same underlying technologies, namely HTML (HyperText Markup Language), JavaScript^TM and CSS (Cascading Style Sheets), and both rely on the browser or the Web Runtime to support this functionality. So if you know those technologies already, it will be very easy to get started.

Note: if you aren't that familiar with web programming techniques and want to learn more, visit HTML Dog for a good introduction to HTML and CSS, and W3Schools.com to learn JavaScript).

Widgets and the Web Runtime

Widgets offer seamless integration between Web technologies and local applications. A widget can be selected from the phone’s application menu and the HTML and JavaScript loaded locally. Not only does this improve the loading time for a Web app, but it also spares the user from having to type a URL to access the widget, which is awkward on a mobile device.

The next few sections will describe how you can create your own widgets, package them up and test them. You will also learn about tools, security and the distinction between WidSets and widgets.

Creating a Widget

If you are familiar with Web technologies such as HTML, CSS and JavaScript, then creating a widget is easy. Dive right in with the Web Runtime (WRT) Quick Start. It’s similar to creating a normal Web page, which is packaged up into a compressed file. These are the main steps to follow in preparing a widget:

First, you create an HTML page that defines the structure of your widget’s main page. This is the page that appears when you launch the widget from the phone’s application menu. The Web Runtime does not allow this main HTML page to be replaced during runtime, but it is possible to launch additional HTML pages in the Web browser, using the widget.openURL() method.
Next, you create one or more Cascading Style Sheets files, which define the formatting and style of your HTML page. It is best if you create separate files for the CSS information and link to them from the HTML file (using the ‘link’ tag) rather than embedding the CSS elements directly into the HTML file. For example, it is possible to create one CSS file for devices with touch support and another one for devices without.
The core logic of your widget will be defined in one or more JavaScript files. As for the CSS files, create separate files and load them using the <script> tag inside the HTML file (thus allowing the use of JavaScript libraries packaged within the widget). In a JavaScript file, you can implement the dynamic behaviour of your widget. This includes event handling, the creation of menu items, the access of service APIs, and changing the appearance of the Web page itself.
Every widget needs to have an Info.plist file, which stores information about the widget itself. This includes the title of the widget, a unique identifier, the name of the main HTML page and optionally a request for network-access rights and version number. Info.plist needs to conform to a DTD defined by Nokia.

Examples

We've found a few good examples to further explain the process of creating widgets for Symbian-devices:

Nokia provides a very good widget e-learning course and a Getting Started with Nokia Web Widget Development guide on its Forum Nokia website. Detailed technical information about widgets can be found in the Forum Nokia Web Developers’ Library.
An example widget implementation can be downloaded from Forum Nokia. Note: the version of the widget is different to that used by the e-learning, which also discusses the Accu widget, but shows code that is older.
The WRT Wiki Page on Forum Nokia helps with commonly encountered problems and provides a large number of code examples.
Another good starting point is a tutorial on NewLC.com, which explains the creation of widgets in basic terms and is helpful, although slightly dated.

In addition to retrieving local information through device APIs, as discussed previously, a widget can also use asynchronous XML HTTP requests (also known as AJAX – Asynchronous JavaScript and XML) to retrieve data from a Web server. This is done by creating an XMLHttpRequest object and registering a call-back function on it (using the onreadystatechange property). This call-back function is then called when the response from the server has arrived. Further information on using AJAX with mobile widgets, including example code, is available from IChoose - An Introduction to AJAX.

Access to Device Data and Platform Services

Access to local data on the device is achieved using a set of platform services APIs.

Local device information is queried by JavaScript code through the platform services APIs. These service APIs are provided by the Web Runtime (WRT) which is included as part of device firmware. WRT 1.0 was introduced as part S60 3rd Edition FP2 (though some 3rd Edition FP1 devices will support WRT 1.0 after a firmware upgrade). WRT 1.1 is supported in 5th Edition and the Symbian^1 platform.

Widget object API

A widget object is a JavaScript object that extends the window object. It can be used to set the screen to landscape or portrait mode, open URLs in the mobile Web browser or launch native applications. It also defines event handlers that are called when the widget is brought to the foreground (window.widget.onshow) or background (window.widget.onhide). These methods can be used to update the content of the widget when it is shown, or cancel outstanding requests to a server when it is hidden.

Menu object API

The menu object is used to create the options menu (typically placed on the left softkey) and to change the label of the right softkey. In order to create the options menu, you need to instantiate the menu items and append them to the menu, using the window.menu.append (MenuItem menuItem) function. An event handler (window.menu.onShow) is called when the user opens the options menu.

MenuItem object API

For each menu in the options menu, you have to create a MenuItem object. The constructor of the MenuItem class expects two arguments, the label of the menu item and an identifier. You can also append child menus to your menu item (using MenuItem.append) and set menu items as dimmed (MenuItem.setDimmed).

Device object API and service object API (WRT 1.1 only)

This is a major addition in WRT1.1. It allows better integration of widgets to the more sophisticated services of the Symbian platform.

The device object is used to retrieve a service object, which in turn can be used to retrieve information about platform services. This is a two-step process. First, you use

 
var so = device.getServiceObject(provider, interface);

to retrieve a particular service object, and then you call methods on that object.

There are many platform services APIs available, including APIs for:

Launching applications (AppManager Service API)
Accessing and adding calendar entries (Calendar Service API)
Managing contacts (Contacts Service API)
Organising landmarks (Landmarks Service API)
Retrieving the device location (Location Service API)
Logging support (Logging Service API)
Retrieving information about media files on the device (Media Management Service API)
Sending and retrieving SMS or MMS messages (Messaging Service API)
Querying sensor data (Sensor Service API)
Accessing and modifying system information (SystemInfo Service API)

For example, to add a contact to the device’s local address book, first get the appropriate service object:

var so = device.getServiceObject("Service.Contact", "IDataSource");

and then call the appropriate method on it (so.IDataSource.Add), passing in the appropriate arguments.

Note that although the user has to confirm the installation of a widget, some of the APIs above require the user to grant additional access after installation.

Reference Documentation

A detailed explanation of the available APIs (including example code) can be found in the Forum Nokia Web Developer’s Library.

Widget Packaging and Deployment

Widgets can be deployed to any device that has the Web Runtime environment included, but first you need to package all the content into a ZIP file (using any of the available ZIP applications). The file extension is then renamed to .wgz; this step is required so that the file is recognised by the installer on the mobile device.

The ZIP file needs to adhere to a particular structure, where some files are required to be in the root of the ZIP file. The following list states which files are mandatory or optional:

Info.plist is a mandatory file that needs to be located at the root of the ZIP file.
The main HTML file is a mandatory file that needs to be located at the root of the ZIP file.
An Icon.png can optionally be provided in the root of the ZIP file. This file represents the icon of the widget, which is shown in the application menu of the device. The recommended size of the image is 88x88 pixels. If no icon is provided, a generic default icon will be displayed instead.
CSS files are optional and can be stored in the root or a subfolder.
JavaScript files are optional and can be stored in the root or a subfolder of the ZIP file. Alternatively, JavaScript files can also be loaded from a remote location by providing a URL inside the ‘script’ tag in the HTML file.
Image files other than Icon.png can be located in any location in the ZIP file and can be either in PNG or JPG format.

Once the ZIP file has been created, you can deploy it like any other Symbian installation file, for example via Bluetooth, USB, e-mail or memory card. If the widget is installed from a Web page, remember to set the correct MIME type for the file. For the Symbian platform, the MIME type should be set to x-nokia-widget. Consult your Web-serving technology documentation for instructions on setting MIME types for content.

Aptana Studio for Widget Creation

You don’t require any special tools other than a text editor (preferably with support for syntax highlighting) and a ZIP application to create a widget. However, you might want to consider installing Aptana Studio which is supported by Windows, Linux and Mac OS X.

There is an additional plug-in for Aptana Studio specifically for creating widgets for Symbian devices. The plug-in provides a number of additional features such as debugging, packaging and deployment support. Further information is available here and you can find a handy, and very complete guide to installing and using the Aptana Studio plug-in here.

The Web browser supplied with the Symbian platform emulator has a JavaScript console enabled for debugging widgets that use device-specific APIs. However, if you do not wish to download a Symbian C++ development SDK to access the emulator, you don't need to, since you will find Aptana Studio sufficient for most testing prior to deploying a widget to a device for further testing. This makes development for Symbian devices accessible to Mac OS and Linux users as well as those using Windows.

Note: The Aptana Studio plug-in provides a Select Device pop-out menu in the widget preview mode which allows you to reflect the screen resolution of a chosen device and, where appropriate, test switching between screen orientations.

Figure 7 A security warning is shown to the user when they run a widget

Security

The security model for widgets is different to that for native applications. To start with, widgets don’t have to be Symbian Signed or certified. They are sandboxed. Access to platform services has to be granted by the user (see Figure 7) and is managed by a component called the runtime security manager (from WRT 1.1 onwards).

Detailed information about widget security can be found in the Forum Nokia Web Developer’s Library.

Testing on the Symbian Emulator

Widget testing can be performed on using Aptana Studio, on the Symbian emulator and on the target devices (which must support WRT).

S60 3rd Edition Feature Pack 2 SDK and the S60 5th Edition SDK support WRT 1.0 and 1.1 respectively (you need to register at Forum Nokia to download the SDK). Install one of those SDKs and then launch the emulator. Because most widgets require networking capabilities (to talk to an external server), make sure the settings on the emulator are correct. You can find the settings in the emulator window under Tools | Preferences.

Copy the WGZ file to the emulator file system. For example, copy it to {SDK Installation Directory}\epoc32\winscw\c\Data\Others.
Launch the emulator and open the file manager (on Symbian^1 emulator it can be found under 'Organiser').
Open the WGZ file from the file manager. This will install the widget.
Once installed, the widget can be launched like any other application from the emulator’s application menu.

Coding for the Mobile Web Browser

Modern mobile Web browsers like the one on the Symbian platform can render and display Web pages in the same way they appear on a desktop browser; many devices now use browsers based around the open-source WebKit rendering code that is also used in the Safari and Chrome desktop browsers. Do we then still need to consider mobile use cases separately from the desktop?

Supported Web Standards

From a Web standards perspective, there is little difference between a desktop and a mobile browser.

The Web Browser Product Description lists and describes the supported standards and features of the Web browser of the Symbian platform in detail, but core standards include:

HTML
XHTML
CSS
DOM
SVG-Tiny
JavaScript

The Symbian platform Web browser is based on the WebCore and JavaScriptCore open-source components and therefore benefits from contributions from the open-source community. Please note that phone manufacturers may choose to use a different browser on their devices. Users also may want to install additional third-party Web browsers, although they can't uninstall the browser that ships in ROM.

Designing for Mobile Browsers

Issues that affect browsing usability on mobile devices include display size, input mechanisms, processor speed and the costs of data transfer. Directly displaying content intended for desktop display on a mobile platform can use significant resources and produce a poor user experience. With smooth and sophisticated zooming, and support for touch screens, mobile browsers can comfortably navigate much of the standard Web. However, just because a page renders does not mean it offers good usability for mobile devices, and developers should follow the W3C’s Mobile Web Best Practises in order to understand usability and efficient issues affecting the mobile browser.

A key area that affects the usability of Web pages on mobile devices is the bandwidth and latency of mobile network connections. This is not a problem when using WiFi connections, but 3G or GPRS connections have less bandwidth and a higher latency than is typically available on a desktop computer. The browser cache on mobile devices is implemented in a way to mitigate those issues. Section 2.4 of the Nokia Web Browser Design Guide recommends a number of ways to improve the utilization of the browser cache. This includes the use of expiration headers for cached content to avoid unnecessary connections to the server and the re-use of CSS files, images and scripts. Understanding how the Web browser’s cache algorithms work can also help you to implement efficient Web pages.

One way of optimizing content for mobile is to use a pattern such as Nokia’s Progressive Enhancement, which aims to create a simple website that provides all the required functionality first, and then extends it via external CSS, JavaScript and Flash (Lite) files. JavaScript running on the client can then decide what elements of the additional functionality can be supported, and CSS files can be dynamically modified to suit the smaller screen. For example, this approach can be used to fetch reduced-resolution images suitable for the mobile display by detecting the device screen size through JavaScript, and thereby reducing network traffic, power consumption and memory use. Using the client to make the decisions on optimizing content to fit the available hardware can also help to reduce server load.

Another way to improve the speed and layout for mobile is to filter and modify the Web as it passes through a gateway or proxy. The gateway detects the type of browser (using the user agent information in the HTTP message) and provides a special version for mobile browsers. This approach is, for example, used by the Opera Mini browser, where the ‘full’ website is pre-processed before being sent to the client. As a drawback, you have to maintain and continually test multiple versions of the Web pages on a potentially large number of mobile devices, and the load on the gateway can be significant. Some network operators in some localities now provide this type of service by automatically transcoding content that passes through their gateways, a process that may be more or less transparent depending on implementation.

For further discussions on philosophies for designing mobile Web pages, visit the Mobile Community Design website, the Little Springs Design Wiki or read the article about Designing for the Mobile Web.

Development Tools

No special development tools are required for implementing Web pages for mobile devices, because all the normal Web development tools can be reused. An AJAX-capable JavaScript library is often essential in practise for cutting down on network traffic between the mobile client and a server. Additionally, tools to make it easier to create widgets (discussed in the Widgets and the Web Runtime section later in the article) are available.

However, because it is good practise to test the resulting pages early during the development stage, it might be worth considering how the Web pages are tested to validate whether they are usable on mobile browsers. The next section discusses a number of testing approaches.

Testing Approaches

Although from a testing perspective, the mobile Web browser can be treated in a similar way to any of the other popular desktop browsers, there are several approaches to testing Web pages on mobile Web browsers that can improve or simplify the testing process. These include:

Resizing the desktop browser window to simulate a smaller screen size. This is a quick and simple way to test a Web page during early stages of development. Note that there are some things that cannot be duplicated by resizing. The text-wrapping algorithm used on the mobile browser will give different results – therefore do not rely on the method entirely.
Using IFrames to simulate a smaller screen size. An IFrame allows you to embed an HTML page into another one, for example:

 
<iframe src="http://developer.symbian.org" width="240" height="320" />

would display the developer.symbian.org webpage in a frame of fixed size 240x320 pixels. Because you can specify the size of this embedded frame, it is ideal for testing smaller screen sizes (see Figure 5). The same limitations as apply to resizing (above) also apply to this method.

Using the emulator from the software development kit (SDK) is a more sophisticated approach, however, because it uses a WebKit-based browser, the same as is installed on the mobile platform. Because Web pages are rendered in a similar manner on the emulator as on the actual device, best practise is to test Web pages on the emulator throughout the development phase. Another advantage is that the emulator lets you change screen resolutions very easily. Note however that the emulator’s Web browser may run faster than a typical mobile device (the CPU is not emulated).
Using real hardware is obviously the ideal way to test mobile Web pages. The major manufacturers offer remote access to devices in order to ease the burden on developers, who might otherwise have to obtain different devices with different screen sizes and input mechanisms for testing. Nokia provides several options including Remote Device Access. Sony Ericsson offers a virtual device lab service, and Samsung has Lab.dev.

All these approaches are discussed in Section 3.3 of the Nokia Web Browser Design Guide.

Figure 5 You can use IFrames to simulate a particular device display size. Here, we’ve forced SDN to appear in a QVGA-sized (240x320) IFrame

Special attention should be paid to testing embedded content such as Flash Lite animations, audio or video displayed from within your widget. While the Web browser on the Symbian platform supports a number of embedded media types and it is extendable via plug-ins, it is possible that not all embedded elements are supported. As a result, it may be necessary to redesign and re-implement the Web page in question in order to accommodate the capabilities of the mobile Web browser. Also, different mobile browsers (or earlier versions of the browser on S60) may well have more limited support for embedded content than the Symbian platform browser.

Embedded Media Considerations

It’s good practise to avoid embedding large objects such as video or audio files into a Web page for the reasons already discussed (latency, bandwidth), but if those elements are core to the functionality of the Web page then this is unavoidable. The mobile Web browser on the Symbian platform supports a number of media formats and most of these formats can be displayed or played directly in the browser, without launching an external player:

Supported video formats include 3GPP, MP4 and Real Video (version 7, 8. 9, 10).
Supported audio formats include Real Audio Voice, WAV, MP3, MIDI, MPEG4, AMR-WB, AMR-NB, AAC, and EAAC.

Because mobile platforms are generally resource-limited compared with their desktop equivalents, some popular content formats and standards are mainly available on mobile as dedicated profiles or variants. SVG support on mobile is generally in the form of SVG-Tiny (SVG-T), while Flash Lite is a Flash profile targeted at mobile platforms. Both have reduced feature sets compared with their desktop equivalents, but you can use JavaScript to detect programmatically whether the browser supports Flash or Flash Lite. You can find an example for such a client-side check in Section 6.2.1 of the Nokia Web Browser Design Guide.

Summary

This article has outlined the type of applications that can be developed using Web technologies, the support for Web technologies on Symbian-based devices and covers widgets, mobile browser optimization and Web development tools.

Related Info

Further information can be found on the Forum Nokia documentation pages.

You can also get support by posting questions on the developer discussion boards on this site or on Forum Nokia.

Retrieved from "http://developer.symbian.org/wiki/index.php/Web_Technologies_Technical_Overview"

Comments

Category: Web technologies

Web Technologies Technical Overview

From Symbian Developer Community

Contents

Technical Overview of Web Technologies on the Symbian Platform

Widgets and the Web Runtime

Creating a Widget

Examples

Access to Device Data and Platform Services

Reference Documentation

Widget Packaging and Deployment

Aptana Studio for Widget Creation

Security

Testing on the Symbian Emulator

Coding for the Mobile Web Browser

Supported Web Standards

Designing for Mobile Browsers

Development Tools

Testing Approaches

Embedded Media Considerations

Other Interactive Content Authoring and Web Services

Flash Lite

Java MIDlets

Combined Technology Approaches

Web Services

Summary

Related Info

Comments

Views

Navigation

Toolbox

In other languages

OUR SITES

DEVELOPER PROGRAMS

Source

Website bugs

Documentation

Forums

CONTACT

Follow us