Exzellente Präsentation zu dem Thema BlackBerry-Layouting

Wer sich ernsthaft mit BlackBerry-Entwickung auseinandersetzt, sollte sich die Präsentation “DEV20 – Custom Layouts” von der letztjährigen DEVCON (RIM’s Entwicklermesse) ansehen.

Die Präsentation zeigt, wie schicke UIs skalierbar implementiert werden können. Das tolle ist, dass RIM den kompletten Quelltext der vorgestellten Manager und Fields zur Verfügung stellt.

Der Download erfordert allerdings einen BlackBerry Developer Account.

3 Dinge, die das BlackBerry-SDK gut löst

1. Manager und Fields

Die kleinste Basiseinheit im UI-Framework ist net.rim.device.api.ui.Field, welches einen rechteckigen, zeichenbaren Bereich darstellt. Beispiel für ein Field ist net.rim.device.api.ui.component.EditField, welches Texteingaben ermöglicht.

Fields werden durch net.rim.device.api.ui.Manager-Instanzen verwaltet. Ein Manager ist für die Positionierung der enthaltenen Fields sowie für das Scrolling verantwortlich. Jedes Field kann zu genau einem Manager zugeordnet werden. Beispiel für einen Manager ist net.rim.device.api.ui.container.HorizontalFieldManager, der seine Fields horizontal anordnet. Manager können auch andere Manager enthalten, da sie selbst von Field ableiten.

Für komplexere Views müssen eigene Manager und Fields implementiert werden. Was anfangs etwas gewöhnungsbedürftig erscheint, entpuppt sich schnell als durchdachtes Konzept.

2. Crypto-API

Kernkompetenz der BlackBerry-Smartphones ist der Einsatz in Unternehmen. Dementsprechend umfangreich und mächtig ist auch die Crypto-API des SDKs. Alle Verschlüsselungsanforderungen in unseren Projekten konnten wir mit der Crypto-API lösen, ohne fremde Bibliotheken verwenden zu müssen.

3. Eclipse-Integration

Mit eines der grössten Ärgernisse in der BlackBerry-Entwicklung war die veraltete, swing-basierte Entwicklungsumgebung names “JDE”. RIM hat reagiert und ein Plugin für Eclipse entwickelt, welches seit letztem Jahr, bzw. der Version 1.1.1 auch wirklich praxistauglich funktioniert. Durch das “Code Hot Swap”-Feature, also der Austausch von COD-Files zur Laufzeit verringern sich auch die zeitraubenden Neustarts des Simulators.

Zudem muss man immer noch eigene Ant-Skripte bauen, um auf Knopfdruck ein Deployment für alle unterstützten OS-Versionen zu generieren. Hier besteht noch Verbesserungspotential.

3 Dinge, die das BlackBerry-SDK eher suboptimal löst

1. Welchen Transportweg hätten Sie gern ?

Ein Http-Request kann über 5 verschiedene Transportwege übermittelt werden:
1. BIS (BlackBerry Internet Service)
2. BES (BlackBerry Enterprise Service)
3. WAP 2.0
4. Direct TCP – (Direkt über den APN des Netzbetreibers)
5. WiFi

Welcher Transportweg für eine Http-Verbindung genommen werden soll, muss der Entwickler selbst bestimmen und dabei gleichzeitig auch die Verfügbarkeit prüfen. Natürlich verhalten sich die Transportwege auch unterschiedlich: Beispielsweise wird man bei dem Transportweg BIS oder BES nie einen HTTP 301 oder 302 zu sehen bekommen, da die Redirects bereits in der BlackBerry-Infrastruktur aufgelöst werden.

Verschärfend kommt hinzu, dass dem Endkunden je nach Datentarif und gewählten Transport unterschiedliche Kosten entstehen können. Somit muss der Kunde in den Einstellungen der App die Möglichkeit haben, den präferierten Transportweg auszuwählen. iPhone-User und Applikationsentwickler schütteln hier einfach den Kopf. Zwar stellt RIM seit der OS-Version 5.0 eine Network-API zur Verfügung, die das ganze vereinfacht, aber für ältere OS-Versionen muss dies selbst implementiert werden.

2. Jeder schreibt sich das Logging-Framework selbst

Es soll ja tatsächlich in der Java-SE Welt noch vereinzelt Leute geben, die sich eine eigene Logger-Implementierung schreiben. In der BlackBerry-Welt macht das jeder, da die mitgelieferte EventLogger-Klasse nur rudimentäre Funktionalität bietet und sehr unglücklich zu programmieren ist. Beispiel gefällig ?

  // Register application for event logging with GUID
 EventLogger.register(0x9c805919833654d6L, SampleApp);

 // Log a numeric event.
 EventLogger.logEvent(0x9c805919833654d6L, 12, EventLogger.INFORMATION);

Im Übrigen kann ein Log maximal 16kB umfassen.

3. Anzahl der Threads bei älteren Geräten auf 16 limitiert

Eine App kann auf älteren Geräten max. 16 Threads gleichzeitig laufen lassen. Wenn eine App überdurchschnittlich komplex ist, und viele Dinge im Hintergrund erledigt (Parsing, GPS- und CellId-Lokalisierung, Laden von Kartendaten), dann muss man aufpassen, dass diese Grenze nicht überschritten wird. Ansonsten wird die Applikation unschön mit einem TooManyThreadError beendet. Dies betrifft allerdings nur die älteren Geräte. Modernere Modelle wie der Torch oder Bold können weitaus mehr Threads parallel laufen lassen.

Aber wo Schatten ist, ist auch Licht. Der nächste Blogeintrag handelt von 3 Dingen, die das BlackBerry-SDK elegant löst.

Mein Artikel “Brombeerplantage” im “Mobile Developer Android” Magazin


In eigener Sache: Morgen erscheint das Magazin “Mobile Developer Android” am Kiosk. Das Magazin setzt den Fokus klar auf Android-Entwicklung, behandelt aber andere mobile Plattformen wie BlackBerry oder Bada.

Ich konnte einen 7-seitigen Artikel beisteuern, der den Einstieg in diese Entwicklungsplattform erleichtert. Der Artikel stellt das UI-Framework vor, erläutert die Besonderheiten bei Netzwerkverbindungen und beleuchtet das Tooling sowie Fragmentierung der BlackBerry-Plattform. Viel Spaß beim Lesen …