Ambience Store for Jolla.

Ambience store menu

One of the things that keeps me busy and excited for years is creating and shipping products related to mobiles and mobile apps. I was making tools for it, coding and managing mobile apps (the top one has hundreds of thousands of downloads, hopefully some official milestone news will be published soon). Coding mobile apps in Qt/QML is also one of my hobbies (at the moment Jolla Sailfish OS is the best platform for it though coming Ubuntu phones might be able to change it), I have created a number of popular apps for Jolla, yet.. the lack of even minimal commercial ecosystem for 3rd parties was always a pity for me.

Can paid apps harm the app ecosystem?

I can understand why Jolla as a company isn’t so much keen on introducing paid apps too soon (to my memory introducing paid apps in 2014 is actually the only Jolla’s semi-public target that was not met). You know even if you assume that there are some 80K Jolla users (very generous assumption as for me) and even 10% of them decide to pay for a super useful app some 5 euros out of which Jolla will take just 30% for processing (again impossibly generous assumptions), that would make 80K * 10% * 5 * 70% = 28K euros. Not per month, but per app life. For one super useful app that probably took months to develop. Real monthly numbers for the few top tier apps would probably be around a couple of hundreds max and just dozens of euros a month for the 2nd tier apps. That’s not much of a monetary carrot and without extra support by some developer program (that might be coming) monetary motivation isn’t likely to justify spending time on Jolla even for your girlfriend, wife or husband.

Paid content and services over the paid apps

What if there was some other area where you could do something really cool and welcome for Jolla, spend less effort on it, do it in such a way that it could be reusable on other platforms as well and earn even more money with it? Well, despite all the buzz mobile apps bring only a tiny slice of the mobile data revenue. Majority of money comes from messaging and various types of value adding services such as videos, ringtones, wallpapers. Mobile revenue distribution

Customizing the device

I played with the idea of customizing home screen both automatically and manually. My Daily Wallpaper for Nokia N9 enjoyed dozens of thousands of downloads while being a free app (quite a number for the tiny number of N9 sales) and hundreds of purchases when switched to the paid mode. Daily Ambience Beta for Jolla also generated quite a bit of interest and there are already Jolla fans who exchange ambiences via Dropbox, FTP servers and sharing websites just for the fun of seeing the other people excited by the art of yours.

Ambience Store

Meet the new project: Ambience Store. It is going to be just a.. well, an ambience store, limited to just wallpapers for start where you can look for the new, most popular and fun ambiences and get them for free or purchase some. Artists will get a platform for sharing the art with the world and for getting a bit of money for it too.

The project is in its infancy for now, there is only an Alpha version of the client app, pretty much for just gauging the interest and a single page website for the same. As I believe doing something like Ambience Store is what’s quite appropriate for Jolla company itself, I am trying not to devote too much effort on it before figuring that in-app purchases are indeed likely to be possible and Jolla company isn’t likely to release an own ambience store two days after this one is launched. Yet I still love the idea so some progress is likely to happen anyway.

If you find the project interesting and would like to support it, the best thing you could besides subscribing to updates do is to ask Jolla’s marketing-business side to talk about a possible collaboration or to go and vote for the in-app purchases on Jolla Together. If you feel really generous, you can also vote for these more technical items that will make Ambience Store happen easier and better.

What do you think?

Do you find the idea useful? Does it make sense to do the Ambience Store as a 3rd party service? Would you use it yourself as an artist or as just somebody who like trying new interesting ambiences?

Life after Jolla. Android and iOS

My day job title is Head of Mobile development. Understanding mobile OS and their standards is both my long-term hobby and work. I have created a number of apps that were always best sellers in the relevant categories (not on the nowadays popular platforms though). Right now the app of my day job company designed and managed nearly solely by me and done by talented developers are a huge success in the education market and enjoys thousands of daily users. I am possibly the Jolla Sailfish developer enjoying the biggest number of app downloads/likes ever (definitely in the top three) and I had one of the apps up and running in on the very first day Jolla phone was in sales.

Part of what I do regularly is using phones with the different platforms as the primary ones to understand what different smartphone users are like, to get new ideas and just for fun. I am trying low-end ones, hi-end ones, Symbian, MeeGo, different versions of Android and iOS, BlackBerry 10, even Windows Phone sometimes (not the Firefox OS yet). Last year I had spent some 7-9 months with Jolla, then a couple of months with iOS7 and then a couple of months with Android 4.4, I am on Windows Phone 8.1 right now, BB10.2 I have tried a year earlier, will have a look at 10.3 later.

