Saturday, January 12, 2013

Supersize QT - > QT + BB10 = Awesome - kindof...

Hell yes.
So finally a new QT phone. I mean, a phone with *official* QT support  (that is available, that is - as we know, Android and WP will be supported thanks to Digia in the coming future too, and also Android is already supported unofficially via the Necessitas). This rocks. This is multiplatformness in it's purest form.
In it's perfect form! It's a perfect world! I build an application for one device (say, the only 100% swype-certified phone currently in existance, the N9 / N950) and then require *minimal* changes to my app's codebase in order for it to run on other OS'es like, for an example, Black Berry 10 (BB10). Well, not counting the few changes to support the few differences in the APIs but apart of these, there should be nothing else that would require anything more, there...Because we do not WANT to have to change OTHER stuff, right? What we want, is to maximize monetization, by minimizing costs, no?
Well, f*ck that.
I think that is what is in the minds of most of the project planners of today's new OS'esses.
Why is that? Well, we have this nice and fancy UI scripting language which QT has introduced some time ago. QML, that's right. Now the C++ QT interfaces are standard. And you can't really benefit from them unless you use them; this architects seem to have understood. But the syndrom of NIH (=Not Invented Here) strikes back yet again in QML!
BB10 supports QT Quick components (sort of). But also defines their own set of QML components: Cascades. Worst of it, they are completely incompatible. So you not only have an extremely limited support for the QtQuick components in the SDK. I am talking of out-of-the-box usage of components mind you, aka bundled in the SDK, aka I want to use a Button class from my QML file in my BB10 QT project, and it works out of the box when I press "Run" on the first time! I know now people will think "why don't you just include the ones from the Qt SDK" and on, but the heck, who wants to do it? Who takes the time? Qt is supposed to be officialy supported by BB10! OFFICIALLY goddammit! Why use that word if it is NOT true? So I was saying, on top of this, not only you get an SDK with limited support of QT's QtQuick QML, but you also get incompatibility between the QML components defined by Cascade versus the QtQuick ones! How's that? Well, check this out.

The following is an example of an out-of-the-box "QtQuick project for BlackBerry" from QtCreator 2.6.0:

#include <QApplication>
#include "qmlapplicationviewer.h"

int main(int argc, char *argv[])
QScopedPointer<QApplication> app(createApplication(argc, argv));

QmlApplicationViewer viewer;
viewer.addImportPath(QLatin1String("modules")); // ADDIMPORTPATH
viewer.setOrientation(QmlApplicationViewer::ScreenOrientationAuto); // ORIENTATION
viewer.setMainQmlFile(QLatin1String("qml/main.qml")); // MAINQML

return app->exec();

Nothing special, we have our usual qmlapplicationviewer.h and stuff.

Now, the same for Cascades QML, please:

#include <bb/cascades/AbstractPane>
#include <bb/cascades/QmlDocument>
#include "myobject.h"
using namespace bb::cascades;

int main(int argc, char *argv[])
Application app(argc, argv);
//! [0]
// Load the UI description from main.qml
QmlDocument *qml = QmlDocument::create("asset:///qml/main.qml").parent(&app);
// Make the PizzeriaSearcher object available to the UI as context property
qml->setContextProperty("_someobject", new MyObject(&app));
//! [0]
// Create the application scene
AbstractPane *appPage = qml->createRootObject<AbstractPane>();
return Application::exec();

Can you spot the differences? Cause I can; and I tell you, this is *not* portable code. No SIR!
The main one is QmlDocument from BB10 Vs QmlApplicationViewer in QtQuick.

NIH wins again it seems.

No comments: