Yesterday, the Guarana UI framework has been launched, with a complete set of ready-to-use components that will definitely be useful to all Web Runtime developers.

It's now available a Guarana UI online Components Browser, that allows developers to quickly preview and use all the Guarana UI Components.

Soon it will feature tutorials and guidelines on Components usage, testing and customization.

If you have a WRT widget, a new Component or a proof-of-concept built by using Guarana UI, and want to feature it on this page, just drop me an email or a comment on this post.

Hope you enjoy it! :)

Just came back from a relaxing weekend, with a totally unrelaxing news: as reported, among others, by Leonardo, Alessandro and Mariam, Adobe just dropped the Flash Lite Distributable Player, to entirely focus on Flash 10.1 (for the mobile browser), Air Mobile (for standalone) and Flash Lite 4 (for low-end devices).

This is a huge, even if someway predictable, news for all mobile developers and companies that have been and are currently focusing their efforts around the Flash Lite Distributable player to provide their content to users.

Given the central role of Nokia in supporting and contributing to Flash Lite, and the maybe-related news of Forum Nokia and Kuneri online packagers shutting down, I imagine some more news coming in the following days or weeks, that would help to clarify how and when Nokia devices, distributions channels and development tools will evolve.

Right now, we can just guess it'll take some time to have a new, clear strategy built around Flash on mobile, and I'd be glad to hear your opinions about this.

Meanwhile, let's join Dale in his minute of silence for the brave Dandelion! :)

If you are an Italian mobile developer, or happen to be in Italy during November or December, then the following Mobile Monday events could interest you:

November 23rd in Rome: The User Applications

Talks about mobile user applications together with Giovanni Gasbarrone from Telecom Italia and Kari Tuovinen from Nokia.

December 14th in Milan: Application Developer Event

Are you in the application development business and want to get connected with other developers? Want to share the questions and ideas you have? Do you want to hear more about the support for developers? Come and join us in the Developer Event!

For further details you can visit the Mobile Monday Italy website. Photos from the last event in Milan, on October 19th, are also available on Flickr: Mobile Application Stores event photos.

If you plan to be at one of these events let me know, I'd be glad to meet other Nokia developers :)

In the past weeks I've done some experience with Opera mobile widgets, and would like to share first some tips and guidelines about porting a widget, originally developed for the Vodafone/Opera widget runtime, to the S60 Web Runtime platform. Both platforms use Web standards such as HTML, CSS and JavaScript, and the greatest differences are brought by the runtimes themselves, as will be explained by the following points.

Differences

Widgets' structure is similar for both runtimes. A widget must be composed of a single HTML file, and could allow multiple JS, CSS and image files. In both cases the widget is packed by using a standard ZIP compression, but using different file extensions: WGZ for Web Runtime, and WGT for Opera widgets.

The only important structure difference is represented by the configuration file: config.xml for Opera widgets, Info.plist for Web runtime. Specifications for both files can be found here:

• Info.plist specifications
• config.xml specifications

Similarities

Luckily enough, some useful objects and methods work on both environments, allowing for faster and safer widget porting. Some examples are:

• widget setPreferenceForKey() and preferenceForKey() methods
• widget openURL() method

Not all methods of the widgets objects are supported by both runtimes. For full details:

• Web Runtime widget object
• Opera widget object API

1. Managing the user interaction

Both widget runtimes allow to choose between cursor navigation (so, with the classical mouse cursor) or tabbed navigation. What changes is the way to declare which mode the widget should use. On the Opera runtime, the tabbed navigation mode must be declared in the configuration file, by using the <nocursor /> tag, while on Web Runtime this can be easily handled from JavaScript, by using the setNavigationEnabled() or setNavigationType() methods.

2. Tabbed navigation differences

Tabbed navigation works similarly in both cases, allowing users to move focus by using the 4-way navigation pad. Anyway, there's an important difference in the way the Opera runtime moves focus: apart from standard links (<a> tags) and elements with onclick handlers, the Opera runtime also focuses standard images (<img> tags) even if they have no onclick handlers defined. This could bring to weird behaviors if not appropriately taken into account, and could confuse users in their interaction

