A Qt QML Beginner’s Project: MotoRing, part 1 – GPS

I unloaded some Qt newbie frustration the other day detailing my first serious efforts to code for the Nokia N9.  Now I’d like to step back a bit and outline the actual project, and in subsequent posts walk other newcomers through my coding journey of pleasure and pain.

First a disclaimer: I’ve been programming for over 25 years.  That has included COBOL, Forth, Logo, DOS/VAX/Unix batch commands, Basic, LISP, Pascal, C, JavaScript and Visual Basic (both COM and .NET).  While I could work minor wonders with scripting and compiled linear languages, I found that I have been most productive in event-driven VB.Net.  Readers should know that I am not targeting an audience that’s totally new to programming, but rather, programmers who like me are experienced with other languages and platforms but new to Qt.

I really wasn’t very apprehensive about Qt, especially the mature 4.7.  Friends kept telling me how easy it was, and the Qt Creator environment did not look difficult at all at first glance. 

What got me motivated to finally dive in?  I was presented recently with a coding challenge and after some thought decided I would create an app for the Nokia N9 and N950 that would intercept calls and texts for responsible drivers.  I hashed the idea over with Andrew Flegg and Thomas Perl in London last month and they offered some really useful ideas.  Then I discovered not long ago that apps of this sort already exist for other platforms so there certainly appeared to be a need.

I elected to go the Qt Quick route and see if I could do this completely using QML and JavaScript .  What better test of QML’s depth and breadth?  I also have some experience with JavaScript and none with C++ so that was a deciding factor as well.

With any project, it’s always good to tackle requirements first.  So other than a clever name (in this case, MotoRing) what were mine?

• Constantly retrieve current device speed (in user-preferred units)
• Intercept calls and texts when device is moving above a preset threshold
• Send automatic text to callers/texters informing them that driver is not taking calls.  They should be instructed to immediately call back if there is an emergency
• Allow calls through from previously intercepted number if placed within specified time frame (i.e., emergencies)
• Automatically exit app after device has been moving below speed threshold for a given amount of time

That’s pretty much it.  Of course we can add more bells and whistles, but it’s usually best, especially for us beginners, to focus on core functionality first.  On that note, as I began this I wasn’t even sure if QML and JavaScript could handle this idea.  So the first order of business was to check that out, starting with the GPS need.

As I noted in the previous article, I found example code right away.  After some small bugs were exorcized, the example ran perfectly.  I just needed to add Speed capture.

No need to rehash my struggles with Qt Creator’s behavior.  I’m learning to work around its occasional flakiness anyway (and will report bugs once I get a good grip on what’s been happening).  My main problems outside of bugs and IDE quirks had to do with QML element layout.  Minor changes kept flinging things around my workspace.  Then I came to understand that Qt Creator allows UI elements to be positioned relative to each other… and that’s how my selected sample code was oriented.  This is an elegant solution to the need for fluidity on mobile devices, especially in handling portrait and landscape flipping.  On a related note, I had also been mystified as to why the layout Grid in the sample code extended beyond my portrait mode boundary, until I realized that this was done to accommodate landscape mode.

Ah HA!

With this new-found grasp of QML layout features I was able to make changes to elements positioning without fearing their fall into some IDE black hole.  That included adding a new Speed indicator for testing purposes (I really don’t need all the other GPS properties).

Getting the speed indicator to work was easy.  I found what I needed on a Qt API documentation page and It Just Worked.  But in my excitement I neglected to note how speed was returned.  My youngest son and I took the app out for a test drive and were mystified at the results.  Speed in MotoRing seemed to be about a fourth of actual.

I felt pretty stupid when I discovered the next day that speed is shown by default in meters per second.  That is, 3.6 kilometers per hour.

Of course in the US we measure miles per hour.  I wanted my app to be able to handle either, so I needed a function.  I whipped the following up in JavaScript (precision is truncated):

function speedConvert(speedState) {
if (speedState == buttonMetric)
return 1.00;
else
return 0.62;
}

I also added a ButtonRow element to the top of the page to toggle miles-per-hour and kilometers-per-hour.  The text box for speed passes the state of this element through the JavaScript function above to determine which is being used.  There is probably an even easier way to do this but my method works well.  Not counting a brief hair-pulling period where I forgot that JavaScript has no “THEN” in “If/Else” statements.  Oops!

After I got this part working well, I updated the code at wiki.meego.com/QML/Get_GPS_data.  If you have ideas on how to improve it further, feel free!

Some things to note:

• It would be nice to have the app automatically set units of measure based on localization settings, but I’m not even sure QML can support that.  Readers?
• I would have rather used a RadioButton rather than ButtonRow element– but despite what’s shown in the Harmattan API documentation, it does not appear to be available for that platform.  Question: why would this be a Symbian-specific element?  Radio buttons are very common UI features
• Speed accuracy seems to be +/- about 3 miles per hour, so consider that when you set thresholds

Next: I need to add the threshold setting, and look into SMS interception…

On a broader note: if you’re interested in this series, and/or articles that strive to make technology more accessible, make sure to subscribe to this blog as that will be more of the focus going forward.  And feel free to share articles!