Best practices guide for Series 40 web apps

Overview

This topic provides advice on the best coding practices for creating Series 40 web apps that provide an excellent user experience. Some Series 40 phones lack the processing power and memory to run a standard browser directly on the device. Therefore, Series 40 devices have a distributed or proxy-based web browser model that enables full page rendering. A Nokia Browser for Series 40 Proxy server communicates with websites on behalf of the Nokia Browser for Series 40 client on the phone. The server performs the process-intensive tasks associated with rendering web pages, such as executing scripts and resizing images. The server sends the client optimized web content, reduced in payload and streamlined for efficient rendering. Figure 1 shows an overview of the Nokia Browser for Series 40 architecture.

Figure 1. Nokia Browser for Series 40 architecture overview

A unique feature of the Nokia Browser for Series 40 among proxy-based browsers is that some JavaScript code can be executed on the phone. This feature enables Series 40 web apps to offer an enhanced user experience through dynamic user interfaces with features such as transitions. This novel design creates some new use cases to consider when coding a Series 40 web app, such as the frequency of communication needed between the client and the server.

The HTML and JavaScript code in Series 40 web app is processed on the proxy server only. The server prepares all content for the handset, converting it to optimised HTML and delivering JavaScript code that uses the client’s MWL (Mobile Web Library) JavaScript library. MWL contains code to support application-like interaction on the phone. MWL processing should normally be the only JavaScript that executes on the phone. For more information on MWL, see Descriptions of MWL methods.

Unsupported web techniques

The following tables list web design techniques that either are not supported in Series 40 web apps or that could result in performance issues in the Nokia Browser for Series 40 environment. Recommendations for workarounds are provided.

Tables in the Series 40 Web Apps Developer’s Guide and API Reference list the Supported HTML tags and CSS properties.

Table 1. Page layout
Unsupported page layout technique Comments and workarounds
Some types of nested tables It is recommended that you experiment with nested tables to determine what works in your web app.
z-index,float, and position Workaround for float and general lateral positioning: Use tables.
Most overflow modes (all but visible andhidden) Workaround: use overflow:hidden.

Table 2. Graphics
Unsupported graphics technique Comments and workarounds
Changing image dimensions on the phone No workaround available
Opacity & RGBA graphics Workaround: Use transparent PNGs.
Canvas/SVG support No workaround available
Fine gradients and high colour depth Be aware that the proxy server automatically reduces colour depth to 256 colours (8–bit) or less depending on optimisation requirements. Users might set the depth even lower to reduce their bandwidth charges.

Table 3. General browser functions
Unsupported general browser function technique Comments and workarounds
Directly modifying client-side style properties with JavaScript Workaround: Change predefined classes to modify properties.
Using JavaScript native timers Timers do not perform well when run on the proxy server rather than on the phone. Workaround: Use the MWL timer() and stopTimer() methods. For more information, see timer() and stopTimer().

Table 4. User input
Unsupported user input technique Comments and workarounds
Direct gesture support using gestures other than swipe and longPress Workaround: Use the built-in swipe and longPress gestures. For more information on this, see Web apps for Series 40: Developer’s guide and API reference.

Table 5. Advanced features
Unsupported advanced feature technique Comments and workarounds
Timing-dependent games requiring real-time feedback processing Since most of the system processing occurs on the cloud server rather than the device, the client-server communication lag makes this type of game impractical. This environment supports only games that run entirely on the device with no cloud server support (other than the initial download).

Accommodating screen orientation

Series 40 web apps run on phones with 240 x 320–pixel screens that can be oriented in portrait or in landscape. To ensure that web content fits optimally in each orientation, use the following approaches to formatting:

  • Specify relative size controls such as percentages for width settings.

  • If content must be sized explicitly, create separate CSS definitions for portrait and landscape orientations. To do this:

    1. Add JavaScript code to your web app that queries the screen object and reads the width property.

    2. Test the screen width. A width greater than 240 indicates landscape orientation.

    3. For the detected screen orientation, create a conditional <link> to the web app's document that defines the layout in a CSS file, as shown in the example below.

    /**
 * Selecting a CSS file based on screen width
 */
