Introduction to Series 40 full touch for developers

Car Race 3D Exercise App running on the Nokia Asha 311We’re kicking of the webinar series for the new Series 40 Touch phones tomorrow! The first session will walk you through the new Java ME APIs introduced in the Developer Platform 2.0.

The packed agenda covers all the important topics that you will need to know about when you’re moving your Java ME apps to the new touch UI:

  •  Introduction
    • Platforms & Versions
  • New features for developers
    • UI
    • LWUIT
    • Text Input
    • Touch Input
    • Sensors
    • Location & Maps
  • App Compatibility
  • Publishing & Monetization
  • Resources
     

The recording of the first webinar session is online for viewing. The downloadable version of the slides is slightly extended, featuring some more details than in the 1h webinar. 

You can download the full source code of all the apps shown during the presentation – the blue text box in the top right corner or the slide always refers to the full example being demonstrated.

JavaME-Touch-Examples-v2.0.0.zip

As a special bonus, the example package and the downloadable slides also include a few exercises (+ the corresponding solutions), so that you can put your new knowledge about the APIs into use right away! The excercises are both based on 3D graphics:

  • In Monkey Touch 3D you’ll add drag & pinch support to view the 3D model of a monkey, and add orientation support to dynamically switch the app between landscape & portrait mode, depending on the physical orientation of the phone.
  • Car Race 3D let’s you extend an endless 3D racing game with support for controlling the car using acceleration sensors, instead of physical keys (which would no longer be availble on the new touch phones)
     

Registration

In different webinars during the following days we’ll also look at the design aspect and the IDEs (both the new Nokia IDE for Java ME as well as NetBeans). Every session is held two times, so that you can join no matter which time zone you live in.

Register for the webinars now!

Cross Platform NFC Geo Tags

Nfc Geo Tag on the Nokia N9.Imagine the following: you’re playing a treasure hunt game in your home town. At one station, you touch an NFC tag with your Nokia phone; this opens Nokia Maps to reveal the location of the final place where to collect the treasure. Similar scenarios are possible if you’d like to use Nokia Maps to navigate to the point of interest that you just read about; for example, the St. Stephen’s Cathedral in Vienna, after reading about it in a tourist brochure.

Alternatives

To implement this, you need to store the longitude and latitude of the landmark on the NFC tag (you could also call them "GPS coordinates"). But how to store them? This use case hasn’t been set by the current NDEF URI RTD specification of the NFC Forum, so there isn’t necessarily a solution that works across all NFC enabled phones.

One approach is using the geo: URI scheme (RFC 5870). In the most simple and short form (important due to the limited space on a tag), the URI to write to the tag could look like the following: "geo:60.17,24.829". This encodes the decimal coordinates with latitude of 60.17 and longitude 24.829 in WSG-84 (the location of the Nokia House in Finland, by the way). This works fine with the N9 and directly opens the Nokia Maps client showing the correct location, given that you have PR 1.1+, which is required for default NFC tag handling by the phone. However, Symbian currently can’t understand Geo URIs.

An alternative is to write the URL to Nokia Maps to the tag, according to the Nokia Maps Rendering API. For example: http://m.ovi.me/?c=60.17,24.829. When opening this URL on a Symbian phone, it automatically opens the Nokia Maps client at the correct location. On other devices like the PC, it redirects to the full Nokia Maps web client or the HTML5 version of it. However, MeeGo Harmattan just shows the static map image and doesn’t start the Nokia Maps client.

Cross Platform Geo Tags

So, those two approaches don’t work across the Nokia portfolio. However, there is a simple solution: store the URI of a small script on a server, which then redirects a MeeGo (or Android) phone to the Geo URI, and every other device to the Nokia Maps URI. You can retrieve the operating system by checking the user agent of the browser.

On MeeGo, you can directly send out an HTML header to redirect the browser to the Geo URI (causing it to open Nokia Maps), without loading and rendering the actual web page. On Symbian, a JavaScript redirect can put the browser on the right track and trigger it to open the Nokia Maps client.

Creating Nfc Geo Tags

To make this easier for you, the new Nfc Interactor app (available for Symbian and the Nokia N9) lets you conveniently write geo tags by just entering the coordinates. In the tag compose view, you can also choose which of the three variants you want to write to the Nfc tag. The app will take care of formatting the actual NDEF message for the tag.

