Macoun 2014: Entwicklerkonferenz zu iOS 8, Yosemite und Swift

Inhaltsverzeichnis

Apples eigene Entwicklerkonferenz WWDC ist überlaufen, teuer und weit weg – wie schön, dass sich Entwickler auch regelmäßig auf einer kleinen, aber feinen Konferenz in Deutschland treffen und austauschen können.

Die Macoun-Vorträge deckten in diesem Jahr erneut ein breites Spektrum ab, unter anderem zu iOS 8, HealthKit, iBeacons, Threads und vielem mehr. Der neuen Programmiersprache Swift widmeten sich gleich mehrere Referenten. Außerdem gab es wieder die "Werkstatt", in der Teilnehmer Experten technische Fragen stellen konnten, und erstmals den "Retro-Park", einen eigenen Raum voll mit Apple-Computern aus den letzten 30 Jahren.

Kommunizieren mit iBeacon

Brandaktuell war der Vortrag "iBeacon, HealthKit & Co." von Matthias Krauß und Tim Becker. Mit iOS 8 sind die Möglichkeiten, ein iOS-Gerät als Digital Hub zu verwenden, deutlich verbessert worden. Dank Bluetooth Low Energy (BLE) und NFC kann das iPhone mit Geräten in der Nähe Daten austauschen, ohne viel Strom zu verbrauchen – auch HomeKit, Apple Pay und Handoff bauen darauf auf. Bluetooth LE braucht besonders wenig Strom und erfreut sich breiter Unterstützung. Kompatible Geräte sind günstig in der Herstellung und einfach zu implementieren. Außerdem brauchen Entwickler von BLE-Geräten nicht das "Made For iPhone"-Programm von Apple zu durchlaufen.

Zwei Schnittstellen stehen zur Wahl: GAP (General Application Protocol) und GATT (Generic Attribute Profile). Eine Anwendung, die auf GAP beruht, ist iBeacon. Mit dem iBeacon-Protokoll können sich etwa zwei iPhones in der Nähe finden, um Nachrichten auszutauschen: Meldet sich eine App auf eine bestimmte iBeacon-UUID an, erhält sie von iOS eine Mitteilung, sobald in der Nähe ein iBeacon mit dieser UUID gefunden wurde.

Die Referenten demonstrierten, wie sich vier iBeacons im Raum suchen und finden. Der zugehörige Code beruht auf dem CoreLocation-Framework und benötigt neben einer CLLocationManager-Klasse, die die Autorisierung durch den Anwender übernimmt, eine CLBeaconRegion-Klasse zum Anlegen einer passenden Region, die der Manager absucht. Über eine Delegate-Methode erfährt der Entwickler, wenn ein iBeacon in Reichweite ist. Die Entfernung lässt sich über die Leistungsangabe zwar abschätzen, doch muss man dabei beachten, dass schon eine Hand die Leistung stark abschirmen und somit das Ergebnis verfälschen kann. Nach Lokalisierung der Geräte lässt sich ein regulärer Datenaustausch über das CoreBluetooth-Framework intiieren. Natürlich nur, wenn es sich nicht um einen reinen BLE-Sender handelt.

Mit dem GATT-Protokoll, das auf einer anderen Ebene arbeitet, sind Services wie das Auslesen einer Temperatur machbar. Apple verwendet GATT für HomeKit. Leider durften die Referenten nicht auf Details eingehen, da HomeKit noch unter NDA steht.

Healthkit

Bei HealthKit geht es um viele verschiedene Daten – diskret und skalar, statisch und dynamisch –, die in der HealthKit-App zentral organisiert sind. Anhand einer Beispielanwendung zeigten Krauß und Becker am Quellcode, wie man Inhalte in die HealthKit-Datenbank schreibt und liest. Wenn ein Programm die Genehmigung vom Anwender erhält, sucht man über Bluetooth nach einem Gerät, im Beispiel einem Thermometer. Im Austausch fragt die App die zur Verfügung stehenden Services auf dem Gerät ab, sieht und registriert den Temperatur-Dienst. Sobald sich nun die Temperatur ändert, erhält die App eine Notification der neuen Werte und schreibt sie in die HealthKit-Datenbank. Dabei erfasst sie zusätzlich Metadaten wie den Zeitraum der Messung. Die grafische Darstellung entlang der Zeitachse schafft Überblick. Mit dem Gesundheits-Framework sind viele Kombinationen möglich. So kann etwa ein Programm im Hintergrund Messwerte aufzeichnen und ein anderes sie auswerten.

