Jacek Wojciechowski's Forum Nokia Blog

Widgets: One more step to simplicity...

jack44 — Mon, 29 Jun 2009 20:51:23 +0300

There's no doubt that widgets still remain in the spotlight. It was not so long ago when Nokia WRT plug-ins for Adobe Dreamweaver, Microsoft Visual Studio and Aptana Studio were released (IMHO, these represent about 80%-90% of the web development environments, so it was a well-thought-out decision from Nokia). Then, Nokia Mobile Web Templates were released (I hope I'll get back to these components in my next post). Now, we can test Platform Services 2.0 JavaScript API (beta release).

What is it? It's a set of JavaScript extensions for the Web Runtime environment on Nokia devices that enables developers to access device features with one or two lines of JavaScript. Apart from access to key device features like GPS unit, sensors, contacts records, calendar entries, messages, landmarks, media files, log entries, and system status information, new API adds access to device’s camera. The API also includes startEditor to enable use of native application editors for user data entry (e.g. calendar.startEditor(onStart, null)). The documentation notes: "This method has the advantage of presenting the user with a familiar data entry UI. It also requires the user to confirm data entry in the normal way, making the addition of data transparent and adding to the user’s trust in the application."

There's one more sentence that catches my eye:
"The Platform Services 2.0 JavaScript API is also designed to be platform independent, offering the possibility for its implementation on other web browser and Web Runtime implementations on Nokia devices, as well as in PC and other mobile browsers."

Wouldn't it be great to see this API coming to WebOS/Palm, Android/Google, mobile Firefox (Fennec) than runs on many mobile platforms,... ? Is there a chance for "write once, run anywhere" slogan to become reality on many mobile web platforms? Currently, Platform Services 2.0 JavaScript API is compatible with the Nokia 5800/5530/N97 and the emulator supplied in the S60 5th Edition SDK for Symbian OS (most of the functionality should also work on selected S60 3rd Edition, Feature Pack 2 devices).

Location-aware browsing on mobiles

jack44 — Sat, 13 Dec 2008 15:06:44 +0200

Natural way of using location-based services (especially maps and navigation) on our mobiles is to use dedicated applications like Nokia Maps, Google Maps for S60, etc. Such applications are written in native C++ and have access to AGPS, wi-fi, network/cellid information, and other technologies that work indoors or outdoors and provide information on location with better or worse accuracy. Also natural is to access map services through browsers - this works both in mobile device environment and PC/notebook world. But providing information about where you are for a browser in a mobile environment is a little bit tricky. Let's consider some potential solutions working in a browser environment (but you may also check Creating Location-Aware Applications document).

Plugin for a browser
First of all, this solution will work only for a chosen browser and you need to port it to different platforms (e.g. Symbian, Windows, Linux, etc.). Of course, knowledge of Symbian's C++ is a must to write such plugin (not mentioning about signing it by using Symbian Signed). Secondly, you have to force the user to install the plugin. Thirdly, is there a "proper way" to develop plugins for S60 web browser that will operate like Firefox Add-ons? Browser Plug-in API must suffice here. (OK, you may also develop an application that will use GPS and Browser Control API, but it's not a preferred solution here - it's like creating your own location-aware browser).