So since I use different platforms as a primary device regularly and try paying attention exactly to the apps UIs, I thought it could be of interest for some to see what’s the difference in the experience between the different platforms is. Note that I am one of those who use smartphone a lot: browser, Foursquare, Twitter, Facebook, lots of other services – it’s all me. If you are just using phone for just calls and few messages once in a while, this post might not be of that much value for you.

What’s really great on Sailfish that I miss on other platforms

1. Swiping the app off. And swiping it off half-way


Amazingly easy and natural way for getting the current app off the way is the definitive part of Sailfish experience to me. And the ability to just half-swipe the app off for taking a peek at the clock looks cool and feels like you are playing with the phone. In theory you can also use this half-swiping gesture for having a look at the other apps’ cover cards, but I’ve never found anything really useful to look at this way.

2. Task switching / multi tasking. Fast and fluid, beats iOS and Android hands down

Contrary to some opinions iOS and Android are actually multitasking operating systems nowadays and you can do several things nearly simultaneously there, but Jolla Sailfish shines in how quickly you can switch between the apps.

Swiping app off and switching to another one is simply faster than on iOS and Android and doesn’t require any button presses. The only platform I know that is even faster is BlackBerry 10: It is also based on a single gesture, but BlackBerry designers went an extra mile and made it work precisely everywhere. You use absolutely same bottom-up gesture to get to task manager screen from anywhere even if you are already in the task manager or even if you are on a lock screen (same gesture unlocks the device). As a result, whenever you are feeling a tiny bit lost a simple flick gets you to the same familiar safe with zero thinking involved. Taking into account the BlackBerry market share it is not that important benchmark for Jolla world though.


Sailfish task switching beats iOS and Android in speed and doesn’t work only in few places: app launcher, when you are in task manager already and when you are on the lock screen – a bit of need to make you mind notice such situations, but not much.

Step by step iOS and Android try to get to the same fluidness and getting rid of hardware button presses via the interactive notifications, but it can’t cover all the cases just yet.

3. Awesome WhatsApp client Mitäkuuluu (dead by now, but with a chance of rebirth)

Mitakuuluu wide
This is one amazing app that truly made Jolla shine. Simple, easy, yet powerful and looking great. Unfortunately right now it’s dead for the reasons I don’t fully understand. I thought WhatsApp killed the client for the sole fact that it’s a third party client, but I have also heard some rumors about a possible rebirth.

It is quite a surprise for me that Jolla still isn’t employing the app’s author Coderus despite his explicit wishes to join the company. Well, they might have some reasons.

4. General feeling of half-way-executed action smoothness

It might be silly, but I really like how most of actions performed with swipes in Sailfish you can half-do and then change your mind and cancel. Switching app tabs, Applying settings, even pulling the menu and moving it back. Sometimes there is a bit of use in this half-doneness (you can preview the result of completing the action), sometimes it is just a funny thing to play with.

5. Ambiances

That is one amazing area of Jolla that I didn’t expect to be useful and that has suddenly become a part of what I am using regularly. It’s just so much fun to recolor the phone UI completely once in a while. Unfortunately the current implementation tends to loose my ambiences once in a while (possibly when SD card fails to report to OS on time), but that will be fixed at some point. BTW, have a look at the My Ambiences Beta app that lets you choose a random photo as a base of the phone ambience. In some future point it might do it automatically a couple of times a day and could apply filtering not to select not very appropriate random photos.

What’s not so good and much easier on other platforms

0. Browser


Update: This section was written before the Christmas 2014 firmware update. It improved browser a lot. It is still slower than competitors and eats RAM, but the difference is not that daunting anymore. The only real complains remaining are:

  • very non-standard UI, but you can get used to it
  • no ability to have increased font size on quite a high DPI screen
  • no way to position cursor in the input fields precisely. Jolla’s standard methods do not work there

Tough to read small font
Sorry, Jolla, the current browser sucks and sucks big time. You can get used to the.. non-traditional UI that is quite different not just from other operating systems, but even from the other Jolla apps (e.g. it’s the *only* Jolla’s app with a bottom toolbar), but the fact that the browser is slow, freezes the pages quite often doesn’t render all the sites well and tends to use tiny fonts with no opportunity to force larger ones (unless you are into increasing the font size in the whole system), that’s all real bad. For most of the web sites it is bearable, but that’s it, it pales in comparison to Android’s Chrome and iOS’es Safari Mobile.