Riesige Softwareprojekte

Mac & i-Autor Max Seelemann begann seinen Vortrag über die Anforderungen komplexer Software-Projekte mit der Folie "Nur unter Druck entstehen Diamanten". In den letzten drei Jahren haben er und seine Mitstreiter einen Texteditor mit über 280.000 Zeilen Code entwickelt. Dabei hat er viel gelernt, erzählte er – vor allem, wie man ein Team organisiert, Leute einstellt und Aufgaben verteilt. Ohne gute Organisation sei ein Projekt dieser Größenordnung nicht zu stemmen.

Ein Bugtracker erleichterte das Verfolgen von Bugs, ermöglichte Diskussionen und das Einhalten von Meilensteinen. Alle Fälle durchlaufen Stufen wie "offen", "zu erledigen" (Sprint), "in Arbeit" (In Progress), "fertig" (Completed), "Abnahme ("In Review"), "erledigt" (Resolved) und "geschlossen". Jede Änderung im Code wird von einem oder mehreren Entwicklern überprüft und kommentiert. Teilweise dauert das auch mal zwei Wochen. Wichtig für den Code seien die Kommentare, so Seelemann. Vor allem die Randbedingungen und Edge Cases müssen gut dokumentiert sein, damit man auch nach Jahren noch versteht, was eigentlich passiert. Der ganze Quelltext besteht aus etwa 20 Prozent Kommentaren. Größere Klassen organisiert sein Team über mehrere Header- und Implementations-Dateien, dabei kommt das Category-Konzept von Objective-C zum Einsatz, um eine Klasse möglichst klein zu beginnen.

Threads und die Tücken

Nach einer kleinen Einführung in Threads zeigte Frank Illenberger von den ProjectWizards, welche Probleme man mit der Nebenläufigkeit haben kann, wie man sie vermeidet und wie man Grand Central Dispatch (GCD) als Retter in der Not einsetzen kann. Das Problem: Das Betriebssystem verteilt die CPU-Kraft aller Kerne auf die einzelnen Threads und der Entwickler hat wenig Kontrolle, was wo läuft. Fehler in Threads lassen sich schwer lokalisieren, da sie nicht-reproduzierbar auftreten können. Dennoch sind Hintergrundabläufe enorm wichtig, etwa um asynchrone Netzwerkanfragen zu erledigen oder um zu verhindern, dass der zentrale Mainthread blockiert wird und nicht mehr auf Tastatur- und Mausereignisse reagieren kann.

An einem Beispielprogramm zeigte Illenberger einige häufige Probleme und machte Lösungsvorschläge: Man sollte gemeinsame Daten möglichst vermeiden und unveränderliche Objekte bevorzugen, wo immer es geht. Obendrein gilt es, Datenbanken zu verwenden oder Locks/Mutex-Konstruktionen einzusetzen. Bei Locks sind allerdings auch die gefürchteten Deadlocks möglich, das passiert, wenn zwei Threads gegenseitig auf sich warten. Mit Dispatch Queues als Teil von Grand Central Dispatch kann man das vermeiden. Dabei verwaltet Apples Framework den Thread Pool selbst; der Entwickler hantiert nur mit Codeblöcken. Blöcke dürfen Abhängigkeiten haben und einige Blöcke können exklusiv laufen. Ein Deadlock ist dann unmöglich, weil nur ein Block zeitgleich läuft. Quintessenz: Threads sind oft nötig, aber man sollte sehr vorsichtig damit umgehen und möglichst auf GCD setzen.

Vor- und Nachteile von Swift