Local geolocation server
Of course, it's possible to develop such simple background server that will be a proxy/cache between a webpage running in a browser and location provider by using one of available S60 programming languages (e.g. use HTTP libraries for Symbian C++ or Python web server module to make the task a lot simpler, or even mix your solution with opensource MWS / Racoon, PAMP or this small HTTP server). It forces the user to install additional software that will consume some disk space and RAM (not mentioning that the solution isn't portable). The big advantage is that such local HTTP server may be used by many other S60 applications running on different runtimes and it may provide any information you can normally get via native application (in case of location-aware services: when there's no GPS signal read MAC addresses/SSIDs of all available wlans with their signal strength, Cell Id/Location Area Code/MCC/MNC that combined with remote or local database provide hybrid positioning system).

S60 Platform Services
Currently, you've got access to these services via S60 5th+ WRT widgets (WGZ files) and S60 5th+ Flash Lite. S60 Platform Services (Location Service API, Landmarks Service API) aren't ported to other mobile platforms (BTW, Series 40 could adopt WRT widgets from S60 - why not?). What's more, it seems that it's not possible to use S60 Platform Services in a web browser environment (outside WRT widget) - what a pity! I can also imagine using embedded Flash content - Flash Lite 3 on S60 5th edition delivers extensibility through S60 Platform Services (access to device location through ActionScript Service APIs). I'm not an expert here - can someone confirm that such solution may work in practice for a Flash embedded into a webpage on S60 browser?

Google Gears
This (still beta) project enables more powerful web applications, by adding new features to web browsers. It provides The Geolocation API that enables a web application to obtain a user's geographical position. It's available on some (also mobile) browsers, but currently skips S60. It's great to see it coming slowly to Maemo.

W3C Geolocation Specification implemented by the browser
IMHO, it's a very good solution to follow. Using W3C Geolocation Specification will help to avoid fragmentation and that will have big influence on development of location-aware web applications (one API + many browsers = success!). Developers will not have to develop code to address browser-specific geolocation APIs (S60, Android, Windows Mobile use different solutions today). From the specs... "The Geolocation API defines a high-level interface to location information associated with the hosting device, such as latitude and longitude. The API itself is agnostic of the underlying location information sources. Common sources of location information include Global Positioning System (GPS) and location inferred from network signals such as IP address, RFID, WiFi and Bluetooth MAC addresses, and GSM/CDMA cell IDs. (... ) The Geolocation API in this specification builds upon earlier work in the industry." Where's the catch? At the time of writing, the document has a status of informal proposal. Developers will be able to play with the API in the upcoming beta releases of Firefox 3.1, as well as alpha releases of Fennec (Mozilla Firefox web browser for mobile devices like Maemo based N810 or S60). Developers can also try Firefox 3 and Geode add-on that provides an early implementation of the W3C Geolocation specification.

I wish to have... S60 mobile web browser with geolocation APIs! I hope that many (mobile or not mobile) web browsers will support this specification in near future! (please do)

I can imagine that I use geo-referenced blog, where notes, music, photos and videos I post to the blog are automatically linked to my location (no matter whether I use smartphone, Nokia Internet Tablet, or notebook for blogging; no matter whether I have access to GPS, wifi or GSM signal to define my current location). I can imagine RSS service/browser that treats in a special way GeoRSS feeds, so I can only see the information relevant to the place I am. I can imagine banking service that can show me the nearest ATMs (cash machines) after accepting the security note. I can imagine highly personalized movie website that... And what are your ideas?

S60 5th Edition: widgets and security

jack44 — Tue, 18 Nov 2008 19:37:36 +0200

When I first heard about S60 Platform Services enabled widgets I started to ask myself about security. The first thought was, "I'll have to sign new widgets with something similar to Java Verified or Symbian Signed". Such solution wouldn't be great for many reasons (killing great ideas for widgets, web developers coming from desktop environment wouldn't like it too, signing costs, etc.). Therefore there's no "widget signing" at all. But, is it safe for the end-user?

The first thing to note is that S60 widgets access the network through the Web Browser for S60. In this respect, widgets are as safe as running web pages in the browser. WRT widgets also implement a sandbox security model (it makes me think of Java ME here), and they only have limited access to the S60 Platform Services. Widgets are always considered untrusted by the device. This means that access to platform services (such as user data, location) is controlled and that mobile device users must grant permission before a widget can access network services.

From developer's point of view, WRT 1.1 utilizes a common component called Runtime Security Manager to enable access control to platform services - it registers a widget when it is installed; when running, the security manager performs runtime access control to platform services (prompts the user) according to the access policy; finally, it unregisters a widget when it is uninstalled. Access policy is defined by a set of capabilities (ReadUserData, WriteUserData, Location, NetworkServices) that are allowed automatically or granted to the user via prompts, and by duration of access (one time or session based).

It's a pity that access policy for WRT 1.1 is not customizable by the widget developer (OK, I agree here!) or the user (Why not? Because of security policies! Thus, S60 5th edition Application Manager doesn't show 'Suite settings' for widgets).

BTW, I know that it will not happen, but... wouldn't it be great to have all this goods based on WRT 1.1 running also on S60 3rd FP2 devices (via firmware upgrade)?

S60 5th Edition: enhancing widgets... Let's get widgetized!

jack44 — Wed, 05 Nov 2008 19:02:48 +0200

As you probably know, S60 5th Edition brings WRT 1.1 with support for S60 Platform Services through JavaScript Service APIs. Of course, the new Web Runtime environment is backward-compatible, so widgets created for WRT 1.0 run normally with WRT 1.1 (but you should take touch UI or different display sizes into consideration when running WRT 1.0 widgets on newer mobile devices). It follows logically that widgets created using the WRT 1.1 Service APIs do not work with WRT 1.0

What's new in widgets?