if (screen.width > 240) {
   document.write('<link rel="stylesheet" href="../../basicLandscape.css" type="text/css" />');
}
else {
   document.write('<link rel="stylesheet" href="../../basicPortrait.css" type="text/css"/>');
}

  • Execute this JavaScript from the <head> of the main HTML of the web app, as shown below.

<head>
    <title> Screen size example </title>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <!-- Common CSS for both orientations -->
    <link rel="stylesheet" href="../../common.css" type="text/css" />
    <!-- The following script sets and gets the appropriate CSS files for the screen orientation -->
    <script type="text/javascript" src="screensize.js"></script>
</head>

Note that Series 40 phones do not support dynamic orientation changes.

Tips for peak performance

Several factors affect the performance of Web apps for Series 40 phones:

  • Speed of the phone's processor

  • Availability of runtime and permanent storage memory

  • Communication technology used between the server and client

  • Design of the web app, particularly the frequency of round trips between the client and the server

A round trip is a common communication method between the Nokia Browser for Series 40 client and the Nokia Browser for Series 40 Proxy server. In a round trip, the client browser sends a request to the server. The client then waits while the server processes, builds a response, and sends it back to the client. Nokia has taken steps to speed up this communication such as using optimised HTML, not re-sending unchanged content for page updates, and compressing graphics. Even with these optimisations, a round-trip sequence takes several seconds to complete. Some round-trip communication is unavoidable, but your site will work better if you keep it to a minimum.

Image handling

Web apps get images from either the internet or from within the web app package. The Nokia Browser for Series 40 Proxy server scales images from the internet to the size required for the particular phone and reduces the colour depth if needed. To reduce server-side processing and network traffic and to improve response time, adjust the size and colour depth yourself and make the image available for the exclusive use of your web app.

Images included in the web app are cached on the phone beginning with Series 40 web apps version 1.5. Therefore, all static images should be included in the web app instead of downloaded from the internet.

Suggestions for optimal performance

Good mobile page design principles such as the examples below will help you to improve the performance of your web app. Experiment with these techniques to determine which ones make the most sense for your particular web app.

  • Use simple page design with few graphics – a page containing mostly text will load faster and leave more memory available for other uses. Try using a text link in place of a linked graphic (such as a button image) or image map.

  • Reduce memory usage – memory is one of the critical resources on Series 40 devices. One way to reduce memory usage If you have an application with several tabs is to download the content for only the active tab rather than for all of the tabs. When the user selects another tab, the app fetches the content for the second tab. However, each download requires a round trip between the client and the server. Test your app to find the optimal balance between memory use and speed.

  • Minimize round-trip communication – one way to do this is to rely on server-executed JavaScript as little as possible. If you can code a page using MWL JavaScript calls running locally on the device rather than JavaScript running on the server, there will be fewer round trips and the page should run faster.

  • Avoid unnecessary graphics – one example of this is using a single-pixel tiled background image instead of setting the background color with CSS properties. Another example is drawing boxes with square corners. Because the client browser has no built-in support for drop shadows or rounded corners, you would have to construct these elements with downloaded graphics. Using simpler square corners saves memory and reduces page load time.

Figure 2. Avoid unneeded graphics

  • Reduce processing – Suppose you want to display a button 50 pixels wide with a gradient from top to bottom. You could download a vertical slice of the image, then replicate the slice several times to construct the button. To save memory and improve download time, consider downloading a slice that is 1 pixel wide, but then the processor must do a lot of work to replicate the slice into the final graphic. Another approach is to send down a 10-pixel slice, which the processor could use to build the button significantly faster (with one-tenth the number of processing iterations). Experiment to find what works best in your application.

Figure 3. Reducing processing time for building a graphic

Recommended techniques for common page structures

For ideas on the best way to implement accordions, carousels, tabbed pages, lists, and other page structures, see the Series 40 web app code examples on the Nokia Developer website: https://projects.developer.nokia.com/S40WebApps/files . From there, click on the Sample Code link. (You may need to log in to Nokia Developer first.)

Page layout suggestions