3. Screen size

Opera widgets are currently constrained to a subportion of the available display resolution, by leaving the upper part of the screen for the widget information (e.g.: title) and the lower part for standard softkeys. The Web Runtime allows for full-screen widgets, so layouts should be appropriately resized to benefit from this extra space.

4. CSS opacity

Web Runtime does not currently support alpha transparency for HTML elements, while the Opera widget does. When porting, the opacity should be so appropriately managed, by choosing a suitable alternative effect, or by removing it. A possible way to implement opacity in Web Runtime is represented by the use of PNG24 images with alpha transparency, well supported by the Web Runtime platform.

5. GIF support

A known issue with first Web Runtime versions was the lack of support for animated GIF images, so you should take this into account if your widget uses them. In this case, some JavaScript-based workarounds are available on Forum Nokia Wiki:

• How to create animated images in Web Runtime widgets

6. Move the icon

The Opera runtime allows to use any paths for the widget's icon, just specifying it in the configuration file. When porting to Web runtime, the icon has instead to be moved to the predefined path, that is: '<widget_root>/icon.png', without the need to specify this in any configuration file.

7. Display rotations

Opera runtime does not allow to block the display orientation to landscape or portrait. Web Runtime allows to do this, by using the JavaScript methods:

• widget.setDisplayLandscape() to force landscape orietation
• widget.setDisplayPortrait() to force portrait mode

So, you could use this functionality to let your widget display in only one orientation, if your widget needs that.

8. Home screen

One of the cool features of WRT widgets is, on latest S60 5th edition devices, the possibility to have your widget on the home screen of the device, so always visible to the user.

On the other side, Opera widgets allow for a "docked" version of the widget, so allowing to display any dynamic information instead of its static icon.

Home screen and docked widget concepts are really similar, since they actually allow to display smaller versions of the widget. When porting, the resolution should be taken into account: size available for docked widgets is usually smaller than the one available for home screen widgets. So, more space and more content :)

9. Customizable softkeys

One big plus of Web Runtime widgets, when compared to Opera ones, is the possibility to customize the softkeys, allowing to add custom items and functionalities to both the left and right softkey menus. 

For full details, check out the JavaScript menu object reference.

10. Network access

Opera mobile widgets need to declare the remote hosts they want to connect to, as specified by the Opera Widgets security model. When porting to Web Runtime, this step is no more necessary: Web Runtime widgets can connect to any host, without the need to declare them in a configuration file.

Today I'd like to give a first preview a new little tool that allows users, developers and websites' owners to create a mobile launcher WRT widget for their websites in few, easy steps: the Website Launcher generator!

The website offers a simple interface where, filling out some required fields (e.g.: widget's name, website URL) and optional fields (e.g: widget's icon) it's possible to create and immediately download the Web Runtime widget for the desired website.

A widgets' gallery is also available, to download widgets created and shared by other users.

The service is still in its early development phase, and I'll be glad to have any kinds of feedback :)

Usually, when a mobile application needs an update, it is necessary to release a new version, and to deploy this new version on all the devices where the old version was installed. This includes scenarios as bug fixing, releases of new features, and also the smallest code changes.

While many mobile users know how to perform an update of an application, Web Runtime widgets offer an attractive alternative approach that could both help the less experienced users, and bring some important benefits to Web Runtime itself.

Summarizing this approach in few words, a Web Runtime widget can download new code with simple HTTP requests, and use it to replace existing code (think about bug fixing, or code changes more in general) or to add new features to itself, without requiring any extra efforts from the user.

So, the update process become much smoother than with the classical application updates. What this means is that updates become transparent to the user, since all he needs to do is to allow its widget to connect to network, to retrieve the new code.

How it works is detailed is this Forum Nokia Wiki article:

How to update WRT widgets without installing a new version

To summarize the limits and benefits of this approach:

Limits