In addition to "old" widget, menu, MenuItem objects and Systeminfo Service API (sysinfo object) developers get new S60 Platform Services and Service APIs that allow to:

access and launch applications on a device using the AppManager Service API (e.g. retrieve a list of user/pre-installed applications; launch an application as embedded or stand-alone, based on an application ID or given document or MIME type),
access and manage calendar information using the Calendar Service API (e.g. access, create, and manage calendars and calendar entries stored on a device; import and export calendar entries),
access and manage information about contacts using the Contacts Service API (e.g. retrieve information about contacts, contact groups, and contacts databases; create, edit, and delete contacts and contact groups; import and export contacts; organize contacts into contact groups; also worth mentioning is that the information can reside in one or more contacts databases stored on a device or in the SIM card database, so you have all you need!),
access and manage information about landmarks using the Landmarks Service API (e.g. retrieve information about landmarks, landmark categories, and landmark databases; create, edit, and delete landmarks and landmark categories; import and export landmarks; organize landmarks into landmark categories),
access device location information and perform location-based calculations using the Location Service API (this API relies on the GPS capabilities of the device to provide location information),
access device logging events using the Logging Service API (e.g. access mobile device logging events such as call logs, messaging logs, and data logs),
access information about media files stored on a device using the Media Management Service API (widgets can retrieve metadata about the media files stored in the Media Gallery of an S60 device, so you can create widgets such as a custom photo viewer or audio player, that display or otherwise incorporate media),
send, retrieve, and manage messages such as SMS and MMS using the Messaging Service API (widgets can use the Messaging Center of an S60 device to send, retrieve, manage or notify the user when new messages arrive or even change the status of a message),
access data from the physical sensors of a device using the Sensors Service API (The data from a given sensor is mapped to one or more sensor channels, which the API can listen to. That is, you can search for sensor channels available on a device; listen for data provided by one or more sensor channels; retrieve information about and modify sensor channel properties; notify the user when a sensor channel property is changed; Of course, the available sensors depend on the device.),
access and modify system information on a device using the SystemInfo Service API of WRT 1.1 (as opposed to 'old' SystemInfo Service API of WRT 1.0, you can also modify system attribute values).

That's all for this time - next time I'm going to write about security of widgets, so stay tuned for some interesting facts...

Now, let's get widgetized!

Are mobile browsers ready for full web?

jack44 — Fri, 05 Sep 2008 13:25:30 +0300

Looking from developer's perspective, developing for mobiles is not always that easy. If you're mobile web developer, you always have to test your work on many mobile browsers. The Mobile Web Test Suites Working Group has released a set of tests that assess the compatibility of mobile browsers with well-established, current and brand new Web technologies. The test (in the same spirit as the ACID tests) combines in a single page tests for 12 Web technologies. The latest version (1.41) has some improvements over April release. The source code is also available, so one can check how everything is tested.

And the results... are really different for every mobile browser - this applies also to mobile browsers based on "the same" WebKit open source browser engine (AFAIK, WebKit engine powers S60 3rd+, S40 6th+, Android platform and Apple devices, so it can be said that it dominates the 'mobile web') - see the gallery of screenshots for the first version of Web Compatibility Test for Mobile Browsers and the latest version. No mobile browser has passed all the tests so far, but I hope this will change in the near future.

The results for S60 SDK browsers (WebKit based):

As can be seen, there's still room for improvements in some areas (tests: 6, 7, 9, 12, 13, 14, 16). Will upcoming S60 5th edition be even better?

The test is available at http://dev.w3.org/2008/mobile-test/test.html
QR code for quick access:

Shorten your long URLs

jack44 — Tue, 08 May 2007 18:28:34 +0300

Long URLs are difficult to remember and not easy to enter into your mobile device (especially if you don't have QWERTY keyboard like in Nokia E90/E70/E61(i) or external bluetooth keyboard). However, there are various online services that shorten long URLs (for example TinyURL or SnipURL).

Let's check an example: it's not easy to enter without a mistake quite long URL to my Forum Nokia Introduction Page which is: http://www.forum.nokia.com/main/forum_nokia_champion/forum_nokia_champions/Jacek_Wojciechowski.html (99 characters), but it's much easier to enter and remember eg. http://snurl.com/jacekw (23 characters). This way I can save 76 characters in my SMS/MMS message (it's ca. 77% of the original URL!). You can send short URLs in emails without the fear of them being wrapped and as a bonus if your underlying URL changes you can always modify your shortened URL.
Generally you can save much more time if you set a bookmark in your device's browser ;-)