I find third party WebCat browser based on WebKit (unlike the system one based on Mozilla’s Gecko engine) somewhat better and noticeably faster, but there is still a way to go.

Interestingly it doesn’t seem to be a problem of small amount of RAM and slow CPU. Google’s Chrome browser that you can run on the same Jolla phone behaves noticeably faster, but then you run into lack of RAM quite easily.

1. Number of apps and poor Android support

There simply aren’t many native apps yet, there is no Instagram, Facebook client called Friends is not bad, but still has a long way to go (not much groups/events support yet for example, you cannot open some photos, etc). In fact it is quite difficult to build good native apps, because of the significantly different development process (Sailfish projects use very own project structure), solutions discouraging cross-platformness (e.g. deployment specifics often require you to make modifications to the other guys plugins source code) and very limited set of APIs officially approved (e.g. forget about anything involving Location or Contacts).

Friends cannot open a photo

Android support is still quite poor, many apps need quite a bit of RAM (and get shut down when they can’t have it that kills the whole idea of multitasking), Sailfish keyboard doesn’t work super-well there and quite often I had to reboot just to make keyboard work again, there is no Google services support (for a good reason, but still) and amount of RAM on the device doesn’t really let you run many apps.

Android support is said to be also improved in Update 10, so possibly Android apps are now easier with the RAM available.

2. Keyboard

Jolla’s keyboard is not bad. In fact it is quite okay. It is a little painful for me to use with a single hand (can’t reach corners easily), but it’s more about the size of my hand and Jolla phone. What is missing is well working prediction experience: I make several times more typos on Jolla than on iOS and Android and way more typos slip into the text messages sent. It might be just about autocorrection suggestions not applied, well, automatically,


3. Inter-app interoperability.

Yes, Sailfish way of multitasking has real good and bad sides
Switching between running apps is fast and fluid in Sailfish, but there is a number of negative sides as well:

3.1 Information exchange between apps is almost non-existent

You can send a gallery image to a built-in Facebook/Twitter sharing plugin, but that’s pretty much it. Forget about Android/iOS-style sharing sheets where you can send pages to GetPocket, Evernote, Translation app, wherever else, there is no way to choose a default handler for URLs, voice calls, text messages.

Android sharing

3.2 Lack of privacy control and apps operating with private stuff

Android has pretty rough permission model when you have to agree to many permissions already during the app installation (recall a taxi ordering app that wants to know your SMS messages and list of contacts), iOS is more intelligent in this regard and lets you accept or reject access to, for example, contacts when the app tries accessing it for the very first time and good apps warn you in advance about what they are going to request and why.
Sailfish’es current answer to this: we just do not let any apps use the contacts database. Fortunately according to Jolla CEO plans for 2015 things are likely to improve in this regard, no precise plans known yet though.

3.3 Apps running in background and starting on some events

Think of automatic photo uploads to Dropbox when you enter the home WiFi area. Not in Sailfish for now.

4. Single save-me-to-home gesture

That might be just me, especially since I do use many mobile OSes quite often, but I find it real important for a mobile OS to have a simple constant way to get me to a known “home” place. On iOS on Android it is the Home button.

On Jolla a swipe to the side gesture is taking you to the task manager from everywhere… except from the app launcher pages.
It might be silly, but for me the lack of a simple fitting to muscle memory way of getting to Home is quite important for the day to day use. Especially when I am in the middle of my 7 page long list of apps – takes me several swipes to get back to the task manager.

6. Simple way to organize music and photos

iOS approach with everything going through iTunes is limiting, but having just one way sure makes it easy to remember. Android doesn’t have a standard way for music/photo management (Google Music and Google Photos try making all go through the Google cloud, but it hasn’t happened in full just yet), Jolla doesn’t have one too. You can move your music to the Jolla’s SD card, but music playlist and photo album management.. I haven’t found any way to work with on the desktop these except for manually editing the text files on the mounted phone disk.

7. Size and position of the keyboard

It might be just me, but somehow my fingers find it much easier to reach on-screen keyboard keys on most phones than on Jolla (and I was using something like 6-9 different phones over the last couple of years). It could be about bigger than usual bevel around the screen on the bottom, or maybe the other platforms help my mishits with the better autocorrection kicking in.

8. Confusion in menus, order of options