There are no definitive rules for the best way to lay out web pages. What works well for one web app might not work for another. Some suggested approaches are as follows:
  • Use tables to set up the spacing in a web app. Specify the horizontal location of page elements by using column widths, and specify their vertical locations by using row height. Note that nested tables (tables within tables) do not always work correctly in Series 40 web apps. It is important to test your application on all target phones to ensure that the layout displays as you expect.
    Note: Tables can sometimes slow performance. If you notice slow responses for operations such as animated transitions, which run on the phone without help from the proxy server, try removing one or more page layout tables.

  • Use CSS margins to set horizontal layout. Several common HTML tags have margin properties that you could use to set spacing. For a complete list of tags that support margins, see HTML tags supported.

Example of the CSS margin technique

This example shows the body of an HTML file that displays two coloured squares. The squares are defined in the <style> settings table below the code block.

<body>
		<div>
			 <div id="btn1">
			 </div>
			 <div id="btn2">
			 </div>
</body>

The default alignment of these squares is vertical, as shown below. Note that the <style> settings do not include margin settings.

To align the boxes horizontally, add margin settings to the box definitions, as shown below:

In the <style> setting for #btn2, the margin-left setting adds 40 pixels to the left margin, which moves it to the right of the first square. The margin-top setting of —40 px moves the top margin up by 40 pixels, since up is the negative direction. This places the second square in horizontal alignment with the first, as shown below.

JavaScript function call processing issues

When the Nokia Browser for Series 40 Client processes code that calls both JavaScript Mobile Web Library (MWL) and non-MWL functions, it performs the MWL calls first, regardless of the order of the function calls. The reason for this is that MWL is a local library that runs on the phone.

The client browser processes all MWL function calls first. It then asks the Nokia Browser for Series 40 Proxy server to handle the non-MWL function calls. The following example shows how runtime errors can occur because the client browser calls objects that have not yet been defined due to the order in which function calls are processed.

<script>
function attachHorizView()
{
// Function processing includes defining #btns (not shown).
}
</script>

<!-- #btns does not exist until attachHorizView runs on the server.  -->

<div onclick="attachHorizView();
   mwl.setGroupTarget('#btns', '#btn0', 'show', 'hide');
   mwl.switchClass('#views', 'view1', 'view2');">

In the example above, the attachHorizView function defines an object called #btns . The code references this object later, in the setGroupTarget call. However, the browser calls attachHorizView after setGroupTarget. Therefore, when the client browser calls setGroupTarget, #btns is not yet defined. This causes a runtime error.

To resolve this issue, move the setGroupTarget call into the attachHorizView function itself, as shown below.

<script>
function attachHorizView()
{
// Function processing includes defining #btns (not shown).

// setGroupTarget is called at the end of the attachHorizView function.

     mwl.setGroupTarget('#btns', '#btn0', 'show', 'hide');
}
</script>

<!-- Now the setGroupTarget call occurs after all other processing in attachHorizView.  -->

<div onclick="attachHorizView();
      mwl.switchClass('#views', 'view1', 'view2');">

Now, the variable #btns is defined before the client processes the setGroupTarget call and everything works as expected.

Font support

Series 40 Web apps support only one font, and that font changed between Series 40 6th Edition and Feature Pack 1 of that Edition. For more information, see the Series 40 web apps UX guidelines. The server component maps all of the fonts used in a web app to this Nokia font, and it does not support downloading other font definitions. The system supports simple text effects like bold text and italics using CSS styles or standard HTML tags such as <b> and <i>.

Third-party JavaScript libraries

Your web app can use third-party JavaScript libraries for interactive UI elements, but non-MWL JavaScript code executes on the server instead of on the phone. Therefore, each library call requires round-trip communication between the Nokia Browser for Series 40 client and server. Because of the time delays involved with round-trip messaging, Nokia recommends that you use MWL rather than third-party JavaScript libraries if possible.

Last updated 3 February 2012
Featured links
Develop
Distribution
Blogs
Community
Resources
Site Map
Terms & Conditions
Privacy Policy
Nokia Developer aims to help you create apps and publish them so you can connect with users around the world.

京ICP备05048969号  © Copyright Nokia 2012 All rights reserved