Im ihrem Vortrag zu Swift setzten sich Armin Negm-Awad und Christian Kienle kritisch mit Apples neuer Programmiersprache auseinander, die viele neue Konzepte einführt (siehe Schwerpunkt in Mac & i Heft 5, Seite 146 und 152). Der größte Unterschied: Swift ist eine stark typisierte Sprache, Objective-C dagegen eine dynamisch typisierte. Um Code für verschiedene Typen zu schreiben, kann man in Swift Templates einsetzen. Damit harmonieren jedoch viele dynamische Konstrukte nicht. Core Data, Responder Chain, Core Animation, der Undo-Manager und Proxies sind alles Konstrukte, die ohne dynamische Typisierung schwer oder gar nicht möglich sind.

Leider gibt es noch einige Probleme in Swift. Zum Beispiel bestimmt beim Overloading der Typ der Variable mitunter, welche Funktion aufgerufen wird, und das muss nicht die sein, die man erwartet. Außerdem funktioniert die Typinterferenz bei komplexen Ausdrücken wie Collections nicht immer. Je nach Inhalt der Deklaration von Array- oder Dictionary-Variablen und Syntax kommt ein Swift-Array oder ein NSArray heraus. Bei Ausdrücken kann zudem der Typ der Variable links von der Zuweisung bestimmen, wie der Ausdruck rechts der Zuweisung ausgewertet wird. Auf diese Weise ruft Swift eventuell andere Funktionen auf als erwartet. Das kann die Arbeit mit der Sprache sehr erschweren.

Des weiteren demonstrierten die beiden Referenten Probleme bei Optionals, also Referenzen, die undefiniert sein dürfen. Sie schimpften über kryptische Fehlermeldungen, die häufig auftreten und einem nicht wirklich weiterhelfen. Was soll einem etwa "@lvalue $T3' is not identical to 'String'" sagen? Insgesamt ist Swift, so die Schlussfolgerung von Negm-Awad und Kienle, immer noch eine Baustelle.

Party-Time

Am Abend des ersten Konferenztages war Feiern angesagt: Die Macoun-Party fand im Lokalbahnhof statt. Bei schönstem Altweibersommerwetter und mit über 200 Leuten am Buffet. Leider war die Schlange eine Serial Queue und nicht zur parallelen Verarbeitung ausgelegt, aber bei dem leckeren Essen wartete man gern. Viele nette Gespräche und das ein oder andere Bier lockerten die Stimmung.

Besonderheiten in Swift

Natalia Ossipova arbeitete die speziellen Fähigkeiten von Swift heraus. Swift ist nicht nur eine statisch typisierte, sondern auch eine objektorientierte, imperative und teilweise funktionale Programmiersprache. Der Typ kann automatisch anhand der ersten Zuweisung ermittelt werden, das reduziert Schreibarbeit. Arrays dürfen im Unterschied zu NSArrays nur einen Typ haben – es sei denn, man inkludiert UIKit, wie im gezeigten Beispiel. Danach kann Swift auch ein NSArray verwenden und folglich doch wieder verschiedene Typen im Array mischen.

Der Datentyp Any in Swift kann jeden anderen Typ aufnehmen. Tupel eignen sich besonders, um mehrere Werte aus einer Funktion zurückzugeben. Einige Konstrukte wie Switch-Kontrollstrukturen mit Bereichsangaben, Typauswahl und Pattern Matching sind deutlich mächtiger als in C. Mit Operator Overloading kann man sich eigene Operatoren bauen, etwa für Klassen, um etwa das Addieren von mehreren Objekten zu ermöglichen. Funktionen in Swift sind Objekte, die sich auch als solche benutzen lassen. Dabei kann man Funktionen Variablen zuweisen und später über die Variable aufrufen.

Swift ist auch etwas funktional. Man kann damit etwa ähnlich rekursive Funktionen mit Listen erstellen wie in Haskell. Allerdings berechnet Swift dann alle Varianten, weswegen man dringend eine Abbruchbedingung einbauen sollte.

