BlackBerry Jam 2013 – Best Practices für Cascades und QML

Die mobile Denkfabrik  –  1 Kommentare

Als Nokia mit Qt 4.7 die Programmier- bzw. Beschreibungssprache QML erstmals einführte, sahen viele alteingesessene Qt-Entwickler wenig bis keinen Sinn in der Beschäftigung mit dem neuen Modul. Unter BlackBerry 10 führt kein Weg an der Technik vorbei – Cascades baut auf QML auf. Johan Larsby und Anders Jälevik zeigten auf dem BlackBerry Jam 2013 einige Best Practices für die neue Programmiersprache.

Die Entwicklung von Cascades macht offensichtlich Spaß.
QML und C++ gehören zusammen

Es ist nicht sinnvoll, die Programmiersprachen "gegeneinander auszuspielen". Stattdessen sollten Entwickler die Fähigkeiten der beiden Entwicklungsumgebungen optimal ausnutzen. So fällt das Realisieren von GUIs in QML wesentlich leichter, während Geschäftslogik dank der besseren Debugging-Funktionen in C++ schneller von Hand geht.

Typ-Engine von QML nutzen

Da QML auf JavaScript basiert, bietet es einen Variant-Datentyp. Die Verwendung davon ist nicht empfehlenswert, da sie dem Compiler Möglichkeiten zur Verifikation des Quellcodes nimmt.

Vermeiden Sie die connect-Methode in QML

In C++ erstellen Sie Verbindungen zwischen Signalen und Slots immer durch das Aufrufen der connect()-Methode. In QML gibt es diese Funktion ebenfalls – allerdings ist es nicht sinnvoll, diese einzusetzen. Das liegt – unter anderem – daran, dass QML-Objekte ihre Signale über die on-Properties exponieren. Das Verwenden dieser Eigenschaften steigert die Übersichtlichkeit.

Eigene Steuerelemente raus aus bb.cascades

Wer ein eigenes Objekt exportiert, sollte es keinesfalls im Default-Namespace liegen lassen. BlackBerry erweitert sein Framework regelmäßig – wenn ein Steuerelement mit dem selben Namen wie das Ihre hinzugefügt wird, zerfällt Ihr Code.

Id und objectName sind böse

Von Haus aus sind QML-Objekte nicht von außen ansprechbar. Wenn Sie eines der Elemente aus QML ansprechen möchten, benötigen Sie das id-Attribut – der Zugriff aus C++ erfolgt mit dem über objectName zugewiesenen Namen. Leider ist es nicht sinnvoll, jedem Objekt eine id und einen objectName zuzuweisen (siehe Abbildung 2). Stattdessen sollten Sie nur jene Objekte benennen, die auch wirklich von außen anzusprechen sind.

Wenn jedes Steuerelement eine id hat, wird der Code schnell unübersichtlich.
Nutze das Parent-System

Qt kann C++ nicht um die in der Sprachdefinition nicht vorgesehene Garbage Collection ergänzen. Zur Erleichterung des Speichermanagements liefert das Framework das Parent-Child-System mit. Jedes von QObject abgeleitete Objekt sollte das ihm zugrunde liegende Objekt mit einem Elternobjekt initialisieren – dadurch verhindern Sie die meisten Speicherlecks.

QStrings sind initialisiert

Klassische C++-Strings verlangen Initialisierung. In Qt ist das nicht notwendig – ein QString ist von Haus aus auf „“ initalisiert.

Vermeide dynamic_cast

Zu guter Letzt wiesen die beiden Vortragenden darauf hin, dass Qt mit qobject_cast eine verbesserte Form des bekannten dynamic_cast-Makros mitbringt.

Die hier gezeigten Methoden führen bei konsequenter Anwendung zu einer wesentlichen Verbesserung der Codequalität.