For your experiments, the maps redirection PHP script explained above is hosted on http://nfcinteractor.com/m.php and can be used with a URI on the NFC tag like this:

http://nfcinteractor.com/m?c=60.17,24.829

Note that there is no service or uptime guarantee for the hosted script at nfcinteractor.com – it’s intended for testing purposes only and could be removed at any point. You should host the script on your own server for real-world deployment. See the web services information page for more details.

Additionally, hosting the service on your own web server allows you
to add custom-named places to the script, so that the link on the tag
doesn’t need to contain the coordinates, but you can link to a custom
place-name instead. See the source code of the script for details on how
you can add your own places. Example:

http://nfcinteractor.com/m?l=nokia

The source code of the Geo Tags redirection script is now also available under the open source BSD license, so that you can adapt it to your needs, add custom locations (instead of specifying the coordinates as parameters) and upload the script to your own web server.

Some findings on application orientation in MeeGo 1.2 Harmattan

Few days ago I had a chance to play for a wile with my Nokia N950. I’ve tried to port some Qt application from Symbian to Harmattan and unfortunately faced with lack of support of QWidget and QGraphicsView based applications in that platform. Some of my findings are below:

  1. QWidget-based objects don’t have any native style support and looks exactly as in Windows. Which is obviously awful
  2. There is no working API to set application window orientation. Moreover, the default orientation is landscape! Some interesting details are here.
  3. In case you are using QML-based UI you should rewrite it and use Window\PageStack\Page classes to be able to change your app orientation. Or probably rotation trick will work for it, but i didn’t check.

That seems a bit unfair for me as there are Qt 4.7.x libs preinstalled and QWidgets\QGraphicsView are still mainstream ways to develop UI for it. That might cause a lot of problems during the porting of Symbian\Maemo5 applications to Harmattan.

In my case the app i tried to port contains QGraphicsView with some pixmap elements in it and some QPushButtons with images over them (without text). So i’m luckely avoid QWidget-style problem.

Its launched on N950 without any changes in sources and looks great (of course due to devices screensize the images were smaller). But it had landscape orientation. And i spent a lot of time on fixing such a simple thing. Finally, i have managed to rotate UI using the following:

  1. Call of QGraphicsView::rotate(270) to automatically rotate all items in it.
  2. Change x and y in event handlers code to fix some animation framework staff.
  3. Just move QWidget-based buttons position and rotate all images in it.

And one more step (that’s actually the real reason of that post and the only thing I have to share). The system itself still treats your application window as landscape oriented. That mean, for example, that if the "Top slide closes the application" setting is switched on in your device it will not work correctly for your app window. Actually, it will but with wrong sliding direction (right side is top for landscape oriented windows). To fix this behavior and let system know that your window is portrait oriented you should call following function for your top-level widget:

 
Normal
0
false
false
false
RU
X-NONE
X-NONE

Normal
0
false
false
false
RU
X-NONE
X-NONE

#ifdef Q_OS_UNIX

#include <QX11Info>

#include <X11/Xatom.h>

#include <X11/Xlib.h>

#endif

 

enum MyOrientation

{

    Landscape = 0,

    Portrait = 270,

    LandscapeInverted = 180,

    PortraitInverted = 90

};

 

static void writeX11OrientationAngleProperty(QWidget* widget, MyOrientation orientation= Portrait)

{

#ifdef Q_WS_X11

    if (widget)

    {

    WId
id = widget->winId();

    Display *display = QX11Info::display();

    if (!display) return;

    Atom
orientationAngleAtom = XInternAtom(display, "_MEEGOTOUCH_ORIENTATION_ANGLE", False);

    XChangeProperty(display, id, orientationAngleAtom, XA_CARDINAL, 32, PropModeReplace, (unsigned char*)&orientation, 1);

    }

#endif

}

 

 int main(int argc, char *argv[]) {

    QApplication a(argc, argv);

    Form f;

    writeX11OrientationAngleProperty(&f);

    f.showFullScreen();

 

    return a.exec();

}

 

 


The code was copy-pasted and adopted from some MeeGo sources.

Unfortunately it just tells the system that your window orientation is changed, so OS can manage it accordingly. But it doesn’t change orientation of content inside window so it doesn’t affect window rendering.