Yosemite-Apps

Das Erstellen einer beeindruckenden GUI für OS X 10.10 war das Thema von Florian Bachmann. Dabei machte er auch die Parallelen und Unterschiede zwischen iOS- and Mac-SDKs deutlich. Sein Beispiel-Programm nutzte NSDocument, das von Haus aus bereits Funktionsbereiche wie iCloud, Undo, Sichern und vieles andere mitbringt. Die Oberfläche erzeugte er mit Storyboards, die jetzt auch auf dem Mac bereit stehen und eine einfache Möglichkeit sind, die Bedienoberfläche mit Autolayout und vielen nützlichen Hilfen aufzubauen. So kann man per Drag & Drop Aktionen mit Steuerelementen verknüpfen.

Als weiteren Punkt demonstrierte Bachmann das Erstellen eigener Frameworks. So lässt sich Code kapseln, den man beispielsweise auf iOS und Mac OS verwendet. Am Ende beleuchtete er, wie man von NSDocument auf UIDocument umsattelt und das Ganze so auf dem iPhone zum Laufen bringt. Idealerweise fügt man in solchen Fällen einem Projekt zwei Targets hinzu und kann so 90 Prozent seines Quelltextes für iOS und Mac OS X verwenden.

Umstieg mit Schmerzen

Auch Mac & i-Autor Alexander von Below und Tammo Freese setzten sich kritisch mit Swift auseinander. Swift ist zwar noch neu, aber bereits von Apple als Objective-C-Ersatz angelegt. Der Umstieg bereitet Schmerzen, aber nach dem ersten Chaos sollte man besser mit Swift zurecht kommen als mit Objective-C.

Ein Vorteil von Swift ist, dass der Programmierer durch Optionals klar definieren muss, wann Objektreferenzen nil sein können. Normalerweise dürfen sie das nämlich nicht und der Compiler würde einen Fehler melden. Das wird viele typische Programmierfehler vermeiden helfen. In Swift sind viele Elemente als Struct definiert und dadurch effizienter. Enums dürfen Methoden haben, die auf den Werten arbeiten. Das gibt es in C nicht, wo Enums nur bessere Konstanten sind.

Man kann vorhandene Operatoren umdefinieren (wie schon im Vortrag von Natalia Ossipova erwähnt), aber dabei nicht nur vorhandene Operatoren, sondern auch komplette eigene Zeichen erzeugen. Zum Beispiel das ∈ für einen Operator, der prüft, ob in einem Array ein Wert enthalten ist. Generics sorgen im Operator-Beispiel dafür, den ∈-Operator auf alle Listen anwenden zu können.

Für Aufrufe von Funktionen und Methoden benutzt Swift kein Messaging mehr, sondern ruft direkt auf. Das ist deutlich schneller, vor allem, wenn der Compiler die Funktionen direkt einfügen kann. Damit fehlen aber einige Dinge, die man in Objective-C schätzen gelernt hat, wie Responder Chain, das Weiterleiten von Messages und Key Value Observing.

Allerdings ist Swift wohl die Zukunft und von Below wettet schon, dass es auch die Sprache für Apps auf der Apple Watch sein wird. Sobald Apple Swift auch mehr für eigene Projekte einsetzt – und davon ist auszugehen – dürfte sich viel bewegen, vor allem in den Frameworks.

Unterm Strich

Die Macoun fühlt sich tatsächlich an wie eine kleine, deutsche WWDC. So viele Entwickler für iOS und Mac auf einem Fleck findet man sonst nirgendwo, jedenfalls nicht in Deutschland. Dabei stammen diese aus ganz unterschiedlichen Disziplinen – vom kleinen Indie-Entwickler, der vielleicht nur ein Programm im Angebot hat, über Auftragsentwickler mit dutzenden Apps als Referenz bis zum Angestellten von DAX-Konzernen. Wir können jedem Entwickler den Besuch empfehlen und dem Team ein großes Lob aussprechen für die Organisierung und Durchführung des Events. Bis zum nächsten Jahr! (thk)