It is pretty hard to get confused in most of iOS apps. They’ve got two-three options in the main toolbar (most important one always on the right), maybe a couple of buttons in the main screen area and that’s it, scrolling to the top of the list is always same ta in the same screen area. Android’s action bar is also always located in the same area with the most important action always on the left. Jolla.. after several months after developing for the platform I am still not sure if the most important action in the Pulley menu should be on the top or on the bottom; app’s tab switch: should it go via the pulley menu or the left-right swipe way (and what’s the difference from back swipe and previous-tab swipe then?). Bottom pulley menu and sidebar drawers: when shall these be used and when not?

Sailfish OS UI is still young, lets you use many new interaction types and while it possibly lets the creators be as creative as they can, it doesn’t help the users much if he has to learn every app’s interaction models separately.

Easy and low hanging fruits for increasing Jolla satisfaction a lot

1. Offline maps and navigation.

Okay, it is easier to say than to do, but it is not a technical trouble. Ideal way of using maps on the trip would be similar to Here maps: Plan trip on the web interface, see it automatically synchronized to the phone, navigate offline.

2. Fix the freaking save-me-to-home gesture

Find some way to make the same get-me-home gesture it work exactly always, I do not want to spend a single bit of cognitive activity during the task switching, mind is to be 100% on the previous and next tasks.

4. Improve the keyboard

Maybe just enabling autocorrection by default could be good enough to reduce the amount of typos significantly.

5. Get the UI guidelines in place

Okay, I am an app consistency freak, but I find the need for the common app guidelines so welcome, that I would even prefer mediocre guidelines than to zero guidelines. It could be related to the daunting number of apps I use daily and to my zero will to have to recall the details of each app’s interaction model. Jolla with its typical errors list is already half-way there. Just complete the list and transform it from “here’s what you probably did wrong” to “here’s how you should do it way”.

Not so easy ways for improving Sailfish

That would be a topic for some more posts 🙂
Things I could hope for would be to encourage developers or spend own staff time in the several most important app areas (e.g. incentivize Facebook client development or add a half-time Jolla developer to it). Implementing some sort of a common BB10-like chat hub could also be very useful while relatively easy given Jolla’s universal messaging accounts.

What do you think? What things in your opinion make Jolla Sailfish OS really stand out above the other platforms and what makes you still look for iOS and Android? Any easy improvements you could think of that could improve the Sailfish VS others comparison a lot?

I had my troubles with Jolla (slowness, not picking up calls), but there were times when it behave as advertised, so this comparison assumes things are fine. As you will see many positive things are the other side of negatives of course.

Cute Contacts for iOS – video demo

Some time ago I have started Cute Contacts a project for studying how well QML as of Qt 5.3 is fit for prototyping iOS app. By now the project is done enough to see how fit things are. On the way I have found a few bugs, found some generic inconveniences and learned a lot.

I will probably post more on the findings, possibly it could help Qt project folks to save some time when developing Qt Quick controls for iOS. For now, just have a look at the video. For more details watch the project page or subscribe to this blog RSS feed.

And sure feel free to grab the code on Github and study it or do with it whatever you like.

CuteContacts-iOS7: Cloning iOS7 Contacts application UI in Qt/QML

As you might know I am interested in figuring out the ways for making native or almost native looking apps for iOS and Android with Qt/QML.

So I have started a project on GitHub for trying one of the ways. CuteContacts-iOS is an attempt to use customized QtQuick Controls for cloning the iOS7 standard Contacts app UI. It is not intended to be a real final application, nor a guidebook for correct coding. It is a proof of concept for the UI level only.

Pasted Image 5 16 14 0 01


If the projects succeeds in full, it might evolve into a library of controls or framework, but that’s a secondary goal. Primary goals are:

  • To go the edge of what’s possible in looking iOS7 native and to have a working native or almost native looking demo.
  • Evaluate possibility for prototyping iOS7 apps in QML. QML is extremely powerful tool for super-fast UI prototyping, but if 90% of time will be taken by recreating basic controls experience..
  • To identify impossible or particularly difficult UI bits and draw Qt Project team attention to these

How you can help

Well, just join the project and submit pull requests. Most of all it would be great to have some UI-aware mind helping. I have fun solving the principal issues and figuring out the ways for cloning UI and animations precisely, but I have problems with understanding what exactly it should be like: exact color values, exact sizes in pixels and so forth. And most of graphics I just cut out of the popular iOS mockup template Getting advice and contribution in all things UI would be very welcome. Coding contributions would be great too naturally.

Principal difficulties I have uncovered by now

