With the newest version of the application you can use your NFC enabled phone to check-in automatically by just tapping and NFC enabled/tagged poster. No more tedious steps of launching an application waiting for location fix, connecting etc… With NFC this is all done with a simple tap.
Furthermore, the developer made it even easier for the user to check-in – without the need to have the app running – just tap and the app starts automatically and checks you in. Pretty awesome and again demonstrating the convenience of NFC! In a separate post Andreas explains how as a developer you can implement application autostart .
Foursquare with NFC support is available in the Nokia Store for Symbian NFC enabled phones (download Symbian version here,N9 support coming soon) . And the best thing about it is that it is not a separate application just for NFC sake. Developers simply added the support for NFC to the existing application version!
Opportunities for venue owners
Venue owners can now create smart posters asking users to Check-in with embedded NFC tags, so that visitors of their venues that have an NFC enabled phone (from any brand) can easily perform the check-in by just tapping the smart poster. Additionally NFC check-ins can be considered as real check-ins as the user had to physically be there to check-in, giving venue owners the potential to have much more accurate data versus normal check-ins. We have demonstrated this concept as verified check-ins at Nokia World 2011 (read NFC Times article here)
How to create Foursquare Check-in Smart Posters?
There are several ways to do it. All you need is an NFC tag encoded with the foursquare venue URL (i.e.: https://foursquare.com/v/nokia-house/4af3fa31f964a520bbef21e3 ) that you stick behind your 4Sq sticker/poster. NFC Hub, for instance offers a readymade solution for 4Square Check-in campaigns. Here is a demo example of a smart poster I did for an event this weekend.
You’ve created your first NFC app, which acts upon data stored on tags. Wouldn’t it be nice if the phone automatically launches the app when you touch your NFC tag?
This guide explains how to achieve this using Qt Mobility APIs. You need some background knowledge about NDEF messages and records in general to be able to make most out of this guide. To take a deeper dive into the standards covered here, take a look at the specifications at the NFC Forum.
Record Type Names
Each NDEF record has a type name; some are standardized by the NFC Forum for compatibility (e.g., the Smart Poster [urn:nfc:wkt:Sp], URL [urn:nfc:wkt:U], etc.). Every NFC capable phone should be able to handle those well-known types.
You can also read these record types from within your application. However, you can’t register your app to be started when touching a tag that only contains a well-known record — it’s always the phone that handles those (but you can write a browser-plugin to react to specific URLs and use this to open your app, like the FourSquare application for Symbian & MeeGo is doing – read more about the FourSquare app at Jures blog post).
To autostart your app directly when touching a tag, you need to use your own, custom record type.
Your custom type name has to follow a standardized format as well — according to the NFC Forum External Type Name. Like the well-known type, it starts with "urn:nfc", but then continues with the namespace "ext". Afterwards, your type name must contain the domain name of your organization, then a colon, and then your own type name. A complete example:
urn:nfc:ext:nokia.com:nfccorkboard
Note: the first three parts of the type name ("urn:nfc:ext:") are actually encoded in just one byte on the tag. The rest of your name is stored in plain text; with the usually very limited size of the tags, make sure that the name you choose isn’t as long a whole novel.
In addition, you can store any kind of data (payload) for this record on the tag, and usually only your application will be able to understand the contents. For example, a custom record to check in to a social network may contain the ID and the name of the place in the payload.
Handling Custom Type Names
Your app can obviously read and understand your own record type, and it can also be started when the user touches a tag that contains your custom record. But what if the phone doesn’t have your app installed yet?
The solution is elegant: you simply store two records in the NDEF message on the tag. First your own, custom record; then a well-known URL or Smart Poster – for example a link to the Nokia Store, allowing users to download your app. See below for instructions on how to create such a tag.
What happens when you touch the tag is the following: if your app is already installed and registered for your custom record type, it will be started. Otherwise, your custom type will be unknown to the phone, and it’ll ignore your record and proceed and handle the next record — the well-known URL. The phone will take care of this one and send your potential future user to the Nokia Store to download the app.
The ndefheadergen tool mentioned in the docs isn’t shipped with the Qt SDK, but it’s actually not required — it just auto-generates the same few files that you can easily take and adapt from the documentation (linked above) as well. If you’d like to get the tool nevertheless, download the Qt Mobility source code and compile the ndefheadergen project for your desktop OS.
On Symbian, you only need to adapt an XML registration file and ensure that it’s installed together with your project by adding the deployment into your .pro file. Just insert the name of your app, as well as the custom record type name you’ve selected for your application.
Note: the phone needs to be restarted after registering your app in the current Symbian version (see the report). A second small issue is that at the moment the registration doesn’t get fully removed when you uninstall the application again (bug report).
On MeeGo, your app needs to be registered as a service over the D-Bus. To achieve this, two files have to be deployed during installation: a bus configuration file as well as a service file. For the phone to find your app and its icon, the name of the .desktop file has to be %APPNAME%.desktop (and not %APPNAME%_harmattan.desktop, as is the default file name from Qt Creator). As the last step, you have to add a .postinst and a .prerm file to your debian package — these files contain scripts that are executed when the app is installed or removed from the phone and register your app over the D-Bus with the service.
Note: you need to have PR 1.1+ installed on your N9 for autostart to work; the PR 1.0 firmware didn’t handle NFC tags, and consequently also no custom autostarts.
Application Setup
In case your application doesn’t use the registerNdefMessageHandler() method of the QNearFieldManager already, you need to call this method on application startup as well, so that your app registers at runtime to handle the message.
Writing a Custom Record Type to an NFC Tag
If your app doesn’t support writing its own tags, you can use any of the more customizable tag writing apps to create your own custom tags. For example, use the Nfc Interactor to write a "Combination Tag", which consists of a custom record type name that you can define, plus a URL record. Or, use the "Custom Tag" function to only write your custom record type to the tag, without an additional standardized URL record.
NFC Autostart Example Application
If you’d like to see autostart on tag-touch in action, simply install the Nfc Corkboard application (version 1.4.0+). It works on MeeGo and Symbian (don’t forget to restart your Symbian phone after installing the app for the autostart feature to work!) and is started when touching a tag that contains a record with the type name: "urn:nfc:ext:nokia.com:nfccorkboard". The app also supports writing its own autostart tag — just swipe to the Wednesday corkboard, and press the red NFC flag of the yellow note "Corkboards Autostart"
You can also use this app as a reference to add autostart functionality to your own app.
Besides educating Nokia customers of the benefits of NFC technology out of the box, we also ensure that Nokia NFC phone customers can take advantage of a growing number of apps that leverage NFC in an easily accessible way.
The Nokia Store NFC Apps Collection
Instead of customers having to look for different applications where they can put this technology to use, we’ve made the work for them… We are constantly on the lookout in our publishing system for apps utilising NFC and make sure they are all accessible in the Nokia store at an arms lenght – the "NFC Apps" collection. Users can find all the latest and greatest apps using NFC by simply going into the Categories section of their Nokia Store client using their NFC enabled phone, or browse the content from the Store web front.
Incentive for developers
Not only is this good news to consumers, I beleive it’s a really good incentive for developers. The NFC Apps collection gives NFC applications much sought visibility in the storefront, making it more likely for users to discover it.
For Apps to be featured in the NFC Apps collection, publishers need to make sure that our system can identify that the application published is using NFC. To do that they need to include the keyword "NFC" in at least one of the following metadata areas before submitting the Content Item to Nokia Publish Quality Assurance:
As a developer or interested end-user, you often want to take a closer look at the contents of NFC tags. The new Nfc Info app is here to provide the corresponding knowledge, given that you have an NFC capable Symbian (Nokia C7 [Astound], 600, 700, 701) or MeeGo phone (Nokia N9). Simply touch a tag and the app will show you plenty of data about the Nfc tag contents. You will see:
Generic NFC tag information (e.g., NFC Forum Tag Type 1, its UID and version)
The records contained in the NDEF message plus its size (e.g., a custom record + a URL record)
For most standardized records also a nice textual overview of the parsed contents (e.g., URI, title, action for a Smart Poster)
Internally, this is done using convenience classes that hide the complexity and bit/byte-encodings of the records. Luckily, Qt Mobility already provides those for the most common record type definitions (RTD): text and URI. In the Nfc Info source code, you will now find additional ready-made classes that parse Smart Poster, Mime/Image and vCard (for storing business cards) RTDs.
Best of all, you can easily plug those classes into your own project. It’s so simple that I’ve embedded them into the Nfc Corkboard example within a few minutes, so that also that app now handles Smart Posters and business cards.
Usage of the new classes is simple: first, convert the generic record class into the corresponding derived, specialized class. From now on, you have access to methods that return the individual components of the record, or you can assign components for writing.
A short example, which parses a Smart Poster and adds textual information to a string called tagContents:
The features of the new classes — including read and write support for all listed properties:
Smart Poster (urn:nfc:wkt:Sp): Uri, title(s) & their languages, action, size, type and image.
(Note however that most phones currently on the market do not process the last three details listed here in their default phone tag handling UI)
Image (MIME, image/[png,gif,jpg,…]): en/decode all image formats supported by Qt (includes png, gif, jpg) or use raw image data. Automatically sets the correct mime type.
vCard (MIME, text/x-vCard): parse the versit document and get a list of all contained contacts, already provided in a convenient QContact instance. You can query all details through that class, or go ahead and add it to the phone’s address book.
To get started, just download the binary of the example (.sis for Symbian, .deb for MeeGo Harmattan). If you’re using the C7 [Astound], make sure that you update the device firmware to Symbian Anna in order to enable NFC support. You will also need to install Qt Quick Components, Qt 4.7.4 and the Qt Mobility 1.2 package and from the Qt SDK. See the Nfc Info release notes for more details, or read the "Start NFC Development with the Qt SDK today" blog post for full details. If you should be lucky enough to have Symbian Belle on an NFC phone, you only need to install Qt Quick Components from the Qt SDK (the Smart Installer isn’t used in the Nfc Info app at the moment). On the N9, you’re good to go with the standard firmware — everything is in place by default.
With the current Qt SDK (1.2.0 or newer) the scope of Nokia’s NFC developer offering took a significant step forward. It features the final environment for developing NFC apps on Symbian and Harmattan using Qt.
In order to enable you to take full advantage of the Qt / NFC development options, read this small guide that will make your first steps easier. For more information, please also check out the NFC technology pages at Nokia Developer!
Windows, Linux, Mac
You can develop NFC apps for the Nokia N9 with MeeGo Harmattan on all platforms supported by the Qt SDK: Windows, Linux and Mac OS X.
Tools Installation
When you download and install the Qt SDK, ensure the following are selected:
Development Tools -> Symbian Toolchains -> Symbian Anna
Development Tools -> Harmattan
In case you forgot to enable for example the Harmattan package during installation, start the "SDK Maintenance Tool" to download and add these components to your existing Qt SDK installation.
Device Setup
Follow the instructions for all devices you want to enable for working with NFC:
Nokia N9 / MeeGo Harmattan: The device already ships with Qt Mobility 1.2; no installation is needed. The Nokia N950 is running the same MeeGo Harmattan platform, but lacks NFC hardware.
Nokia C7-00 with Symbian^3: NFC hardware comes with every C7 in the market, but you need Symbian Anna to enable NFC functionality. Therefore, make sure you run the "SW update" on the device, or use the Nokia (Ovi) Suite to start the firmware and the following application update! Your device should have software version Symbian Anna / 022.014 or newer (enter *#0000# in the dialer to check).
Nokia C7-00 with Symbian Anna: the device is ready for NFC development using Java ME or Symbian native C++. In order to use Qt for NFC development, you need to update the device environment to the latest version, in case the new Qt versions are not already on your phone:
Nokia 603 / 700 / 701 / C7-00 / 808 PureView with Nokia Belle or newer: if you’re lucky enough to have a NFC capable device with Nokia Belle +, you don’t need to do anything to enable Qt NFC development. Qt 4.7.4+ and Qt Mobility 1.2+ are already pre-installed and work out of the box. Do not overwrite the existing Qt / Qt Mobility installation with files from the Qt SDK that are intended for the Symbian Anna version only!
In addition, make sure you make your phone ready for communication with the Qt Creator IDE and on-device-debugging. This involves installing the "CODA" debug agent on all Symbian devices (no matter which version), or the "SDK Connectivity" tool on the Nokia N9. See the help of Qt Creator for more details.
Development
In general, it is highly recommended to use Qt Quick Components for developing the UI of your NFC application. Qt Quick Components are supported on all NFC capable Symbian and MeeGo phones. More information, for example on NFC availability detection, is available on the NFC technology pages.
Nokia N9 / MeeGo Harmattan: simply select the MeeGo Harmattan target to build and deploy your application to the Nokia N9.
Symbian: select the "Qt 4.7.4 for Symbian Anna" target of Qt Creator to develop your application to any Symbian^3 / Anna / Belle phone.
Note: Qt SDK offers a Symbian Belle specific SDK. The apps developed with the Anna target are also compatible to Belle; you only need the Belle SDK in case you access native Symbian libraries (=> non-Qt) unique to Nokia Belle.
Examples to get started
The best way to get started is reading through the Nokia NFC Development with Qt Mobility presentation. It explains the basics of NFC specifications, how the Qt Mobility APIs provide easy access to the technology and then walks you through two hands-on examples.
The three recommended sample-projects to check — all of them are working on Symbian and on MeeGo Harmattan:
Nfc Info: Shows all information about NFC tags available through Qt Mobility APIs. Includes reusable convenience classes for handling additional record types: Smart Poster, Image and vCard.
Nfc Corkboard: Extends the Qt Quick Corkboards example of the Qt SDK with NFC functionality: touch a tag and its NDEF contents appear as a new note on the screen. Press the NFC flag of a note on the screen and its contents will be written to the tag. Parses URI, text, Smart Poster and vCard records and shows a generic post-it for all other tag types. Includes NDEF autostart support for MeeGo Harmattan PR 1.1+.
Nfc Chat: The Nfc Chat is a sample app that demonstrates how to use the NFC LLCP protocol to create a peer-to-peer connection between two compatible NFC Forum devices and how to send messages between those devices.
Deploying NFC apps to the Nokia store is fully supported on the Nokia Store. For more details on the deployment of NFC applications, make sure to check our NFC developer pages!
Known Limitations
To save you some time, the known limitations at this time:
No raw, tag-specific access on Symbian Anna: this doesn’t mean that the phone cannot interact with specific tags; reading and writing NDEF messages always works fine.
Each tag type platform (e.g., NFC Forum Type 1 Tag Platform) has its own low-level protocol, where you can send commands as byte-arrays, and then parse the byte-array returned from the tag. This raw access does work fine on Symbian Belle, but is unsupported using the current Qt Moblity 1.2.1 version on Symbian Anna.
No raw, tag-specific access on MeeGo Harmattan: as described in the Qt Mobility documentation, tag-type specific access as described above is not supported on MeeGo Harmattan.
Qt Simulator: the simulator has a very powerful editor to create your own NDEF messages and records. You can use it to test your Qt application.
Note that the two-step method of reading messages consisting of listening for targets and then asking the target for its contents does not work as expected. If you use the direct one-step process through QNearFieldManager::registerNdefMessageHandler(), the simulator works fine.
NFC QML Bindings: even though Qt Mobility 1.2 includes QML bindings to make the Qt/C++ NFC-APIs available in the QML environment, it’s recommended to use only the Qt/C++ APIs. The documentation and features supported by the QML bindings are very limited. It’s easy to combine a C++ NFC-handler class with your QML user interface code — all three Qt NFC examples linked above (Nfc Info, etc.) demonstrate how to do this. You can then take the NFC-handling C++ class and simply plug it into any QML project you wish.
Update (22. November 2011): Adapted the article with the latest status following the release of the Qt SDK 1.1.4.
Update (6. March 2012): Added Nokia 808 PureView to compatibility, updated references to Qt SDK 1.2.
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:
There is no working API to set application window orientation. Moreover, the default orientation is landscape! Some interesting details are here.
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:
Call of QGraphicsView::rotate(270) to automatically rotate all items in it.
Change x and y in event handlers code to fix some animation framework staff.
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:
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.
In my previous blog I had introduction to MeeGo 1.2 Harmattan Qt Quick components, in this blog I wrote about porting components to other platforms than MeeGo 1.2 Harmattan and in next one about porting applications to different Qt Quick Components like MeeGo-Ux, Symbian or desktop.
Nokia N9 device will be largest volume MeeGo device in near future and most interesting platform for MeeGo application developers. Portability of Harmattan components is interesting issue for many reasons. N950 developer devices are produced only limited quantity and N900 provides excellent developer platform that is more easily available. Many MeeGo developers would like to see their application to run other MeeGo devices and would like distribute their application for all of them. Harmattan components are licensed as BSD license, so they are free to distribute any platform.
MeeGo 1.2 Qt Quick components are portable code but there is some issues need to taken care when porting them.First one is that components use Qt Quick 1.1 and most platforms like Ubuntu Natty or MeeGo 1.2 still have Qt Quick 1.0. I have made patch set allowing components to run in Qt Quick 1.0. This is problem is just temporary, and vanish soon when MeeGo and Ubuntu upgrade up to date Qt version in next release.
Second issue is theming. MeeGo 1.2 Harmattan SDK comes with Nokia MeeGo 1.2 Harmattan product theme that is same theme used in production device, N9. This theme is Nokia proprietary. It may be used in software development but it can’t be redistributed. When you make applications for N9, this is no problem because theme is factory installed in N9. If you would like distribute your applications to other MeeGo or even non MeeGo devices, you need to use theme that allows redistribution. Standard MeeGo 1.2 uses MeeGoTouch theming that is based on .svg files having multiple graphics elements in one file. Qt Quick uses .png BorderImages. To use components, I have exported graphics elements as .png files and made separate add on package. Now developers have two choices, if they would like just develop for N9, it is recommend to use Nokia “blanco” theme, if intention is to distribute application to other platforms, you should use open theme based on MeeGoTouch “base” theme or other compatible theme.
Third issue is different UX. The UX between MeeGo 1.2 handset, MeeGo 1.2 tablet and MeeGo 1.2 Harmattan. There is a big difference to end user, MeeGo 1.2 Harmattan has magnificent swipe UI where task switching is done by swipe gesture. MeeGo 1.2 handset uses traditional way to have close button in application toolbar and MeeGo 1.2 Tablet uses hardware home key. The great advantage of Harmattan Swipe gesture is that no valuable screen space is wasted for home button and toolbar and there is no device front surface wasted for home button and larger amount of device front surface can be used for display and actual application. My experience of MeeGo tablet is still based on keeping one tablet in my hand 5 minutes. For application code difference is small. In MeeGo 1.2 handset application should initiate itself task switching but minimizing it’s window. In MeeGo 1.2 Harmattan and MeeGo 1.2 tablet, task switching activity is initiated by external process as result of swipe gesture or pressing home button. If we compare to typical desktop applications, application switching, minimizing and closing window is initiated by external window manager application. Close and minimize buttons are in desktop in window frame that is owned by window manager, not by application. Maemo Hildon used same method, tittle bar was owned by system process. In MeeGo, all screen is owned by application and if there are home and close buttons, application should respond to them and initiate action. Other small difference is that in MeeGo 1.2 Handset and MeeGo tablet, toolbar is at top of the window when in Harmattan it is at bottom. At summary differences:
MeeGo 1.2 Harmattan: Toolbar at bottom, no close or home buttons needed
MeeGo 1.2 Handset:Toolbar at top, Home and Close buttons needed
MeeGo 1.2 tablet:Toolbar at top, no Home or Close buttons needed
What that means in practice to application developer ?
You can use Harmattan components to develop applications to all MeeGo devices. With small effort you could adapt your application UI to MeeGo 1.2 handset or MeeGo 1.2 Tablet. At minimum, you need only to add Close and Home buttons to MeeGo 1.2 Handset applications. Your applications would look like more consistent to other system applications when you move toolbar to top of the screen and to redistribute your code for non N9 environment you should use free “base” style.
ToolBar location
In Harmattan UX, the toolbar is located on bottom of screen, in MeeGo handset or MeeGo Tablet, Toolbar is located on top of screen. By default toolbar location is hardwired to bottom in Harmattan components PageStack.qml , I made small experimental patch, adding property toolBarOnTop that defaults as false. Setting this property true, you will have toolbar on familiar place in MeeGo 1.2 handset or tablet. Remember, that property, toolbarOnTop is not standard, do not try use it in Harmattan.
Home and Close buttons
In Qml To have Home and close buttons in your toolbar, you should add them to toolBarLayout. In front page you should have home button in left corner and close button in right corner. In other pages there should be back button in right corner. Qml does not directly support minimize or close, you need to have hooks in your C++ code to server slots. Add following lines to your main QdeclarativeView
Your Main page .qml file could look something like this. In harmattan, you don’t need toolbar in main page at all unless you have menus or some other need for it and you can omit tools: from mainpageComponent. Commontools is commont toolbar definition that is used in all subpages.
PageStackWindow {
id: rootWindow
initialPage: mainpageComponent
toolBarOnTop:true // Experimental non standard property
Most of developers develop applications in desktop first and them move to real device or emulator. Harmattan Qt components work without problems on desktop. It defaults window size as 854×480. To render window correctly in MeeGo 1.2 or Harmattan environment, window must be created as full screen with window.showFullScreen(); in desktop this is annoying of your test application window pops upp full screen 2560×1600 size with small patch of content in middle. In Harmattan components this was resolved just easy way
This works in Nokia devices but is not so nice for x86 based touch screen devices. Some little bit more clever way is needed. I made code so that that it just takes size of screen and it it is smaller or equal 1024×800, assume touch device and use full screen, if it is larger, render into window. I made also patch in mdeclativescreen.cpp so that it uses screen size as default size if running smaller screen than 1024×800.
Here is full main program with handling close and minimize and setting full screen in small displays.
int main(int argc, char **argv)
{
QApplication app(argc, argv);
Release Notes for MeeGo 1.2 Harmattan Qt Quick Components ports
The current base package is qt-components – 1.0~git20110620-7-1fn, it is available now for Ubuntu Natty and MeeGo 1.2 arm and x86 targets. If you would like to use experimental version of MeeGo 1.2 graphics and not Nokia Harmattan product graphics you can down load extra theme graphics , qt-components-base-icons-0.3 . If you are running in non-MeeGo environment you need also to install meegotouchtheme package. If you would like develop for N9 with product graphics, I recommend to use graphics delivered with MeeGo 1.2 Harmattan SDK (QtSDK) or Platform SDK (Scratchbox)
You can get MeeGo 1.2 Harmattan Qt Components port for Ubuntu from Forum Nokia PPA qt-components – 1.0~git20110620-7-1fn
MeeGo arm version is tested on N900 Community Edition, x86 version for tablet is mostly untested, may be just my bad luck setting environment. Qemu image just freezes after few minutes and chroot Image Xephyr died in few seconds…..
At teh moment, code is only in my personal repository but i hope that
we get them soon some more convinient repository. At the moment,
download files and install them with rpm comman.
When we get files to repository, use zypper
Nokia has just released our new great MeeGo 1.2 Harmattan device, N9, it is a developer device N950 and Harmattan SDK beta release. New Qt Quick components library is now part of Harmattan SDK for N9 and N950 devices. When I had my previous blog about Qt Quick components in November 2010, components were just at very early development stage. Nokia moved development as closed in January 2011 because we started to develop them for new great UI concept that you can now see in our N9 and N950 devices.
The new UI concept has only very minor effect to actual application code. Task switching is now done by swipe gesture and no home button is needed any more. Swipe gesture handling is provided by framework and it does not need anything from application side, you just does not need implement “Home” button to return task switcher any more. Because home and close buttons are not needed, you don’t need have toolbar in your page unless it is needed by menus or back button in stacked pages. Toolbar is also moved to lower side of the screen that is more natural place for it when used by finger.
This release of components implements rich set of UI elements and the required part of our N9 UX. Compared to November 2010 release, there is for example full support for dialogs. API has also evolved a lot better since. The good thing is also that now components do not need to be linked into application Qt Code, just use standard QDeclarativeView or you can test your components UI with QmlViewer. New components comes also with new product quality graphics and they are no longer depending in MeeGoTouch framework to serve graphics and styles. Technically, any environment that Run Qt 4.7.4 or newer should be able to run Harmattan Qt Quick Components. Nokia Developer former Forum Nokia will provides a community port of components to Ubuntu Natty, Maemo5, and MeeGo 1.2. New components could be easily adapted for example to MeeGo 1.2 style with just small hack in application.
Our Qt Components are licensed with Open Source license, so you are free to use them in any system. Out product theme that comes with MeeGo 1.2 Harmattan SDK is proprietary but I have made version of MeeGo 1.2 theme that works with MeeGo Harmattan Qt Components. I will provide more information about porting to different platforms and community theme in my upcoming blogs.
Because Nokia was developing new Harmattan UI, we kept development of components closed several months. At same time Intel also did their MeeGo-UX components development closed. For that reason, API’s of these two MeeGo Qt Quick Components are not fully compatible. Situation is still not so bad at all, I will handle more about this UX differences and porting between these different Qt Quick Components and between different UX in my next blog that will be published soon. the porting between toolkits is simple and straightforward, it took just under hour to port my AR-Drone application to use also MeeGo-UX component.
Short introduction to Nokia MeeGo Qt Components
This does not try to be any comprehensive programming guide for MeeGt Qt Components.
At first, set of screenshots from QlmComponentsGallery demonstrating available UI elements. Application works automatically in Portrait and Landscape orientations. You can find general Qt Quick Components API definition from http://bugreports.qt.nokia.com/browse/QTCOMPONENTS-200
Let’s first look our our demo application .
QmlComponentsGallery main page is PageSatckWindow with ToolBarLayout. The Page content is standard Qml LisView element with Elements linking to new PageStack pages.
QmlComponentsGallery Main Page
Buttons
Menu
Sliders
TextFields
Dialog
QueryDialog
DatePicker
Using MeeGo 1.2 Harmattan components
To use components in your application, you need import com.nokia.meego 1.0 and then use PageStackWindow as your main level element. Under Page Stack window you should define your ToolBarLayout what tools you have visible in default toolbar and then put your main page to initialPage. If you don’t have menus in your application, you could omit “toolbar-view-menu” and menu related form toolbar. Notice that in Harmattan you don’t need close or home buttons because they are handled by swipe gesture by window manager. You can either have MainPage as separate Qml file that is then loaded as component or you could just have it included in same main.qml with “component” definition.
Component {
id: mainPage
Page {
tools: commonTools
…. Put Flickable, ListView etc here as body ….. } }
When you would like to open new page, just use pageSatck.push() like here we open from button press new page that is inline component catComponent. Button is standard button component from MeeGo Harmattan Qt Components.
Dialogs are now also supported in components library. You have either standard general purpose Dialog component or specialized variants QueryDialog, SelectionDialog and MultiSelectionDialog. Standard Dialog has three fields: title, content and buttons.
To display this dialog, use myDialog2.open() . Technically you could populate dialog content with Flickable element with a long list of components and use it as same way as dialogs are used in desktop. In Handset environment, if you have a long content, it may be better to use Stacked pages than dialogs and use Dialogs only for shorter content.
Porting to MeeGo 1.2 Harmattan Qt Quick Components
There are not many applications done with November 2010 pre-release of components but many things about porting affect also applications done with other toolkiits like MeeGoTouch.
Main screen has toolbar on top of screen and it had Home and Close buttons. These buttons were required by framework to be able to close application or return to tack switcher.
Same main screen with new components does not need toolbar at all because task switching is done by swiping gesture and also closing is managed by task switcher.
As a small detail, buttons are not in the middle but aligned to top because content pane is a Flickable element. There you could add any amount of content and scroll it by finger.
There is also two buttons to display dialogs. One shows same dialog than originall application as sliding window. Even we have now also support for Dialog objects, least as my opinion this method is better when your dialog has a lot of content. This sliding window has a toolbar because “back” button is needed to return main page. Toolbar is located to bottom of screen as required by MeeGo 1.2 Harmattan style.
There are now native dialogs and they are excellent when you have less content than this application.
Developing with MeeGo 1.2 Harmattan Qt Quick Components
By default, after you have installed QtSDK 1.1.2 with MeeGo 1.2 Harmmattan plugin, you can develop for Harmattan Qt Components either with real N950 developer device or with Qemu Harmattan device emulator. N950 devices are manufactured only very limited quantities and very few developers would have one. If you don’t have actual device, you should use Harmattan System QEMU image. Good thing in Qemu is that it runs same software as device, bad thing is that it does not match in performance with native execution.
For experienced Linux developers we have also Scratchbox based Harmattan platform SDK. With Platform SDK you can compile and run your code in Harmattan software environment compiled as native x86 or ARM code, bad thing in scratchbox is that it is more complicated than Qt SDK and intended only for experienced Linux developers.
After you have installed Qt SDK, If it does not yet have Harmattan target. You should install it using updater. Chose from “Help” menu “Start Updater”. In updater, chose “Package Manager” tab and ten enable “Harmattan” target under “experimental”
Nokia developer, former Forum Nokia is offering three other alternatives. Ubuntu native Harmattan Qt Quick components, MeeGo 1.2 N900DE version of components and Maemo 5 version of components are coming soon. We are also looking MeeGo 1.2 tablet and Macintosh native components. Using development system native components is fastest and easiest way to develop and debug application but it has limitations that there many handset specific API’s are not available. Development system native components is also easiest way to study and evaluate MeeGo 1.2 Harmattan Qt Quick components.
Installing Nokia Developers Community port MeeGo 1.2 Harmattan Qt Quick Components
Harmattan components require Qt Quick 1.1 but MeeGo1.2, Ubuntu and
Maemo5 has support only Qt Quick1.0 . For Qt Quick 1.0 Components
sources needs some patches to make work, I made patched set that would be available for Ubuntu from our FN PPA. For N900DE you will have qt-components.rpm package that will be released soon.
FN PPA will have soon ready made debian package for Ubuntu Natty, just ad ppa
To run Harmattan components applications, you need also theme graphics. Our Harmattan SDK has graphics included. The graphics are Nokia proprietary, so you are not allowed to redistribute them. For that that reason, we are not including packages to our PPA or MeeGo repositories. For debian based Ubuntu or Maemo 5, you could just copy meegotouchtheme.nokia-graphics.deb and meegotouchtheme-nokia-icons.deb and install them with dpkg -i command.
If you can’t use these debian files, you can use scp -r or cp -r to copy files from your SDK to your host. Files should be /usr/share/themes/meego/blanco directory tree from SDK to your target system. Under scratchbox it is located in /scratchbox/users/<your_user_name>/targets/HARMATTAN_X86/usr/share/themes
In your QtSDK they are located at QtSDK/Madde/sysroots/harmattan-arm-sysroot/usr/share/themes/
We are working for open freely redistributable graphics for Qt Quick COmponents based on N900DE "base" theme. I am hoping that we could make this available soon.
Main view with live feed from AR-Drone camera and telemetry
Here is a little hcking project that I am releasing just before Christmas, it is something fun to play around, something that really moves and makes also non-hackers exited. It also allows to you use own imagination to enhance this base application to be even more fun. Least to me, Christmas has been always time to build something that is fun,like all kind on flying gadgets. I still like playing with everything that flies, some ones where I can sit myself in pilot seat and someone that I can control remotely.
I decided to combine work and fun and also offer a super-cool possibility to learn MeeGo and Qt Quick with having fun, just go shop and buy AR-Drone 299$ and download code from http://mardrone.garage.maemo.org and have happy hacking.
After Nokia announcement focus Qt and Qt Quick and after my previous blog howto make modern mobile applications with qt quick components there has been a lot of need for some real life full show case applications how to do UI with Qml and how to use existing C++ application logic. We have also here in Nokia term “dogfooding”, we should eat own dog food that we make. In his Qt Quick / Qt Components in the case I should say that it’s the best dog food I have ever had.
Other goal for this application has been show, how easy is to make MeeGo versions of iPhone applications. Original Ar-Drone FreeFlight application was made for iPhone. Making Qt Quick UI for this application takes just day or two. Current UI still looks like engineer’s tool, because it is made by an engineer. To make it really good looking needs touch of UI designer and great graphics but no SDK can solve this problem even it is iPhone, Android or MeeGo. Integrating C++ code to Qml took less than days work. The more detailed anatomy of this application is coming on second part, next blog entry.
There has been also criticism and rumors that Nokia would be killing Maemo and no-one should any more develop for Maemo. I would like to prove all these rumors to be wrong. The best option today is to develop with maemo5 with Qt and Qt Quick and when a MeeGo handset is released, just deploy your application for it, it is that easy.
You should remember that our Harmattan project started as called Maemo6 but after merging to Intel Moblin it became MeeGo. Maemo and Moblin already had common roots and result of this merge was not incompatible what Maemo6 was. I have compiled and run this same application without changing a single line of code in both N900 with Maemo5, our future MeeGo based device and Ubuntu Lucid in desktop. Your application will run on all platforms unless you intentionally chose some obsoleted API’s like GTK+ based Hildon. For someone that does not like EOL of some old API’s I recommend reading my previous blog entry, we just needed to renew our UI technology to be competitive and as application developers you should be happy that we can provide now best application development platform where your imagination is only limit in UI creation.
AR-Drone and application
Technologies, that I use in this AR-Drone application are: All QI Is Implemented with Qt Quick QML Language and MeeGo Qt Quick Components with addition of some my own QML and C++ components. I have integrated to the UI seamlessly some my existing Qt GraphicsView code as custom component and existing C-code, AR-Drone video codec used in iPhone and in their GTK+ demo application. All application logic is coded with Qt / C++ . Application uses real time and performance critical things like live video feed from drone camera, real time telemetry data from drone and augmentation of video with realtime HUD display.
What is then the AR-Drone ? AR-Drone is quatrocopter, Vertical Take off and Landing ( VTOL) aircraft, rotorcraft like helicopter. Quadrocopters are not so efficient for cross country flying they are very simple to construct with electric motors and due simplicity they are very crash proof and durable. With implementing artificial stabilization with software and sensors they can be made very easy to fly and handle. Typical RC-helicopter may need dozens of hours, many dozens of crashes, disappointments, lot of glue and hundreds of euros. As opposite, AR Drone, you just press fly button and it starts hover about one meter over ground and then you can start moving it.
Technically AR-Drone is much more advanced than standard RC-aircrafts. It has 32 Bit ARM processor running Linux, it is controlled over WLAN and it has bi-directional data stream transmitting back both telemetry data and live video feed from two cameras on drone. For flight control AR-Drone does have 3 axis MEMS Gyro ( angular speed sensor) and linear acceleration sensor, ultrasound for measuring altitude and bottom facing camera for position holding.
AR Stands for augmented reality and it’s manufacturer, Parrot calls it as flying video game. You can implement as example air fight between two drones by detecting others color tags from video and augmenting video image with ammunition trails or misles. I my application I did not yet try to make this kind of game but i have already augmenting layer implementing HUD ( Heads Up Diaplay) , similar than fighter planes have showing flight instruments over pilot’s vision.
This is not a sponsored add, i just bough my AR-Drone from Sunnyvale Bookstone shop with $299.
Basic structure of application
The main program is very simple, it just registers my three C++ classes to Qml and then creates QdeclatariveView with my main Qml file, ardrone.qml. For easier application packing, it uses Qt resources to keep qml files, so no extra files is needed to install with application. The ardrone.qml then imports my “drone” classes with import Drone 1.0 .
Main class is called by DroneControl, it does not have any visible representation to Qml, it’s purpose is to implement actual application logic and expose it’s interface to QML. DroneControl creates instance of DroneThread that handles real time control and telemetry connection with drone. DroneControl class also implements interface to QSettings for application settings storage.
DroneControl also implements command protocol and telemetry data parsing. They are implemented from scratch with Qt, i had option to use also AR-Drone SDK VP_LIB library functions but they had so heavy dependencies that i did not like and the command protocol was so simple that i decided that it is easier just do own implementation with Qt/C++
As addition to main Logic, I created class DroneVideo derived from QGraphicsWidget . For Qt C++ view it is just like any other QGraphicsWidget derived class that can be used to Qt QGraphicsView applications. It did not need any modifications to be used as component from QML. Standard QGraphicsWidget properties like position, size etc are already automatically exposed to QML. That means that you can use your QGraphicsWidget or QGraphicsItem derived classes in many cases without any modifications from QML. The DroneVideo implements video streaming functionality via separate VideoThread. It was easiest way to implement this application and re-use codec from AR-Drone SDK. In future more elegant solution would be to implement codec as Gstreamer module. The DroneVideo is not yet optimized at all, in future I should also consider implementing YUV-RGB conversion and scaling with GPU OpenGL-ES2 and shader code. Performance currently in N900 is fair but even this implementation gives relativelly good performance in MeeGo device.
Third C++ class I used, was also re-use from my previous Qt QGraphicsView based application implementing HUD, Heads Up display, artificial horizon with declination and inclination indicators. It was mostly as it is, but just non-standard properties exposed to QML with Q_PROPERTY declaration. HUD is drawn as overlay over video picture. If yoy would like to add some augmented reality stuff like gunfire, missles etc, just replace HUD drawing code with it. You could also use Qt OpenGL-ES2 if you need more compled Augmented reality.
The actual UI is implemented with Qt Quick and Qt Quick MeeGo Components. The main QML UI file is under 200 lines of code, specifying layout of main screen of application and binding UI element properties to C++ class variables. Main page is mostly custom UI in full screen mode, more like games are but it uses MeeGo Qt Components framework and some items like Button and Text there. Joysticks are implemented as my own QML components. If you need some custom UI component, in many cases you can do it with 10..50 lines of QML. The settings page is implemented as separate page less than 200 lines. For easy application deployment, all qml files are included to executable code as resources, so no extra directory is needed for them.
Building application
To build application, you need to have Qt 4.7 and Qt Quick components installed. You can read from howto make modern mobile applications with qt quick components how to install them for both Ubuntu and Maemo5 Scratchbox development environment. You don’t need to use Qt Creator but if you would like to use it, you can read it from qt creator and scratchbox .
To addition, you need AR-Drone SDK that contains video codec library for AR-Drone from https://projects.ardrone.org/
You need to apply patch ARDroneLib.patch from mardrone to compile AR-Drone libraries under scratchbox for Maemo/MeeGo target and to expose couple of previously static functions to application. The AR-Drone SDK were unaware that you could compile for ARM target under Linux that looks a like “native” ARM that does not look as embedded linux.
If you would like to build test version of this application for both desktop and Maemo/MeeGo target
and do it automatically from Qt Creator from same source directory, extract your AR-Drone SDK for both your Ubuntu host and scratchbox under your home directory. They are in real life different directories and so you can have x86 in host and ARM under your scratchbox. To build, execute under your host and scratchbox both
cd ARDrone_SDK_1_5_Version_20101004/ARDroneLib/Soft/Build/
make
To build actual application, you can either just open ardrone1.pro file with your Qt Creator and
press run, it should compile it with your host Qt4.7 . Compiling under scratchbox from Qt creator, please refer previous blog. Or you can just compile it from command line
qmake
make
If you would like to make installable debian package:
fakeroot dpkg-buildpackage -b
And you should have ready made application to run. If you have installed it from debian package, you will have ready icon. If you would like to run it fron command line, In current pre-alpha N900 Qt Quick components MeeGoTouch style libraries there is bug that you should start your application with
mardrone -graphicsystem native
That is slower than opengl but with opengl render you got all components as red background.
Using using application with AR-Drone
WARNING this application is at the moment early alpha level, version 0.1. It is intended to be used as technology demo and suitable only hackers that can read, understand and fix the code. There are still unknown bugs and unimplemented features like acceleration sensor, joystick, better UI style etc. Don’t try this unless you know what you are doing.
When you have your drone, i recommend to first test flight in place where you have free space around but not in windy weather. Best place is big empty room like garage etc. The drone should auto-hover after takeoff and it if crash resistant, so it should not get easily broken if you collide walls etc but try avoid it.
First step, you should connect your device to AR-Drone Ad-Hoc WiFi network. After powering up your drone., you should see network named ardrone_xxxxxx, connect to that one. It should assign IP 192.168.1.2 to your device and drone will be 192.168.1.1 .
The next step is to start mardrone application. It takes little moment and you should see application main window. If the connection to drone is successful, you should see video feed from drone camera. If you see gray background with X, over it, there is no video feed and no connection to drone.
By default you should also see two lines of green text over joysticks. They are debug status from drone. If there is something wrong in your drone, you should see message there. As example, if you carry it by hand, it may have too high angle and you get message there. You can reset status by pressing emergency twice.
To fly the drone, press “fly” button on bottom of the screen. The drone should take off and hover about one meter over ground. It should not move to any direction without you controlling it with joysticks in left and right side of screen. Try first right joystick, it moves drone up, down and turn around. When you are familiar controlling, try right one, it makes drone to fly forward, backward, left and right. Be careful, with full deflection drone flies fast and may collide something.
At 
considered as real check-ins as the user had to physically be there to check-in, giving venue owners the potential to have much more accurate data versus normal check-ins. We have demonstrated this concept as verified check-ins at Nokia World 2011 (
Besides educating Nokia customers of the benefits of NFC technology out of the box, we also ensure that Nokia NFC phone customers can take advantage of a growing number of apps that leverage NFC in an easily accessible way.
With the current 
