Thank you for visiting the BlackBerry Support Community Forums.
BlackBerry will be closing the BlackBerry Support Community Forums Device Forums on April 1st (Developers, see below)
BlackBerry remains committed to providing excellent customer support to our customers. We are delighted to direct you to the CrackBerry Forums, a well-established and thorough support channel, for continued BlackBerry support. Please visit http://forums.crackberry.com or http://crackberry.com/ask. You can also continue to visit BlackBerry Support or the BlackBerry Knowledge Base for official support options available for your BlackBerry Smartphone.
"When we launched CrackBerry.com 10 years ago, we set out to make it a fun and useful destination where BlackBerry Smartphone owners could share their excitement and learn to unleash the full potential of their BlackBerry. A decade later, the CrackBerry community is as active and passionate as ever and I know our knowledgeable members and volunteers will be excited to welcome and assist more BlackBerry owners with their questions."
- Kevin Michaluk, Founder, CrackBerry.com
Developers, for more information about the BlackBerry Developer Community please review Join the Conversation on the BlackBerry Developer Community Forums found on Inside BlackBerry.
04-16-2013 06:37 PM - edited 04-16-2013 09:53 PM
I know that Cascades development is preferred and recommended and that it has some serious advantages, but for a person who has 4-5 quite complex applications already made in Qt/QtQuick for Symbian and Harmattan (MeeGo) it is far from being a perfect solution to have to now spend several months on literally having to re-do their whole UIs from scratch in Cascades.... Moreoever, if I want to support other platforms (e.g. Jolla's Sailfish OS) in the near future, it definitely isn't a good choice for me to have two separate versions of each of my applications - for Cascades and the rest - and have to further develop them separately...
So, despite all the advantages of Cascades, choosing QtQuick / Qt components instead (if only possible) is simply a much easier, more reasonable and simply BETTER choice for me... Not just to much more easily port my existing apps now, but also to be able to still maintain SINGLE versions of them in the future...
I've already ported one of my applications to BB10 in QtQuick using Qt components ported from Symbian. Except for one small problem (already solved), porting was quick and easy and the result is more than satisfactory - the application looks and feels the same (if not better) than on Symbian and the N9 and everything works just fine and smooth.
However, that application was the only one that does not require QtMobility and all the remaining ones fully rely on being able to use the GPS receiver, compass, orientation sensor, etc.
Hence the question: is there ANY way to access the GPS receiver (get location), compass and orientation/rotation sensors of the Z10 from within a QtQuick application?
If not, I'm not sure (despite really willing to) if I can find the time (and strength/patience) to re-make my applications (some of them best-sellers in the Nokia Store) from scratch in Cascades just because of not being able to access location and sensors from QtQuick that otherwise works just fine for everything else.... And I'm sure I am not the only Qt(Quick) developer who might give up just because of that, so maybe RIM could consider doing something about it? After Jolla, Ubuntu and maybe some further Qt-based mobile platforms come out, the number of Qt developers looking for easy ways to port their Qt apps to BB10 will further grow. It would be bad to disregard this...
P.S. Isn't it hilarious that on a Qt-based platform it is MUCH easier and quicker to port Android applications (often without ANY changes) than to port.... Qt applications? Doesn't it contradict the whole idea behind Qt: PORTABILITY?
04-17-2013 03:45 PM - edited 04-17-2013 04:10 PM
Although I have not tried the QtLocationSubset library directly in a QtQuick app I have used it successfully in a Qt (i.e. QCoreApplication) app. I don't see why it wouldn't work with QtQuick though. QtLocationSubset is not dependent on any Cascades components. QtLocationSubset is based on the QtMobility QtLocation module. It is a subset because only positioning and geocoding are currently supported. But it should be quite straighforward for you to give it a try by porting some of your existing code using the QtLocation positioning and geocoding functionality. The major difference is that on BB10 it is not part of QtMobility proper, and it is in the namespace QtMobilitySubset.
QtSensors is supported on BB10 as part of QtMobility, and it also does not depend on any Cascades components. It should be straightforward to port your QtSensors code as well.
See also http://developer.blackberry.com/cascades/documenta
One of the advantages of using Qt has always been a large degree of platform independence. As Qt supports more mobile platforms in the future I suspect there will be more developers in your situation, not able to use Cascades directly.
Let me know if you have any problems, I am interested to hear of the outcome!
04-19-2013 04:23 PM
Thank you for your help.
Unfortunately, if I add
import QtMobility.sensors 1.2
to a QtQuick file (that otherwise works fine), I only get white screen on the device. QtCreator does not show any error. Tried both with and without adding
CONFIG += mobility
MOBILITY += sensors
to the .pro file - same result. And the same happens if I try to use QtMobilitySubset.location 1.1
In a Cascades file (with import bb.cascades 1.0) it works OK, but in QtQuick applications (import QtQuick 1.1) it doesn't.
Am I doing something wrong?
04-22-2013 03:04 PM
Sorry, I had not considered the QML api, my experience has been with the C++ api. Though I don't know that there would be any Cascades dependencies in the QML plugins either. Did you have to modify your Qt Quick app as per http://developer.blackberry.com/native/documentati
04-23-2013 05:58 PM
I've found a solution. All it takes is registering it in main.cpp, e.g. for Compass:
sensors", 1, 2, "Compass"); qmlRegisterUncreatableType<QtMobility::QCompassRea ding>("QtMobility.sensors", 1, 2, "CompassReading",QLatin1String("Cannot create CompassReading")); qmlRegisterUncreatableType<QtMobility::QSensorRead ing>("QtMobility.sensors", 1, 2, "SensorReading",QLatin1String("Cannot create SensorReading"));
After that, QtMobility.sensors 1.2 can normally be imported in a QtQuick app and one can normally use the required items like e.g. Compass. I haven't yet tried the other sensors but I guess it's the same.