javablog.ch

Jeder Bildschirm in einer nativen Blackberry-Applikation leitet von net.rim.device.api.ui.Screen ab. Das Blackberry-Framework verwaltet die Screens als Stapel (“Stack”): Soll ein Screen geöffnet werden, muss er mit UIEngine.pushScreen(Screen screen) auf den Stapel gelegt werden.

Wird ein Screen geschlossen, wird wieder der darunterlegende Screen dargestellt. Dieses Verhalten entspricht im Übrigen genau dem UINavigationController des iPhone SDKs.

Beim “Pushen” des Screens werden dem Screen diejenigen Objekte übergeben, die er darstellen und verarbeiten muss. Hier ist beim Software-Design zu beachten, dass der Screen nicht das komplette ganze Modell kennt, sondern immer nur den spezifischen Modell-Abschnitt, den er darstellen muss. So wird eine enge Verzahnung der Screens vermieden und ein höherer Wartungs- und Wiederverwendungsgrad erreicht.

Wenn der oberste Screen Änderungen an darunterliegende Screens kommunizieren muss, so sollte dies über ein Interface geschehen, um weiterhin eine lose Koppelung der Screens sicherzustellen. Das nachfolgende vereinfachte Beispiel zeigt dieses Pattern anhand einer vereinfachten Mailapplikation.

1. Mit Klick auf “Posteingang” wird ein ListScreen erzeugt und auf den Stack “gepushed”
   Auf dem Stack liegen nun zwei Screens (IndexScreen und ListScreen). Der ListScreen hält eine Referenz auf einen Vector mit allen Emails.
2. Beim Klick auf eine Email in der Liste wird eine Instanz des DetailScreens erzeugt und auf den Stack gepushed. Diese Instanz erhält eine Referenz auf das darzustellende E-Mail Objekt und den ListScreen über das Interface “DetailScreenListener”.
3. Über genau dieses Interface teilt der Detailscreen dem ListScreen mit, wenn der User auf “Löschen” geklickt hat, damit dieser aus der Liste entfernt wird

Dieses Pattern erlaubt flexibel strukturierbare Anwendungen und wird sowohl im Blackberry- als auch in iPhone-Apps eingesetzt.

Mit der steigenden Popularität von Apple-Produkten rückte auch die Programmiersprache “Objective-C” in den Fokus von Software-Entwicklern, da nur mit ihr die Entwicklung von nativen iPod-, iPhone- und iPad-Applikationen möglich ist. Das Faszinierende an dieser Sprache ist die Kombination aus statischer und dynamischer Typisierung:

“Objects are dynamically typed. In source code (at compile time), any object variable can be of type id no matter what the object’s class is. The exact class of an id variable (and therefore its particular methods and data structure) isn’t determined until the program runs. [...] To permit better compile-time type checking, and to make code more self-documenting, Objective-C allows objects to be statically typed with a class name rather than generically typed as id. It also lets you turn some of its object-oriented features off in order to shift operations from runtime back to compile time.”

http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocStaticBehavior.html

Konkret bedeutet dies, das beliebige Nachrichten an Objekte verschickt werden können. Mit Hilfe von “Categories” können bestehende Klassen (beispielsweise NSString) sogar um neue Methoden erweitert werden, ohne deren Quellcode zu ändern. Zudem können größere Klassen mit Categories in mehrere Dateien aufgeteilt werden.

Aufgrund des dynamischen Verhaltens kennt Objective-C keine privaten Methoden. Zwar kann auf eine Deklaration der Methode im Interface verzichtet werden, allerdings kann die Methode dennoch aufgerufen werden.

Auch null-Referenzen verhalten sich etwas anders als gewohnt: In Java führt jeder Methodenaufruf einer null-Referenz zwangsläufig zu einer NullPointerException. In Objective-C dagegen wird in diesem Fall nil zurückgegeben, und das ohne Fehlermeldung. Die nil-Referenz hat auch eine weitere Aufgabe: In Listen (NSMutableArray) wird nil zur Markierung des Listenendes verwendet, und kann somit nicht als null-Wert genutzt werden. Für diesen Zweck gibt einen eigenen Typ namens NSNull.

Eine Garbage Collection ist nur für Mac OSX 10.5 verfügbar. iPad-, und iPhone-Entwickler müssen sich dagegen mit dem halbautomatischen Memory-Management anfreunden bzw. auseinandersetzen. Da Objective-C direkt von C ableitet, erbt die Sprache auch einige C-Artefakte wie beispielsweise den für Java-Entwickler ungewohnten Präprozessor.

Trotz dieser Hürden überzeugt Objective-C jedoch mit ihrer spannenden Kombination aus statischer Typisierung und dynamischen Binden. Das Tooling (XCode) kann leider aber noch nicht mit Eclipse mithalten. Hier besteht noch deutlicher Nachholbedarf seitens Apple.