The project is just starting and many discoveries are ahead, but a couple of issues I don’t have easy answers for are uncovered already.

Unpaintable “under status bar area”

Some iOS7 animations such as opening a Search box editor in the title bar require animating and painting under the status bar (area with the phone signal). There is no way to do it in pure QML as this area is either beyond the QML control completely or we have to take the whole screen and somehow paint status bar ourselves. Has anybody got an idea on how to ask iOS paint it’s standard status bar over the QML canvas

Color of the blinking cursor in the text editor

There seems to be no QML way to control it. Do you know how to adjust it from C++?


Your opinion

What do you think? Does the project make sense to you? Would you contribute and how to make it easier for you to do so?

Qt on iOS and Android. Looking native today. Or maybe tomorrow

That’s a long post about what could be the ways for making a native looking and feeling, and behaving Qt app for iOS and Android, so here’s a table of contents:

Qt and mobile apps

Coming from strong Nokia background I like Qt and mobiles. I used to be a Forum Nokia Champion, Qt Ambassador, created a number of Qt/QML apps for Nokia N9 and Symbian, possibly created the first ever 3rd party app available from MeeGo, Symbian and Android app stores and built from the same source code. Nowadays I am spitting out Jolla Sailfish apps (including the app more popular than the system Clock app) with the machine gun speed just because I love to see power of Qt and QML come to action on the fully-Qt device.

I am also a UI standards maniac (not necessarily a succeeding one) and it drives me crazy that I cannot use my favorite Qt and QML for building mobile apps for mass market (read: Android and iOS), now that it is technically possible, but in practice only low level graphics examples exist and nobody seems to care much about native or native-looking toolbars, gestures, sharing dialogs, integrating to notification services, you name it.

Right now I am flying for a New York reunion of my day job company (BTW, have a look at pretty cool interactive images service we make, sure we have mobile apps for creating these on the go too) and drafting this post for outlining a set of experiments to proof or decline the ability to create native-looking iOS and Android apps already today or tomorrow. I will probably try implementing a couple of these and some will be beyond my skills. So if you are into the same stuff, grab a topic, do an example on github and post it to comments, I’ll add it to the post.

What’s needed for app to be native-enough

So what’s needed for an app to be native enough. Two things: native look&feel and integration to the system services.

Native look and feel

Buttons, toolbars, gestures (e.g. iOS 7 Back gesture), native text input, view transitions, theming according to the current device theming. Sure it’s better for these to be fully native, but looking at what modern mobile HTML5 app frameworks are able to achieve, I think it’s okay at least for now if your app will look almost native. For example, if you implement view transitions yourself so that they look almost native and make buttons that look like the default phone theme only, I won’t be ashamed for shipping such an app to app store. As a rule of thumb: if you would feel okay showing the next Instagram-Twitter-Foursquare app done this way to potential investors, I’d say UI is looking native enough.

Integration to the system services

There are non-visual or partially non-visual services that user got to expect from the native apps nowadays (and not immediately supported by Qt). Two prime examples are system sharing sheets and system accounts integration (logging in/signing up with Facebook, Twitter, Google+). As the secondary examples I would add being on the receiving side of the sharing interaction and working in the background when started by the system notifications service or just because your app is registered for the background execution. Sure you could add many more examples, but if the ones above are covered, everything else should be doable to and you will probably be able to modify the existing proof-of-concept demos for it.

What’s possible for making the native-enough app

Native look and feel

There is a number of approaches available:

Plain Qt Quick

Plain Qt Quick

You get a rectangle and you draw there whatever you like. That is the way the current most cool mobile Qt demos are made, performance seems to be good enough for cool effects and fast animation on all the relatively modern devices. That could be a good approach for creating a cross-platform mobile game nowadays where you anyway are likely to have non-system looking controls and not much system interaction.. except for in-app purchases.

  • Pros: You can use power of the full Qt and QML, manipulate your C++ objects and QML and create whichever effects you want easily
  • Cons: If you are not creating just a demo game, cloning system toolbars and view transitions could be a daunting and boring task. Possibly an easy one, possibly a complex one

Qt Quick Controls

Qt quick controls

