iOS 8: Die Neuerungen für Entwickler
Seite 2: Touch ID, Gerätegrößen & HealthKit
Zweiter Anlauf
Touch ID wurde mit dem iPhone 5s eingeführt, dann aber schnell gehackt und musste durchaus bittere Häme einstecken, wenngleich der Kommentar von Jürgen Schmidt "Besser mit Touch" zum Thema goldrichtig war. Mit iOS 8 gibt Apple den Zugriff auf den Fingerabdruckscanner frei. Nein, nicht wirklich frei, denn man hat ausschließlich über das Local Authentification Framework stark reglementierten Zugriff und kann nur eine Benutzerprüfung durchführen. Hierzu müssen das LocalAuthentication.framework im Projekt eingebunden und LocalAuthentication/LocalAuthentication.h importiert sein. Dann lässt sich mit folgendem Quellcode der Klasse LAContext eine Benutzerprüfung durchführen:
LAContext *context = [[LAContext alloc] init];
NSError *authError = nil;
NSString *localizedReasonString = @"Bestätigen Sie Ihre Identität";
if ([context canEvaluatePolicy:LAPolicyDeviceOwnerAuthentification
WithBiometrics error:&authError]) {
[context evaluatePolicy:LAPolicyDeviceOwnerAuthentificationWithBiometrics
localizedReason:loclizedReasonString
reply:^(BOOL success, NSError *etrror) {
if (success) {
NSLog(@"User authentifiziert");
} else {
NSLog(@"error = %@", authError);
}
}];
} else {
NSLog(@"Kein Touch-ID vorhanden");
}
Beachtung der vielen Gerätegrößen und Auflösungen
Einen wichtigen Teil der Neuerungen in iOS 8 hat Apple der Tatsache gewidmet, dass durch das iPhone 6 und iPhone 6 Plus zwei neue Bildschirmdiagonalen und Auflösungen hinzugekommen sind, unter denen eine Anwendung funktionieren muss. Bisher hatte man sich nur um die zwei Bildschirmdiagonalen 3,5 und 4 Zoll zu kümmern. Die Breite ist hierbei sogar gleich, nur die Höhe unterschiedet sich leicht. Durch die neuen Geräte kommen mit 4,7 und 5,5 Zoll jedoch komplett neue Diagonalen dazu. Deshalb werden in vielen Apps spezielle User Interfaces für die verschiedenen Geräteklassen notwendig. Damit nicht für jeden Gerätetyp ein eigenes Storyboard notwendig wird, hat Apple die Größenklassen (Size Classes) eingeführt und das Auto-Layouting aus
iOS 7 stark erweitert.
Die Größenklassen kategorisieren die Breiten und Höhen eines User Interface in die zwei Kategorien: "Regular" (viel Platz) und "Compact" (wenig Platz). Für die Gerätetypen legt Apple folgende Klassifizierungen für die Breite und Höhe fest:
| Gerät | Breite | Höhe |
| iPad (hochkant oder quer) | Regular | Regular |
| iPhone (hochkant) | Compact | Regular |
| iPhone 4/5/6 (quer) | Compact | Compact |
| iPhone 6 Plus (quer) | Regular | Compact |
Dank der Auto-Layout-Funktion von iOS 7 lässt sich im Storyboard mit Constraints das Layout feinfühlig konfigurieren. Mit iOS 8 gibt es nun mit Unified Storyboards die Möglichkeit, ein Constraint oder Controls nur für bestimmte Kombinationen von Größenklassen für Breite und Höhe zu aktivieren.
In Abbildung 3 sieht man, wie für den ausgewählten Button festgelegt wird, bei welchen Size Classes er sichtbar ist. In diesem Fall ist der Button für jede Breite und die Höhe "Regular" sichtbar. Auf die gleiche Weise lässt sich einstellen, wann ein Constraint gilt. Hierzu ist es nur auszuwählen, dann kann man in Xcode am rechten Rand ebenso die Größenklassen konfigurieren.
Dargestellt werden Kombinationen von Size Classes über die Klasse UITraitCollection. An einem UIScreen, UIViewController oder UIView lässt sich die aktive Kombination mit traitCollection abfragen.
Durch das iPhone 6 Plus kommt allerdings nicht nur eine neue Diagonale hinzu, sondern auch eine noch höhere Pixeldichte. Das virtuelle Koordinatensystem mit 414 x 736 Punkten wird deshalb nicht wie beim bisherigen Retina-Display mit Faktor 2, sondern mit 3 multipliziert und gerendert. Die sich daraus ergebenden 1242 x 2208 Pixel werden auf die 1080 x 1920 Pixel des Displays herunterskaliert. Um dem neuen Skalierungsfaktor von 3 gerecht zu werden, lassen sich alle Bilder jetzt zusätzlich mit dem Suffix @3x versehen. Da das Rendering eines User Interface mit dem Faktor 3 geschieht, liefert die Eigenschaft scale von UIScreen ebenfalls den Wert 3.0. Den echten Umrechnungsfaktor bis zu den Pixeln des Bildschirms weist die Property nativeScale zu.
Mit Vorsicht zu genießen
Die HealthKit API wird sicherlich viele Entwickler magisch anziehen, denn sie ist auch für die Apple Watch gedacht. Apple hat mit der Smartwatch sicherlich den Markt der Computeruhren nicht neu erfunden, denn es gibt schon viele Firmen am Markt. Aber Apple wird diesen in der dem Unternehmen eigenen Weise merklich mitbestimmen. Es scheint so, dass Apple es wieder einmal verstanden hat, einen Markt aufzumischen.
Jeder sollte sich aber überlegen, ob es sinnvoll ist, die persönlichsten Daten einem Weltunternehmen preiszugeben, dessen Datenhunger nicht unbedingt kleiner ist als der von Google – nur eben etwas anders.
Dennoch dürfte dieses Segment stark ansteigen und somit HealthKit eine gefragte API werden. Dem Entwickler stehen durch diese Schnittstelle eine Vielzahl an neuen Möglichkeiten zur Verfügung. Eine App, die HealthKit nutzen möchte, muss dazu einen Speicher HKHealthStore für die Gesundheitsdaten initialisieren. Er kümmert sich dann um die gesamte Kommunikation mit der HealthKit-Datenbank auf dem Gerät. Um Daten von diesem Speicher abzurufen, ist eine Berechtigung für jegliche Art von Daten einzuholen, die gelesen oder geschrieben werden sollen. Daraufhin lassen sich die aufgenommenen Gesundheitsdaten einzeln oder auch mit Abfragen oder statistischen Analysen auslesen. Auch neue Werte können in HealthKit gespeichert werden. Eine gute Übersicht über die Möglichkeiten mit dem Health Kit bietet die zugehörige Apple-Dokumentation.
