Developing Series 40 web apps with Nokia Web Tools 2.0

Series 40 DeveloperTraining

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=series40we
bapps

» Core use cases: Connected data-driven applications
› Social networking, RSS readers, trivia games, …

Web Apps Are Not Web Pages
» 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

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
CSS Manipulation Timers Misc
addClass timer setInputValue
removeClass stopTimer insertHTML
toggleClass replaceChild
switchClass scrollTo
iterateClass loadURL
setGroupTarget
setGroupNext
show
hide
toggle

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

› addNavLeftListener(), addNavUpListener(), …

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


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

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 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

Example 4 - AnimatedPageChangeSample 2/2
How it works

Page #1 Page #1 Page #2
Page #1 Page #2

Page #2

Default positioning We move Page #2 Then we wrap both
for the 2 pages (the up by how high Page pages in a container
dashed line is the #1 is, and to the element (red), which
viewport of the right by how wide we can move
phone) Page #1 is, so we get sideways with an
them side-by-side animation

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

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)

Developing Series 40 web apps with Nokia Web Tools 2.0

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 › serverside: $('#foo .bar').text('TEXT');
environment of the Proxy is
sometimes a black box › even though only '...' needs updating,
entire '<div class="bar">TEXT</div>' is
transferred
› Use libraries you know to work; for
example in templating, jQ-tpl not,
Mustache yes › add arbitrary id: <div id="foo"><div
id="whatever" class="bar">...</div></div>

› Also be aware of your DOM › same serverside JS, but only 'TEXT'
interactions with jQuery for example! transferred

› DOM-updates always delivered as › Use only simple callbacks in event
JavaScript to the handset handler attributes
› Observe with WebKit Inspector › E.g. onclick=“foobar()”

› Updates are always anchored to an ID

› Consider an example:
› <div id="foo"><div class="bar">...</div></div>

Thank you!

@MichaelSamarin
http://www.futurice.com

Developing Series 40 web apps with Nokia Web Tools 2.0

Related slideshows

More Related Content

Developing Series 40 web apps with Nokia Web Tools 2.0