That is the primary way forward for Qt for Android. There is an effort led by Bogdan Vatra for making existing Qt Quick controls look real native and even fetching colors and font sizes from the system theme. The problem is that most of these goodies are [probably] coming in the end of 2014 the earliest and are for Android only anyway. Meanwhile you can grab the current, quite desktop-looking controls and with a bit of hammer and swearing make them look good enough for you. There is even a couple of open source projects aimed at it.

  • Pros: Full Qt/QML power is still here, you will definitely find at least PageStack and Page elements useful, possibly some controls won’t look that bad.
  • Cons: You won’t get theming for free, possibly making even semi-okay looking controls will be difficult, native looking transitions and gestures will also be on you

HTML5 with C++ interfaces

HTML with large QML part

Qt 5.2 SDK already includes an HTML5 app template and, well, it is pretty much just a Webkit view with HTML inside, so you can use some modern mobile app frameworks for the native-looking buttons and toolbars. Advantage you get from using these frameworks in the HTML only mode is [potentially] easy integration to the C++ side on your code. I think you could access C++ side objects injected to HTML or made accessible by it (e.g. Settings or file system or your proven network comms engine). And/or you can go the other way around and modify web page DOM elements from C++.

  • Pros: Native-enough look nearly for free. You can still use your Qt libraries and shift much of the complexity to the Qt side
  • Cons: No QML, Qt-HTML integrations could be difficult and unusual (e.g. could signals and slots be used anyhow?), no good debugging and profiling tools

HTML5 with the large part painted in Qt/QML

HTML with large QML part

A variation of the above for the apps centered around large main controls such as lists, map of the local restaurants or a painting board. It is likely to be possible to paint these using Qt/QML though performance and ease of debugging of such an option are to be studied yet. Controling lifetime of such objects could also be tough.

  • Pros: You get native enough-looking controls nearly for free while using Qt/QML exactly where it matters most and where you want to polish the UI.
  • Cons: Debugging and optimization could be difficult, running two JavaScript interpreters and passing data/signals back and forth through several layers (or some side bus) could be challenging

HTML5 inside QML

HTML5 inside QML

That is sort of a reverse approach. You can have a QML app that devotes 100% of it’s space to a web view or you can even have a non-visual QML component running side by side with the web view instantiated the C++ way. Then you can paint 100% of UI using HTML5 UI frameworks while having app logic in QML. If you go one step further, you can even create a whole presentation layer in QML that just maps itself into as lightweight as possible HTML5 UI.

  • Pros: Native enough-looking controls from HTML5, all the logic in Qt/QML, property bindings included
  • Cons: It could be tough to establish one-two one mapping between QML and HTML5 when reading and writing data

QML inside HTML5 inside QML

QML inside HTML5 inside QML

I.e. main UI list done in QML injected into web view created by a QML app. Just because we can 🙂
I am far from being sure it is easy to do, but if it happens to be easy, you could get the best of both worlds: controls and view interaction only from HTML5 frameworks, power of QML logic and graphics for everything else.

  • Pros: HTML5 only where it’s really needed (just for native looking controls/transitions) and nothing else. Everything else in Qt/QML
  • Cons: Could be too tough to do that many levels of injection

Real native manipulated by QML

Real native manipulated by QML

QML is not the only Qt way for contracting UI. You can still use a form designer for getting a QtWidgets app and manipulate the generated form from C++ (technically from QML too though you are not likely to do it).

Nowadays both Android and iOS have a way to define UI declaratively and certainly you can use native code for adding more controls. Well, you could define such layouts in the native tools and then instantiate and manipulate them from Qt/QML, possibly even painting a couple of particular controls yourself.

  • Pros: Native look and feel, no compromises whosoever!
  • Cons: Quite platform-specific way for integration, injecting your own controls inside can be tough

Integration to the system services

That is the area I am not really familiar with unfortunately so can’t outline many approaches. I only know that it should be possible to communicate with the Android side via JNI and some way for accessing iOS APIs should also be possible. How easy or hard it is and whether you will be able to use e.g. platform-specific Facebook SDK for logging people in is to be studied.

Experiments to perform

