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

Today, a final version of NetBeans IDE 6.1 has been released. I was reviewing some of NetBeans Mobility features not so long ago. Next point on NetBeans IDE roadmap is version 6.5.

Download link for version 6.1

 

Some time ago I promised to write small review about NetBeans Mobility. Last week, I attended NetBeans RoadShow 07-08 conference in Warsaw, Poland. Of course, I was mainly interested in sessions related to mobility and new NetBeans features. I had an unique opportunity to ask Sun's software engineer about future of Java ME and NetBeans Platform. In the case of Java ME, final MIDP 3.0 specification should be ready later this year and Java ME is also part of Java FX Mobile (a mobile phone running JavaFX APIs will also be able to run Java ME applications), so "I shouldn't worry that I'll have to change a job". In the case of NetBeans Mobility, the future looks also bright - future versions will support MIDP 3.0, JavaFX Mobile, more device platforms, more components and visual data binding.

Let's look into NetBeans in version 6.1 (RC1). It may be considered as development IDE for Java ME and widgets (!). Generally, it starts a lot faster than previous versions and has smarter code completion (including Javadoc).

J2ME:
In addition to NB Mobility 6.0 features, it has even better support for SVG. Thanks to SVG, there're two developing roles in the project: graphical designers create images (menus, etc.), developers add business logic. Creating SVG application is really simple - it's done by using "Microsoft programming method" (you need mouse, mouse pad and your eyes) - almost no programming at all (check FN screencast Getting Started with JSR-226 Applications for S60 Devices that demonstrates the creation of a simple Java ME application using the SVG features of NetBeans Mobility and the example used in the presentation). The "SVG programming" is simplified by visual designer supporting such components as: SVG Menu, SVG Splash Screen, SVG Wait Screen, SVG Image, SVG Player. What's interesting, some components of Visual Mobile Designer are displayed only if your application supports chosen JSR (e.g., if your application doesn't support SVG API, you won't see SVG components). The developers who are interested in developing in NB Mobility may be interested in a screencast that illustrates how to create, edit, package, and deploy a simple Java application.

Widgets:
Although currently there is no plugin for widgets like for Eclipse IDE, it's still possible to write widgets easily. You can use IDE's HTML, CSS and JavaScript editors with an Ant script to make everything automatically. Among "standard JavaScript editor features" like semantic highlighting, marking occurrences, refactoring, tasklist or code completion (of course, not for specific widget APIs), there's one more worth mentioning - Quick Fixes and Semantic Checks. The IDE warns the developer when code has no side effects, when using an assignment in a conditional (if x = y) or when code has inconsistent returns from a function (where some return expressions return a value, and some do not).

There's a great (old), but extremely useful feature for people developing in both IDEs - Eclipse and NetBeans. You can have the same keymap (in NetBeans choose Tools -> Options -> Keymap and set to Eclipse), e.g. formatting of source code in both IDEs under Ctrl+Shift+F (normally Alt+Shift+F in NetBeans, where Ctrl+Shift+F means Find in projects option). This's the first option I set, after deactivating all not used modules/plugins.

However, there're many things that can be done to enhance the NetBeans Mobility IDE 6.1:

• word "Mobility" for Sun means 'mobile Java' - why there's no support for developing WAP (WML, WMLScript, XHTML MP)? Since the IDE supports HTML, XML, JavaScript it wouldn't be a problem to add such support and make the IDE more "Mobility edition",
  
• mobile widgets support would be a plus,
  
• new components like: MMS composer/editor, tabs component, lbs - show your current position component (that will hide the complexity of implementing it on many devices - location API / bluetooth API + NMEA), lbs - show your position on map (Google/Yahoo) component...