Series 40 Developer Training

Series 40 Web Apps 2.0

Michael Samarin, Ph.D Director, Developer Training Futurice

@MichaelSamarin

What Are Series 40 Web Apps » W3C Widget specification (http://www.w3.org/TR/widgets/) says:

› “Widgets are client-side applications that are authored using Web standards, but whose content can also be embedded into Web documents. “

» Series 40 Web Apps are based on the W3C Widget specification

› Authored using a set of development tools provided by Nokia

› Targeted to be run on Series 40 mobile devices

› Using browser engine Nokia Browser for Series 40 (alternative name Nokia Proxy Browser, former Ovi Proxy Browser), which is pre-installed on all latest Series 40 devices and available as download for older devices. In total, there are 35 devices that support Nokia Browser (Series 40 5th Edition, Feature Pack 1 and up).

› Latest version required for Web Apps with API level 2.0 is Nokia Browser 2.0 (as of July 2012)

» http://www.developer.nokia.com/Devices/Device_specifications/?filter1=series40webapps

» Core use cases: Connected data-driven applications

› Social networking, RSS readers, trivia games, …

» Although developed using web standards, web apps are not the same as traditional web pages

› Appear and behave like standalone applications

› Located in application grid like regular applications

› A ”custom fit” for a small-screen mobile device

› Package can contain local content like graphics, data samples, scripts

Web Apps Are Not Web Pages

Tools for Series 40 Web Apps » Nokia Web Tools 2.0

» Eclipse Based (Aptana Studio) web development environment

» Customized by Nokia for Series 40 Web apps

» Includes templates, libraries, code snippets, simulator, debugger, deployment options unique to Series 40 Web Apps development

» Bluetooth Launcher 1.5 for on-device deployment

Nokia Browser for Series 40 » Unique proxy browser with server side JavaScript / Compression

engine for Series 40

» Engine that made Series 40 Web Apps possible, because most Series 40 devices do not have enough CPU/RAM to run a full WebKit based web browser

» Nokia Browser Proxy hosts the Web App client, and acts as a proxy between the Nokia Browser Client and the Web App server, so can be described as ”Cloud-Assisted Web Runtime”

» Takes web app development for lower-end devices to a whole new level!

Nokia Browser for Series 40 » Nokia Browser main features:

› JavaScript runs on Nokia Browser Proxy server side

› Application content compressed before sending to the client

› CSS minimized, images compressed, partial HTML updates whenever possible

» Current Nokia Browser main constraints:

› HTML 4.01 with CSS 2.0 mobile profile (selected parts of CSS 3 also available)

› Certain DOM events not supported (onkey*, onmouse*, ontouch*)

› Limitations on animations (a limited set of transition timing functions available)

› No device API access, except: geo-location, uploading / downloading files, initiating sending SMS, phone call.

› No home screen widgets

JavaScript and Mobile Web Library

» Regular JavaScript statements are executed by the Nokia Browser Proxy server

» JavaScript function calls in your code cause a round-trip to Nokia Browser Proxy

» Special library called Mobile Web Library (MWL) provides client-local JS functions

» Functions executed fully on the client side (Nokia Browser Client)

» Used via a namespace called mwl

Mobile Web Library - MWL » MWL is limited, however covers the most common use cases

that can be run on the client side:

› Running simple CSS transitions/animations

› Handling gestures (swipe, long press)

› Inserting new nodes to DOM

» Implemented natively by the Nokia Browser Client

Mobile Web Library - MWL

» In addition to these, MWL also provides functions for registering listeners for synthetic events (gestures) and navigation keys

› addSwipeLeftListener(), addLongPressListener(), …

› addNavLeftListener(), addNavUpListener(), …

CSS Manipulation Timers Misc

addClass removeClass toggleClass switchClass iterateClass setGroupTarget setGroupNext show hide toggle

timer stopTimer

setInputValue insertHTML replaceChild scrollTo loadURL

Common JavaScript Use Cases » Non-MWL JavaScript can be used almost as usual

› Just keep in mind that it causes a round-trip to the Nokia Browser Proxy

› Be especially careful when using 3rd party JS libraries (e.g. jQuery or jQuery Mobile)

» Handling XHR/AJAX

› No performance hit caused by the Nokia Browser architecture itself

› No limitations with same origin security policies

› Mashing up content from different sources possible!

» Lazy loading vs. front loading

› Round-trips can sometimes be avoided by front loading data at startup

» Preparing DOM for mobile client use

› E.g. building lists/tables to be inserted into the app

New Features in API 2.0 » Support for Full Touch Series 40 devices with 240x400

resolution

» 4-Way Navigation on non-touch devices

» Inline-block layout in CSS/HTML

» Files upload (input type “file”) and download

» encType of the form HTML tag

» vertical-align property of the div tag

Example 1 - ButtonSample » Learning Nokia Web Tools

» Explaining application structure in Eclipse

» Deployment settings and target deployment: Local Preview, Cloud Preview, Device

» The <button> calls mwl.toggle(), which will hide visible elements and show invisible ones

» toggle() accepts a simple CSS-selector as its argument (as do many MWL methods)

» Note that everything happens in the Client – the Proxy Server only serves the initial HTML, and after that it need not be contacted at all!

» http://www.youtube.com/watch?v=emAXcTFl4vo

» https://projects.developer.nokia.com/videotraining/downloads/1

Example 2 - ButtonCounterSample » Highlights how application state (i.e. the value of the counter) can be retained on the Nokia Proxy Server

» How it works:

› Application loads, the counter is 0 on the Server

› Client detects a press of the button, notifies Server

› Server increments counter by one, updates Server HTML

› Server notifies the Client to make an identical update to its own HTML both parts of the application are in sync

» Note: the Client never knows the actual value of the counter, only receives updates to its HTML!

› Thus, intensive computation/large amounts of data can be processed by the Server, while the Client only gets small updates and saves battery and bandwidth

» http://www.youtube.com/watch?v=HY-K6xThvCQ

» https://projects.developer.nokia.com/videotraining/downloads/3

Example 3 - PageChangeSample » Anything in <body onload=””> will be executed just before the

application starts

» We use that to hide the 2nd page initially

» Notice how we can use more than one MWL-call in an event attribute, such as the onclick=”” of a <button>

» Each press of a <button> will hide the current page and show the page that was hidden

» Note that no Server communication needs to take place – the application runs entirely on the Client

» http://www.youtube.com/watch?v=ooAuLj-YDrA

» https://projects.developer.nokia.com/videotraining/downloads/4

Animations and Transitions » Certain properties can be animated locally on the client side:

› Element’s width, height, margin-left and margin-top

› Or a combination of these

» Consequently, there are a few design patterns that are especially recommended

› Accordion

› Carousel

› Tabs

» These have certain common advantages/properties

› Based on the principle of concealing/revealing content

› Client-local, animated transitions can be easily added

» When used correctly, unnecessary round trips to the Nokia Browser Proxy server are almost automatically avoided!

Animating Height & Width

Animating Margins

…or…

…or…

Important Notes on Animations » Local Preview, Cloud Preview and an actual device will all work

slightly differently, so don’t rely overly on the simulator.

» GIF animations don’t work in the simulator but DO on the device. Be careful with GIF, because of high CPU usage

» Contrary to regular browser scripting, animations on the Client are blocking

» Only a single element can be animated at one time for performance reasons

Example 4 - AnimatedPageChangeSample 1/2 » A bit more involved than the previous one!

› Adds altering the default positioning of elements

› Adds animation

» Absolute positioning is not allowed

› So we emulate it with negative margin tricks

› We set the two pages side-by-side

› When either page is navigated to, we move the container they both share to give the illusion of moving both pages at once

» http://www.youtube.com/watch?v=0EHjhgXJLB8

» https://projects.developer.nokia.com/videotraining/downloads/5

Example 4 - AnimatedPageChangeSample 2/2

Page #1

Page #2

Default positioning for the 2 pages (the dashed line is the viewport of the phone)

Page #1 Page #2

We move Page #2 up by how high Page #1 is, and to the right by how wide Page #1 is, so we get them side-by-side

Page #1 Page #2

Then we wrap both pages in a container element (red), which we can move sideways with an animation

How it works

Example 5 – Ajax 1/2 » Ajax makes it possible for web pages to communicate with

(other) servers

› http://en.wikipedia.org/wiki/Ajax_(programming)

» We’ll use jQuery to make Ajax simple

› http://api.jquery.com/jQuery.ajax/

› Note that while jQuery is a (relatively) large JavaScript library, the Client will never need to download it, since it’s the Server that uses it, and only sends updated HTML to the Client

Example 5 – Ajax 2/2 » Let’s contact a free web service that will geolocate its clients based on their

IP address

› Fun fact: you will get different results when running Local Preview and Cloud Preview!

› Bonus exercise: why does that happen?

» The async:false and crossDomain:false options are key to making this work

› Without async, the call from the Client to the Proxy Server would finish before the web service responds

› Without crossDomain, jQuery would get confused in the Proxy Server environment

» http://www.youtube.com/watch?v=gg9Cq9l3BeA

» https://projects.developer.nokia.com/videotraining/downloads/6

Complex Apps - UI Considerations » Accordion

› Allows for compact representation of list items

› Additional content or secondary actions can be revealed with a press

› Good for lists of similar items

» Carousel

› Allows for playful, quick browsing of media content

› Allows for full-view focus of content

› Good for unspecified amounts of rich media

» Tabs

› Allow for quick access to independent content stacks

› Allows for categorization and persistence of content states

› Good for functions that behave independently of one another (e.g. settings, favorites, profile)

Complex Apps - Design Approach » Document-driven

› Try to keep your scrollable content to a certain axis (e.g. vertical) by keeping a fixed-size on the other axis

» Component-driven

› Try to eliminate document overflow – for example, set the body to 100% width and height and set overflow:hidden

› Use relative (percentage) lengths to make flexible layouts in either orientation

» It may be possible to take a “hybrid” approach

› By creating some views that are fixed (component-driven) and others that are scrollable (document-driven).

› For example, a main screen of icon components with sub views as reading panes

» This strategy allows the use of fluid scrolling as well as flexible, accessible UI

› As long as only one view is shown at a time

Complex Apps - Performance and Debugging » Handling large amounts of data

› E.g. memory management with image carousels

» Animation performance

› Minimizing reflows – do not animate very many objects at the same time

» Handling differences between ”regular” web apps and apps designed for Series 40 devices (Nokia Browser)

› Debugging with Web Inspector

› Taking CSS compression/cascading issues into consideration

› How image compression affects your application

› Unsupported features of web standards

Persistent Data » Most mechanisms you would normally use for client-side persistent data are actually

handled on the server here

› Including cookies!

» One mechnism exists for storing simple data on the client

› widget.preferences

› Contains simple key-value pairs

› http://www.w3.org/TR/widgets-apis/#the-preferences-attribute

<script> // Store a value... widget.preferences.setItem("mypref","myvalue"); // ...and read it back var value = widget.preferences.getItem("mypref"); </script>

Browser Integration FAQ » Is it possible to integrate the app with the Nokia Browser back

button?

› No, this is not supported at the moment

» Can I create custom items for the Nokia Browser options menu?

› Not at the moment

› If such funtionality is needed, create a custom implementation with HTML/CSS

» Can I close my app from JavaScript?

› No, there is no such MWL method or window.close() available in the current release

Common Examples » Changing the application icon shown in the Nokia Browser favorites

› Use the standard favicon syntax:

<link rel="icon" type="image/png" href="favicon.png">

› The icon should be 16x16 pixels in PNG format with a transparent background

» To launch a phone call, use the standard tel: URI scheme

<a href="tel:+3581234567">Dial</a>

» Loading audio or video

› Simply use MWL to play back a file type supported by the device (e.g. 3gp, mp4):

<a href="#” onclick="mwl.loadURL('http://domain/video.mp4');"> Play video </a>

CSS Compression Issues › #id.class is not allowed by the compressor

› Use ID’s for addressing, classes for styling

› !important-declarations aren’t allowed

› ...but they’re a bit of a hack anyway

› Declarations that don’t match anything in document are dropped

› So have an instance of a class you’re about to ”cast” for an animation for example

› .first .second {} becomes .x123 {}

› This is anonymization of the classes, and changes the semantics of the stylesheet

› This will become natural with experience

› Summa summarum: it’s complicated

› ...so don’t use complicated selectors!

JavaScript Tips › The JavaScript execution

environment of the Proxy is sometimes a black box

› Use libraries you know to work; for example in templating, jQ-tpl not, Mustache yes

› Also be aware of your DOM interactions with jQuery for example!

› DOM-updates always delivered as JavaScript to the handset

› Observe with WebKit Inspector

› Updates are always anchored to an ID

› Consider an example:

› <div id="foo"><div class="bar">...</div></div>

› serverside: $('#foo .bar').text('TEXT');

› even though only '...' needs updating, entire '<div class="bar">TEXT</div>' is transferred

› add arbitrary id: <div id="foo"><div id="whatever" class="bar">...</div></div>

› same serverside JS, but only 'TEXT' transferred

› Use only simple callbacks in event handler attributes

› E.g. onclick=“foobar()”

Thank you!

@MichaelSamarin

http://www.futurice.com