So here is a list of proof of concept demos I think are needed for validating the approaches outlined. Once I implement some of them or figure out an existing demo about the same, I’ll add the links to here. Demo projects could about whatever topic, I guess a basic Flickr browser could make a good reference app.

  1. Looks and feel
    1. Plain QML or plain QML + just PageStack from Quick controls. Just make them look native(ish)
    2. QtQuick controls styles to look like iOS/Android
    3. QtQuick controls styles to look like iOS/Android
    4. HTML5 (with some mobile UI framework) + interaction with the Qt objects
    5. HTML5 with some area inside painted by Qt/QML, ideally a couple of different controls in a couple of different pages
    6. HTML5 inside QML app and manipulated from QML
      • And QML inside HTML5 inside QML
    7. Native iOS layout(s) manipulated from Qt
    8. Native Android layout(s) manipulated from Qt
  2. System integration
    1. Logging in with the system integrated Facebook/Twitter/Google+ (probably many different platform-specific projects)
    2. Passing link/photo to Android sharing framework
    3. Passing link/photo to iOS sharing framework
    4. Receiving link/photo on Android from sharing on Android
    5. Receiving link/photo on iOS. Okay, that’s not very important as I think on iOS the sharing source has to exactly know your app for sharing to you
    6. Sharing link/photo using exactly Facebook/Twitter/G+ SDKs for fully optimized native look
    7. Waking up on system notifications
    8. Waking up on geofencing event or something like that
    9. Just running in the background sometimes

Your opinion

What do you think? I created this list first of all for my own understanding. I am likely to actually try a couple of approaches, but will probably stop once I figure a good enough solution for some real app to make or if I give up due to the complexity. Then this proof-of-concept catalog could continue only if there’s an active interest from somebody to make consumer grade Qt apps a reality on iOS and Android.

Does this list of approaches make any sense to you?
Do you know of some existing projects already trying these? Is something important missing?

Do you think the whole goal of making cool looking Qt apps for iOS and Android is worth studying at all while there are good 100% native platform-specific tools already and even HTML5 for those into the cross-platform UI dream?

Log4Qt for Jolla Sailfish OS and in general

I had troubles with logging from my Qt code efficiently, so took an effort to find a good and flexible logging framework that works. Log4Qt is very powerful and works well, but lacks docs and examples. So I created a sample project that uses it and tried commenting it as much as I could. It is a Jolla Sailfish OS app, but with very small changes same should work for other platforms as well (Sailfish OS is pretty much just Linux + custom QML controls + requirements for the app binaries/data to be located in specific places).

If you are in a hurry, just go grab the code on github. If you are making Jolla apps, you can use the HelloWorld Pro wizard for renaming the project into my-cool app. The rest of this post is just an overview of what happens in the code and repeats comments quite a lot.

Why logging example

Logging in the Qt world is easy, but not really configurable. Here’s how you do it typically in c++:

and here’s how you do it in QML:

Most of the time I just comment out logging statements when there is too many of them. You can also stream the logs to file via qInstallMessageHandler() and there are some code examples for it.

That works great for normal development, but always takes time when you want to log the particular code unit without too much noise from the other ones. In Qt 5.3 situation will become better with the addition of configurable categories, you will be able to enable or disable whole groups of logs yet I still find it not flexible and configurable enough. Also Jolla Sailfish OS which I care at the moment most about is still on Qt 5.1


Log4Qt is a port of a [not the latest version of the] popular Log4J library (that I happen to use too). It lets you be very simple or as advanced as you like: you can set priorities on many levels, stream logs to files, syslog, console, database even network and configure it all at run-time or via the settings files. There is only one problem: a lack of examples and documentation (docs are pretty much the ones that were ported from Log4J code).

Well, so I created a reference copy-pastable example project demonstrating many of the project features in [hopefully] the proper way. That is the project for Jolla Sailfish OS on which I focus lately, but with very minimal changes it should work for any other platforms as well (join to create ports or expand the current example to multiple platforms).

Features demonstrated

  • Multiple logging destinations: console, file (with daily log files), syslog
  • Different logging levels for different C++ classes and QML objects
  • Different logging levels for the different destinations (e.g. only ERROR+ messages to syslog, and DEBUG+ to console)
  • Configuration via stand-alone .conf files
  • Prioritized .conf file selection (falling back to default settings unless user puts another .conf file to a particular dir)
  • Different default configurations for the debug and release builds
  • A project structure that makes sense for the production projects: engine with C++ objects, app with QML objects, c++ tests and QML tests with little dependency on Log4Qt
  • A project that is good enough for passing Jolla Harbour criteria and getting to the app store
  • A separate “pseudo app” project that can be installed to the user’s device for generating more logs from the main app (basically just drops another .conf file to the proper directory)

How you use logging in your app

The easiest way to get started is to just clone log4qt-demo project. You can use script for renaming the project into my-cool-app, see HelloWorld Pro docs on how to do it.

Starting with Log4Qt one class at a time

Demo project configuration captures all console.log, qDebug(), qWarning() messages to the Log4Qt streams as a logger (unit of logging) called “Qt”, so you can continue using your current logging practices while introducing new logging facilities step by step

