In my last post I wrote about local connectivity - this time I'd like to continue the topic and look into USB OTG possibilities that IMHO are not well advertised to the users and developers. Generally, almost all smartphone manufacturers are on the same level taking into account hardware (e.g. the same ARM processors, memory chips and other I/O components) - the biggest difference lies in the software/OS/integrated services and look&feel of the device. Of course, the manufacturers have many opportunities to improve the hardware/software (do you remember my post "Japanese vs European smartphone features" or "How future displays for mobiles may look like?"?). IMHO, the next big thing after touch (WOW factor guaranteed!) may be USB host feature (also called USB OTG or USB On-The-Go).

No one should be surprised that we can connect different USB accessories to our PCs, but some may be amazed that the same idea works on several mobile devices. Let's start with Maemo platform. With the help of on-board USB OTG chip, F-F USB adaptor and "USB Control" application (like Kate's usb-otg-plugin) you can connect for example:

* normal PC keyboard


* USB mass storage device (e.g. your smartphone, pendrive, digital camera, various digital audio players & portable media players)


* USB toys (like little fan, LED light, etc.)


The limitation lies in A) power consumption (not enough current to supply any type of USB accessory, in this case USB HDDs, USB CD burners; according to FN, N810 can power an external accessory with a maximum of 100 mA; a standard PC USB host may output up to 500mA per USB port), B) software/drivers (like tv tuner, printer, scanner, mouse support; some USB Hubs are supported after recompilation of the kernel which is not a perfect solution for the end-user). I have no doubt that this technology will be improved in the future (don't forget that USB host was rather hidden feature of internet tablets at the beginning). I eager to know whether there're some improvements in this matter in Maemo 5 devices like N900, so don't hesitate to post comments to this blog as soon as you get one!

And other mobile platforms?
It's a pity that we still can't play that way with USB host mode on S60 smartphones (AFAIK, USB OTG extensions were intoduced in Symbian 9.3; OS provides the support within its framework, but the provision of USB Host stack and drivers is left to licensees and partners). I hope that the idea I presented more than two years ago will be introduced in S60 and it will move beyond current possibilities (USB peripheral classes supported on S60: Wireless Mobile Communications Device class for serial communication with PC - used by Nokia PC Suite, Mass Storage class, Still Image Capture Device class, PictBridge/Picture Transfer Protocol, Media Transfer Protocol). USB OTG is available on selected Series 40 devices (USB Host classes supported: Digital Audio Class, HID class + USB peripheral classes). Linux-based Android should get USB OTG too. I've got a feeling that USB host (implemented for a rich functionality) may become a distinguishing feature of internet tablets for some time, but if I am not wrong, we may see similar functionality on S60 too. Till then, power users can use such adapters to have access to mass storage devices through normal microSD slot. 

This may sound crazy, but imagine that you get a monitor, mouse and keyboard, USB Hub, Nokia Internet Tablet, then hook up everything only via USB and you suddenly have a desktop-lite PC. And that is only the beginning...

 

Have you ever needed to copy some files between Nokia Internet Tablet and S60 smartphone but there was no wifi network signal nearby and you didn't want to search for a running PC? I have, so I decided to take a look at possible solutions that don't involve internet connection (we can't use ftp, e-mail, SMB, etc.) and can be applied to N810 and N95-8Gb. The simplest way would be to use a microSD memory card, but not in this case, so let's focus on local connectivity.

The test setup: N95-2 (a.k.a. N95-8GB) v15.0.015, N810 OS2008 v5.2008.43-7, test file size: 10.045.112 bytes

 

 

 

1. Bluetooth for the beginning
N810's file manager has a great feature - you can simply manage files and folders available in paired devices using Bluetooth technology and supporting file transfer as you normally do with local files (don't ask me, why it's not a 'standard feature' also on S60). This simplifies the task (I don't have to search for 'send via bluetooth' option). Transferring ~10MB test file took 1m42s (N810 -> N95-8Gb and almost the same in the other direction). As you may guess... the more you test, the more different results you get, so I present only the best times. Simplicity is a big advantage here, but I'd expect more from Bluetooth 2.0 + EDR.

2. Wifi in Ad-hoc mode
N810's file manager can also display the shared content of available UPnP media servers (such server is available out ouf the box on S60 smartphones; you may also install UPnP media server on Maemo device, e.g. BRisa). Setting up the wifi ad-hoc for the first time is a little bit tricky (you need to remember to set the same SSID, channel number and you may use only WEP in this mode), but it's easy (and it's done only once). Please note that such network will operate in 802.11b mode, and get up to 11Mb of total bandwidth (according to specs, this is a normal behaviour in ad-hoc networks). Of course, you may use other software to copy data over wifi. The drawbacks of described solution are as follows: you need to spend time to set everything up (but you do this only once); when you want to copy not multimedia file with UPnP server, you have to rename the file extension first (to simulate multimedia file). Transferring the test file took 22s (N95-8Gb with UPnP server -> N810 UPnP client). Turn Bluetooth off, to get best times!

3. USB host mode
This is a very funny and easy way. First of all, you have to have a F-F USB adaptor and install "USB Control" application on your tablet (like Kate's usb-otg-plugin). How does it work? The USB uses a host/peripheral architecture. N810 acts as the host - like PC (USB Master role), and S60 smartphone acts as the peripheral - FAT-formatted flash memory card (USB Slave role). Such "memory card" works smoothly in N810's file manager. Transferring the test file took 20s for the first time, but 4s (!?) for the second time (from N95-8Gb to N810's internal memory; 26s and 16s respectively when transferred in the other direction). If you're curious, you may try 'time cp fileX fileY' or 'time gnomevfs-copy fileX fileY' commands and get... far better 'visual' results (well, it's linux!), but I'll stop at 20s achieved by N810's file manager - the software used for all tests.

 

I ended up with the following results: 98.48kB/s for bluetooth, 456.5kB/s for wifi and 502.3kB/s for USB. The results may vary depending on test method, testing environment and firmware versions. Bluetooth is currently the slowest, but it will change in the future because of new bluetooth standards - Bluetooth 3.0 HS. Fingers crossed, we'll get it on Nokia platforms soon (theoretically, it's a matter of some business decisions and proper firmware update; practically, we'll have to wait for new hardware-based implementation of chips, like this one)...

Of course, there's still room for improvements e.g. in pairing stage - just imagine holding two devices in one hand and shaking them twice in the same direction (all this goods thanks to accelerometer) or just touching them each other (NFC) to be paired. I would expect to see wireless USB or technologies like TransferJet to complete local connectivitiy options in future devices. Some of mentioned technologies are implemented on a limited number of phone models, but... what is your choice for a new local connectivity highspeed standard?

 

A beta version of Java Runtime 2.0 for S60 (JRT 2.0) has been made available via Nokia Beta Labs. As you may remember (I wrote about it some time ago), Java Runtime is now versioned and released separately from the underlying S60 Platform. The latest version of JRT can be installed directly to our smartphones, using the built-in Nokia S60 Software Update functionality. What's new? As you may read on Nokia Beta Labs, it is a totally re-written Java mobile execution environment for Nokia S60 devices. It gives several usability and performance improvements, including: one-click application installation, improved application launch user experience (a 'loading' animation is shown), improved execution performance.

 

 

I think that major changes made under the hood may mean "arrival of MIDP 3.0 era" on Nokia devices in the near future (I hope so!). What do you think about this theory?

 

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

 

In case you're still interested in developing Java ME applications  there's a final version of Java ME Platform SDK 3.0. I wrote about it's features (based on EA version) ealier on my blog. One may note that it's still only available for Microsoft Windows XP or Vista (what about linux?).

Download link for final version (116.7 MB)

 

First of all, it's worth noting that Nokia has introduced a new naming scheme for Java platform - "Starting from S60 3rd Edition Feature Pack 2 Java Runtime for S60 is versioned separately from the underlying S60 Platform with aim to provide more frequently new Java versions to the market. Key drivers for that are for example faster time-to-market for new features and a possibility to update Java Runtimes for S60 independently in the future via Nokia SW Update." IMHO, it's a very good decision - the concept is very similar to e.g. Sony Ericsson Java Platform 8 (JP-8) or ealier versions. Currently published versions include Java Runtime 1.3 for S60 (JRT 1.3) and forthcoming Java Runtime 1.4 for S60 (JRT 1.4).

JRT 1.3.x is in use in the Nokia 5800 XpressMusic (sw 20.0.012 onwards) and includes some new features like MIDP security prompting enhancement (a possibility to select the security setting, when the prompt is shown), popup textbox, freely resizable fonts, support for new system property "com.nokia.mid.msisdn" to retrieve the MSISDN, Nokia UI API 1.2, orientation support for Location API (JSR-179) if device has magnetometer hardware, forcing certain orientation by using "Nokia-MIDlet-App-Orientation" JAD attribute, support for downscaling of Canvas graphics.

JRT 1.4.x is in use in the forthcoming Nokia N97. It's very nice to see Mobile Sensor API (JSR-256) support (supports accelerometer, battery charge sensor, charger state sensor, network field intensity sensor). Now you can access sensors natively in Java ME like it's done in C++ (sensor framework) or WRT widgets / Flash Lite (Sensor Service API) and don't need "Multi-Language Programming". The API came to the platform quicker than I expected. JRT 1.4.x includes also Nokia UI API 1.3, 9-way navigation support, 8 Mpix camera support, improved Java support for QWERTY devices, On-Screen Keypad on device with touch screen and hardware keyboard, finger usability improvements for touch screen (tap detection).

The version of JRT can be checked by using standard MIDP system property "microedition.platform". A working sample MIDlet code is available here.

 

 

Some time ago I wrote about a way to run MS Windows and MAC on Nokia Internet Tablets. The trick was to use DOSBox utility - x86 PC emulator. It's very interesting to see DOSBox running on S60 (and it's not a demo). What's the use of this? Well, mostly fun & prove of concept (it may not be usable in many cases, but isn't it cool?). Someone may use it to run old DOS apps or games, others will try to install Windows 3.1 or Windows 95 (rather to prove that these systems do work on Symbian devices / ARM hardware).

 

 

 

 

Have fun!

The port was possible thanks to some libraries published by FN/Symbian (like OpenC/C++ or SDL). BTW, have you heard about any examples of the successful use of OpenC, OpenC++ and RGA plugins in open-source applications ported to S60? I'm waiting for your entries!

Forum Nokia provides some success stories on Open C/C++ technology landing page and Quick Start section, you may also find some examples of using these libraries here (like Open C IRC Example, Open C FTP Client Example, Open C SMS Crypto Example and some games).

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?

Version 6.5 of NetBeans IDE has been released! The 'mobility part' is now included into one standard Java bundle that also contains Java SE, Java EE, Java FX, web components and servers (GlassFish, Tomcat). The installation file is about 212MB (NetBeans 6.1 'mobility' was 72MB)! One may ask why there's no separate bundle - IMHO, the answer is simple - Java ME and Java EE complement one another in different environments and more IDE components are Java ME+EE enabled (like webservices or SIP). Of course, you can add or remove packs later using the IDE's Plugin Manager (Tools -> Plugins).

What's new for Java ME developers?

• new project wizard for adding custom components to the Visual Designer Palette
  
• new SVG UI components in the enhanced SVG Composer enable rich UI design
  
• new Data Binding Custom Components in the Visual Designer Palette
  
• upgraded obfuscation tool to ProGuard 4.2 and test framework to JMUnit 1.1.0

You'll find more (screenshots included) about described features at NetBeans IDE 6.5 New and Noteworthy page.

Bonus links:
NetBeans IDE 6.5 Features
NetBeans IDE 6.5 Tutorials and Documentation
Guided Video Tour of NetBeans IDE 6.5

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

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!

 

 

Java ME Platform SDK toolbox is the successor to the well known Java Wireless Toolkit 2.5.2 and Java Toolkit 1.0 for CDC. It integrates CLDC, CDC and Blu-ray Disc Java (BD-J) technology into one SDK. It provides device emulation, a standalone development environment and a set of utilities for rapid development of Java ME applications.

The key features include:

• Integration with 3rd party emulators and Windows Mobile devices
  
• On-device deployment and on-device debugging
  
• CLDC/MIDP, CDC/FP/PBP/AGUI and BD-J integrated into one SDK
  
• New CLDC HotSpot Virtual Machine
  
• Optimized MSA 1.1 stack with extensions
  
• Profiling support
  
• BD-J support
  
• New development environment based on Netbeans Platform
  
• Lightweight UI Toolkit (LWUIT) integration
  
• Device search database integrated in SDK
  

 

From developer's point of view, the deprecated KVM has been replaced with the CLDC HotSpot VM which provides a significant performance advantage over KVM. Java ME Platform SDK contains an optimized CLDC/MIDP stack that is build upon CLDC 1.1 and MIDP 2.1. It also contains the following new JSRs: Mobile Sensor API (JSR 256), XML API for Java ME (JSR 280), Java Binding for the OpenGL ES API (JSR 239). What I really like is the support for XML API for Java ME and Mobile Sensor API. The first API enhances the XML support distributed over several JSRs today (it provides SAX2 event handler-based parsing, efficient DOM-style document processing) and it's goal is to avoid further fragmentation by offering one common set of XML APIs. The second one and my favourite allows Java ME application developers to fetch data from sensors (sensors can vary from physical sensors such as magnetometers and accelerometers to virtual sensors that combine and manipulate the data they have received from various kinds of physical sensors. An example of a virtual sensor might be a level sensor indicating the remaining charge in a battery or a field intensity sensor that measures the reception level of the mobile network signal in a mobile phone. JSR 256 supports many different types of sensor connection - wired, wireless, embedded and more). Wouldn't it be nice to see this API working on S60 5th edition (there's a sensor framework for C++ and it would be sensible to have JSR 256 too)? Maybe it will happen in S60 5th FP1 . Java ME Platform SDK comes with a built-in "sexy" LWUIT library. What's really cool is the built-in WURFL database search tool that allows you to search a large number of mobile device properties (currently more than 8000 device specifications). As the tool is based on Netbeans platform it looks familiar to Netbeans IDE users (e.g., look&feel, profiler based on Netbeans profiler, shared project system, modularized environment with the ability to update on the fly).

The Java ME SDK is currently available as an Early Access for Windows XP and Vista.

The new Java ME SDK looks attractive, doesn't it? Looking forward to your comments.

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:

 

The number of OSes that can be run on N810 Internet Tablets just grows and grows. Now it's time for MS Windows family. I hope you still remeber Windows 3.1. The trick to run it on NIT is to use DOSBOX utility - x86 PC emulator (the instructions may be found e.g. here or on Internet Tablet Talk forums). What's more interesting, there's a proof that you may also run Windows 95 this way, but don't expect that it will start and work smoothly (you really need to be patient). Thanks to very active Internet Tablet community, you can also have MAC on MIT by using the Basilisk II Macintosh emulator (list of Macintosh Software that can be run on a NIT and instructions).

Purists would extend the list of working OSes by adding Android, Ubuntu and numerous emulators (all ported to maemo) like Amiga 68k - UAE, Apple II - Winapple, Commodore 64 - Frodo, Palm OS - Access GarnetVM, TI-89 Calculator - TiEmu 2 (just to mention the most interesting ones). Can you do this all on iPhone?

 

So now, the "open platform" slogan gets completely new dimension...

It's interesting how marketing works these days. We don't have devices yet, but we have a chance to see new mobile OSes in action working on other devices. Mentioned Android and LiMo demos are only Java ME based apps, but this forced me to ask the question: will we have a chance in the future to buy a smartphone with the mobile operating system of our choice - just like in PC world? In case of Nokia Internet Tablets it's possible to run Android (not officially, of course) - I wrote about it here. It looks that the platform is even more flexible - Nokia is actively sponsoring an Ubuntu ARM port. 

 

I'm wondering how many people would be interested in experimenting with other mobile operating systems (let's assume that we'll have a possibility to easy (re)install mobile OSes on the same device)... What's your opinion on this topic?

Bonus links:
Android API demo
Android UI demo
LiMo R1 UI demo