Current Web Runtime JavaScript APIs allow widgets to locally save textual data, with the preferenceForKey() and setPreferenceForKey() functions.

So, the new JavaScript code can be easily saved and used for all the subsequent usage sessions of the widget, without the need to download it each time. But all the binary data, for example images, simply cannot.

So, when some binary data needs to be added or updated, this approach doesn't work, and the only way is to deploy a whole new version of the widget, so updating in the classical way.

Advantages

One major problem with Web Runtime widgets is that, when a new version is installed over an older one, all the data saved from the previous version gets lost. So, the new version of the widget cannot use the data saved by its previous version.

With the approach presented here this does not happen, since the widget isn't "actually" updated.

Repeating what already told, the greatest advantage of this approach is surely the better and smoother user-experience, since updates (with the limits already mentioned) become simple as doing network requests.

Security considerations

One could think about this as a major security hole for Web Runtime widgets. While it is true that a malicious developer could inject evil code in his own widgets, this is equally true with the other mobile technologies, even if with different approaches than the one described here.

Also, and most important, the Web Runtime sandbox and security measures guarantee that all the operations dealing with sensitive data or with potentially costing functionalities (e.g.: network requests, sms sending) are prompted to the user for its explicit permission.

Developing Widgets for Web Runtime is absolutely easy and fun, specially if you come from Web development.

While there are a lot of libraries and components that can be easily adapted and used within WRT Widgets, there are still not many components specifically tought and designed for WRT itself.

So, here are my first Web Runtime components: the WRT JavaScript Battery and Network Signal components, supporting both WRT 1.0 and 1.1.

You can view and download the full implementation of both components from Forum Nokia Wiki:

• Battery JavaScript component for WRT 1.0 and 1.1
• Web Runtime Network Signal JavaScript component

Feedbacks are welcome! :)

Some days ago I've put together 5 first guidelines that I usually find useful when thinking about any new WRT Widget. These can be summarized as follows:

1. Widgets and Websites: same technologies, but with some differences
2. Implement an update mechanism
3. Create viral effect
4. Design an application, not a website
5. Carefully consider network connectivity

Today I would like to continue this series, with new points that will hopefully help Web Runtime Widgets developers.

6. Think about scrolling

Ok, this could perfectly be a subpoint of section 4 ("Design an application, not a website"), but I really think this point is important when thinking about a WRT widget. While scrolling is something usual on any (mobile or not) website, when you think about a widget, compared to a website, you want a slicker and faster experience.

So, while standard browser scrolling is a fast option to allow users to view large portions of data, there are surely better or refined alternatives, that will allow a better user experience. Usual scenarios, where implementing custom scrolling is a good option, could be:

• a classic widget with a header and a footer, where you want to scroll content but want to always keep fixed and visible these top and bottom bars (as well as other elements)
• a widget where you want to use and manage custom scrollbars
• a scrolling mechanism where you want to allow users to do fast scrolling (e.g.: pressing left/right keys, or double pressing up/down keys)
• a smooth scrolling (or similar) effect

While for some scenarios CSS properties will do the job (e.g.: set "overflow-y: auto" to tell a single html container to vertically scroll its content, if higher than its own height), for others you must dig into JavaScript, and write your own customized code. Check out how STEW for an example of simple, CSS based scrolling with fixed header.

7. Prepare different layouts for different resolutions

When designing a WRT widget, you basically have 2 choices:

• design a layout that adapts to different screen resolutions (e.g.: using css properties like 'width: 100%')
• design a single layout for each resolution/orientation that you want to support

While the first option could seem someway simpler, the second one turns out to be the more attractive, both for users and developers. The STEW example Widgets shows 2 different layouts for the different display orientations.

While this make sense for a simple display rotation, it does even more when you want to support both S60 3rd and 5th edition device with a single widget. Not only for the totally different display resolutions, but also for the different input methods, that allow users on 5th edition to interact by touches, so needing particular attention to specific guidelines, as you can read on Forum Nokia Library:

• http://library.forum.nokia.com/index.jsp?topic=/Design_and_User_Experience_Library/GUID-3143A96B-9285-4D4E-8BF1-1AA1E472C9AE.html

8. Use Platform Services

Platform Service really are the key for success of Web Runtime. Without them, you could not build anything more than plain, installable websites. You must not use them "because it's cool", but because their purpose its clear: access user- or device-related data, that can bring added value to your user, and so to your application. Simple examples go from access to plain network signal/battery level, to access to Location for LBS applications.

But, how to mantain compatibility between WRT 1.0 and 1.1? This Forum Nokia Wiki article shows how to check if Platform Services are supported in a particular runtime, so that you can accordingly manage your widget functionalities depending on it, without building two different versions of your Widget:

•  http://wiki.forum.nokia.com/index.php/Checking_for_S60_Platform_Services_support_in_a_WRT_widget
  

9. Use animations and transitions

Remember the "good old" mobile Web? Ok, now forget it ;)

As you probably already know, S60 browser offers a powerful JavaScript environment to perform quite cool effects within your Widget. So, don't rely on the concept of a static, overly simple mobile Web, and consider all the benefits that good-designed transitions can bring to your application. Do you want some hints, right? :)

• http://wiki.forum.nokia.com/index.php/Mobile_Design_Patterns:_Screen_Transitions
• http://www.youtube.com/watch?v=v1eqNkhh0eI 

10. It's full JavaScript, but it's not full power!

Ok, point 9 says you should not be shy to implement cool effects within your Widget. This is true, but full JavaScript engine does not mean you can do the same things you do on desktop browsers. And so, never think you can use full-blown JavaScript libraries, without worrying that much about their content and functionalities. So, what to consider before adopting a particular library?

• Its size: even if it's locally deployed (so network traffic and delay is not a problem), you could encounter slow responsiveness of your Widget if you use BIG libraries (think about Dojo)
• Its purpose: do you really need a library? Many libraries offers HTML components, but most of times they're not suitable for a mobile application, due to different factors (e.g.: screen size, different interaction modes). Also, most of times JavaScript libraries include big portions of code to solve desktop browsers' incompatibilities, but this code is (fortunately) useless in WRT environment.
• Its support: there are a lot of libraries that use objects still not available in S60 browser environment. An example is the 'canvas' object: WRT Widgets do not have it, so check if your library uses it.

Since there's a lot of excitement around mobile Web, and particularly about WRT Widgets, I started thinking about which possible guidelines could help both Web and mobile developers to face this new opportunity. Of course, for developers already familiar with WRT and/or mobile environment, most of these points could sound quite obvious: I would be glad to have any kind of feedbacks about them, and to know which other points you consider important in WRT Widgets development.

So, let's start.

1. Widgets are not Websites

Building Widgets with Web technologies does not mean that you can reuse all common patterns found on the Web itself. Some examples are:

• Multiple pages: Widgets are what commonly known as "single page applications". This means that, if you want to show another "page" to your users, you cannot simply let it "navigate" to another page: you have to do it by manually manipulating the DOM of the only page you have.
• Browsers' back and forward button: you have not such a navigation paradigm within widgets since, as told, widgets do not have the standard "page" concept. So, you cannot assume that your users will be automatically able to "go back" within your widgets screens: you must take care of implementing all the navigational logic by your own. Also, no standard "reload" functionality is available: if you want to reload your Widget's content, you have to programmatically do it.
• Content is (mainly) local: one big plus of Widgets versus mobile Websites is that you can deploy all the resources you want (textual and image ones) on the device itself, packaging them within the .wgz file itself, and avoiding the need for the user to connect to network to retrieve those resources. Of course, this makes sense only for static data, but it's anyway a point you should never forget when designing a new WRT widget.

2. Let it update!

WRT Widgets are by all means mobile applications. This means that, when you want to add or modify some of its functionalities, most of times you have to release a new version of the application itself. So, it is recommended that you implement an update mechanism within your Widget itself, so that the user can check (or the widget itself, e.g. automatically at startup) if there's a new version of your widget.