Logging from c++ objects

Then for the classes you want to log you state the following macro in their cpp implementation:

and from the class’s function you log one of the following ways

Logging from where these classes are used

For streaming syntax support you need to have the following in the class implementation:

And then from you main.cpp or from wherever else you can do, for example, the following:

Logging from QML

For intercepting QML logs, app part of the demo project injects QmlLogger into the QML engine. Then inside QML you can make as many loggers as you like (I recommend creating one per QML source file) and use them in the following manner:

File-based configuration

There are a couple of demo config files in the project.
What you mostly pay attention at during daily work is the bottom part where you shut up certain logging units or let them speak at the default DEBUG level:

How it is structured

There are two completely independent projects in the repository: the main one consisting of log4qt itself, engine, app, qmlTests, cppTests and increasedLoggingPackage that is sort of a fake app that makes main app produce more logs when installed (e.g. to the user experiencing tech issues).

Project structure


  • increasedLoggingPackage is a completely stand-alone micro-project that just happens to exist in the same source tree. You build it separately and send to user if you want his app installation to produce more logs
  • Note that qmlTests project also exports a shell script to /usr/share/tst-harbour-log4qtdemo-qmlTests/ that runs both cppTests and qmlTests. You can check HelloWorld Pro docs to see how to run it straight from Qt Creator.

Logging streams

Here’s what sort of structure a demo .conf file creates for your project:


You can have as many loggers as you like. I find it convenient to have one logger per class + logger called “Qt” that intercepts console.log and qDebug()/qWarning() streams. Then everything gets to rootLogger and spread further to so-called appenders that write to console, file or syslog (journalctl in Sailfish OS case).

Other things to note

  • Log4Qt is fetched via git subtree straight from that is a slight variation of original that I chose for support for colored console output (that happened to be not working for *nix) and some other modifications that seemed to be maintained in 2014. That is good enough for my purposes, you may like to use the original Log4Qt in your projects.

Where help is needed most

There is a number of TODOs in the code and in github readme. The main need is in creating ports of the solution that won’t be Sailfish OS specific. You can create simple ports or ideally improve the current project so that it builds and runs for desktop as well

Your impressions

What do you think? Makes sense? Do you want to improve it? Go fork a github project and propose pull requests or create ports

Jolla closing gesture. How to make it better

I am using Jolla hard for about a month by now and that is not my first gesture based device. It has great sides and features that could be improved. One thing that often doesn’t work well for me is the closing apps gesture. My hand is simply not big enough to easily and reliably move thumb from the very top of the device vertically down.

I think gestures in mobile OS control are one of the best things since sliced bread and Jolla continues the Nokia N9 and BlackBerry 10 path very well here. So let’s improve this gesture to make closing apps easier for me and hopefully for your too.

Closing gesture in N9 and Jolla

The idea is simple: You just move your finger from the very top of the device down and the app gets closed (moving your finger in a very vertical way is quite important for the proper gesture detection). I loved this very useful gesture from N9 times and it works just great on Jolla too except.. that Jolla’s screen is noticeably bigger. Big screens are fashionable now, but as a result I cannot comfortably close the apps anymore without stretching the hand or using the second hand. I can reach the corner of a device in an OKay way, but that’s not enough for the precise vertical movement.

There are several ways I hold touch phones when using them single handedly. Here’s how it looks like when I pull phone a little upwards in the palm, probably the maximal stretch I can do without it becoming uncomfortable.

N9 a little top  Jolla a little top

Here are the areas easily and not so easily touchable by my thumb, and how I need to move it in order to close the app or swipe it off to the task manager. As you see, there’s quite some stretching needed for closing the app.

Jolla original closing gesture

More error tolerant gesture detection

So let’s adjust the gesture detection in two ways:

– Let us move the finger along the in a more natural curved way. We will still call it “vertical” in the guide, but will be tolerant to the first few millimeters being not very straight

– Let us be able to start app closing gesture on the side of the phone. If the gesture starts in the top 1-1.5cm of the screen and then continues down as if it was a closing gesture, let’s consider it actually being the closing gesture

Jolla proposed closing gesture

What do you think? Would it help your Jolla usage as well? If yes, go vote for the idea on Jolla’s Together portal.

I was describing the idea in the right handed way for simplicity only. Certainly the same treatment could be applied for the left side of the screen as well for the left handed users.

Beautiful apps for Jolla Sailfish OS and beyond