Fortunately, you can find a ready-to-use code snippet that does exactly this on Forum Nokia Wiki:

• http://wiki.forum.nokia.com/index.php/How-to_create_self-updating_WRT_widgets 

3. Create viral effect

When you're on a website, you can often suggest a webpage to a friend by sending him an email. So, why should you not do it on a mobile device? So, you could let your users send your Widget download link by email, just putting a link as the following:

<a href="mailto:test@test.com&subject=My Widget&body=Dowload this great Widget! http://www.yourwidgetlink.com">Email</a>

but, being on a mobile phone, why not allow them to send a simple SMS message? You can do it with a link like this:

<a href="sms:1234567890&body=download this great Widget! http://www.yourwidgetlink.com">SMS</a>

Both these links open up the email/SMS editor, respectively, with some precompiled data. So that your user has only to push the "Send" button.

But, wouldn't be great to integrate this functionality within your own Widget, without letting the user leave your app? If you think so (and you should :)), check out this Forum Nokia Wiki article, that explains how to send SMS messages using Platform Services:

• http://wiki.forum.nokia.com/index.php/CS001242_-_Sending_SMS_messages_in_WRT

4. Design an application, not a website

Ok, I'm insisting a bit on this point :)

Even if technologies are the same, you should be aware of the differences between approaches of an user toward a mobile website and a WRT Widget. For an end user, it has never been that important which technology you use to develop an application. Basically, if he sees an icon, he thinks about an application, and behaves accordingly. So, apart from the already mentioned ones (local content, different navigation paradigms) another important point to mention is that (hopefully) most of times your WRT widget will use a tabbed nagivation mode, or a totally custom approach implemented via JavaScript. So, differently from a Website, you'll have your users moving around jumping from a focusable item to the next, instead of moving a cursor around. Consider this, its limits, but above all the potential to build the best possible navigation for your end users.

5. Go remote only if needed (and if covered..)

This will seem quite obvious for any mobile application developers but, seeing it from a Web developer perspective, going remote isn't really an option, since the Web IS remote (ok, forget about the cache ;)). So, when mobilising your website, you should take care of considering some basic points related to network access:

• Network traffic costs
• Network coverage is not everywhere

So, to really use the potential of a WRT widget, when compared to a standard mobile Website, here are some key points to consider:

• Implement your own local cache: current WRT capabilites allow you to save only textual data, and persist this data between different usage sessions, by using setPreferenceForKey() and preferenceForKey() method. By using this capability, you can avoid unnecessary requests and give more responsiveness to your Widget.
• Design your Widget also for offline usage: this is surely not suited for all scenarios (imagine a real-time quotes widget) but, even if your widget accesses network to retrieve information, you could let your users use it even when offline, with a someway limited subset of functionalities (e.g.: you could let them view the last downloaded information)
• Implement a delayed update mechanism: imagine you're building a WRT game with remote scores table. You could let your user play your game even when offline, and then send its scores to your server only when he's under network coverage again.

Feedbacks are welcome!

These are the first 5 points (not necessarily in order of importance) I would like to comment with you all. Meanwhile, part 2 of this guide is on the go :)

Hi all!

This is my first post on these Blogs as Forum Nokia Champion, so here's a bit about me.

My name is Alessandro La Rosa, and I'm a mobile developer from Rome, working as CTO for FuelMobile, an Italian mobile company, while in free time I manage a personal blog about mobile development: www.jappit.com. I divide my mobile passion mainly among Java ME (my first love :)), Flash Lite and Web Runtime (being an old school JavaScript addicted.. ).

Now, coming to important things, It's Christmas time! And so here's a little gift for all calendar-addicted folks: a Java ME Google Calendar client!

Here are some screenshots (if you have some doubts: no, I'm not a graphic designer )

Features of this (very) first release include events browsing, searching and creation, calendar filtering, and map viewing for events location.

You can download v0.1 here: Java ME Google Calendar client.

Merry Christmas to you all!