Entwicklung von Apps für watchOS 2, Teil 2
Apple hat bei watchOS 2 die zugrunde liegende Architektur signifikant überarbeitet. Nun lässt sich beispielsweise Multimedia in den Apps nutzen. Aber welche konkreten technischen Möglichkeiten ergeben sich zusätzlich?
(Bild: Apple)
- Thomas Sillmann
Neben der in einem früheren Artikel besprochenen Digital Crown ist die erstmals in der Apple Watch verbaute Taptic Engine ein weiteres wichtiges Hardwareelement von Apples Smartwatch. Sie dient dazu, Nutzer mittels leichtem "Antippen" auf das Handgelenk auf Neuigkeiten hinzuweisen; sie spüren also, wenn gerade eine neue Nachricht eingegangen ist oder sie während eines Workouts ein bestimmtes Ziel erreicht haben, selbst wenn die Apple Watch keinen Ton von sich gibt.
Ab watchOS 2 können Entwickler nun auch das Auslösen der Taptic Engine in eigenen Apps implementieren. Die Verwendung ist denkbar einfach: Die als Singleton ausgelegte Klasse WKInterfaceDevice verfügt seit watchOS 2 über die neue Methode playHaptic:. Sie ist für das Auslösen der Taptic Engine verantwortlich und erwartet einen Parameter vom Typ WKHapticType. Dabei handelt es sich um eine Enumeration, die über insgesamt neun vordefinierte Vibrationen mitsamt zugehörigem Sound verfügt. Diese vordefinierten Werte sind im Folgenden inklusive ihres Einsatzzweckes
beschrieben:
- Notification: Benachrichtigung über eine neu eingegangene Notification
- DirectionUp: beschreibt die Erhöhung eines bestimmten Werts
- DirectionDown: beschreibt die Verringerung eines bestimmten Werts
- Success: weist auf den Erfolg einer Aktion hin
- Failure: weist auf den Fehlschlag einer Aktion hin
- Retry: weist auf den Fehlschlag einer Aktion hin mit der Option, sie noch einmal direkt wiederholen zu können
- Start: deutet den Beginn einer Aktion an
- Stop: deutet das Ende einer Aktion an
- Click: weist auf einen Zwischenpunkt bei der Auswahl verschiedener Elemente hin
Um ein ganzheitliches Nutzererlebnis beim Verwenden der Apple Watch zu gewährleisten, legt Apple großen Wert darauf, dass die genannten Haptic-Types ausschließlich für den angedachten Zweck verwendet werden. Halten sich alle Entwickler daran, führt das dazu, das Nutzer selbst bei Verwendung ganz unterschiedlicher Apps bei Feedback mittels Taptic Engine unterscheiden können, um welche Art von Feedback es sich handelt.
Das folgende Listing zeigt ein paar beispielhafte Aufrufe zum Verwenden der Taptic Engine in eigenen watchOS-Apps.
class MyInterfaceController: WKInterfaceController {
func useTapticEngine() {
WKInterfaceDevice.current().playHaptic(.Notification)
WKInterfaceDevice.current().playHaptic(.Success)
WKInterfaceDevice.current().playHaptic(.Start)
WKInterfaceDevice.current().playHaptic(.Stop)
WKInterfaceDevice.current().playHaptic(.Click)
}
}
Neues Features: Audio, Video, Alerts
Audio und Video
Mit watchOS 2 ist es erstmals möglich, Audioaufnahmen direkt aus einer App heraus über die Smartwatch zu tätigen. Zu diesem Zweck stellt die Klasse WKInterfaceController eine neue Methode namens
presentAudioRecorderControllerWithOutputURL:
preset:options:completion: bereit, die das Standard-Interface zum Aufzeichnen von Aufnahmen einblendet und Nutzern die Aufzeichnung erlaubt. Dabei lassen sich für die Methode die folgenden Parameter setzen:
- URL: Hierbei handelt es sich um den Pfad zur Datei, die aufgenommen werden soll.
- preset: Dieser Parameter bestimmt die Qualität der aufzunehmenden Audiodatei. Es wird ein Objekt vom Typ WKAudioRecorderPreset erwartet. Dabei handelt es sich um eine Enumeration, die über insgesamt drei Werte verfügt (NarrowBandSpeech für einfache Sprachaufnahmen, WideBandSpeech, ebenfalls gedacht für Sprachaufnahmen, allerdings in etwas besserer Qualität, und HighQualityAudio für das beste Aufnahmeergebnis).
- options: Hierbei handelt es sich um einen optionalen Parameter in Form eines Dictionary, über den sich Einstellungen zur aufzunehmenden Datei festlegen lassen. Bisher stehen Schlüssel für insgesamt vier verfügbare Optionen zur Verfügung. WKAudioRecorderControllerOptionsActionTitleKey stellt den Titel dar, der während der Aufnahme auf dem Display der Apple Watch angezeigt wird. Die Option WKAudioRecorderControllerOptionsAlwaysShowActionTitleKey bestimmt, ob der anzuzeigende Titel immer auf dem Display der Apple Watch angezeigt werden soll oder erst, nachdem bereits ein wenig Audiomaterial aufgezeichnet wurde. Als Wert wird dabei ein Boolean in Form eines NSNumber-Objekt erwartet, der Default-Wert ist "true". WKAudioRecorderControllerOptionsAutorecordKey bestimmt, ob die Audioaufnahme direkt nach Anzeige des entsprechenden Interface-Controllers automatisch beginnt oder ob der Nutzer zunächst selbst den Start der Aufnahme aktivieren muss. Auch bei dieser Option erwartet das Dictionary einen booleschen Wert, der als NSNumber-Objekt umgesetzt ist. Der Standardwert ist "true". Zu guter Letzt lässt sich noch eine maximale Aufnahmezeit in Sekunden für die Audioaufnahme mithilfe der Option WKAudioRecorderControllerOptionsMaximumDurationKey festsetzen. Die maximale Dauer in Sekunden ist dabei in Form eines NSNumber-Objekts abzubilden.
Äquivalent dazu stellt die Klasse WKInterfaceController mit watchOS 2 eine weitere Methode bereit, um sowohl Audiodateien als auch Videos direkt über die Apple Watch abzuspielen. Ihr Name lautet
presentMediaPlayerControllerWithURL:options:completion:. Der Aufruf erfolgt mittels folgender Parameter:
- URL: Hierbei handelt es sich um die URL zur Datei, die wiedergegeben werden soll. Es kann sich dabei sowohl um eine reine Audio- als auch um eine Videodatei handeln.
- options: Ähnlich wie bei den Optionen für die Aufnahme von Audio handelt es sich auch an dieser Stelle um ein optionales Dictionary. Insgesamt stehen vier Schlüssel zur Verfügung, um die Audio- beziehungsweise Videowiedergabe anzupassen. Beispielsweise lässt sich mit der Option WKMediaPlayerControllerOptionsAutoplayKey festlegen, ob die Audio- oder Videodatei direkt abgespielt werden soll, nachdem der entsprechende Interface-Controller auf der Apple Watch angezeigt wurde; standardmäßig muss der Nutzer selbst noch einmal die Wiedergabe starten. Als Parameter ist hier erneut ein NSNumber-Objekt zur Abbildung eines booleschen Werts zu verwenden. Soll die Audio- oder Videodatei an einer bestimmten Position gestartet werden, lässt sich diese Position in Sekunden als NSNumber-Objekt für den Key WKMediaPlayerControllerOptionsStartTimeKey setzen, um das entsprechende Verhalten zu erzeugen. Und mittels WKMediaPlayerControllerOptionsLoopsKey kann man definieren, ob die Wiedergabe in einer Endlosschleife ablaufen soll (dazu wird erneut ein booelscher Wert in Form eines NSNumber-Objekt erwartet).
- completion: Dieser Block wird aufgerufen und ausgeführt, sobald die Wiedergabe der Audio- beziehungsweise Videodatei abgeschlossen ist. Dabei werden insgesamt drei Parameter übergeben, die sich als Grundlage für weitere Funktionen und Aktionen auswerten lassen. So gibt didPlayToEnd an, ob die Datei bis zum Ende betrachtet beziehungsweise angehört wurde, während endTime den genauen Zeitpunkt in Sekunden angibt, zu der die Aufnahme beendet wurde. error informiert überdies über Fehler und Probleme.
Apple macht es mit den beiden Methoden recht einfach, Medien in eigenen Watch-Apps zu verwenden beziehungsweise Audiodateien aufzunehmen. Durch Bereitstellen eines Standard-Interface-Controllers, der die jeweiligen Aufgaben auf optimale Weise übernimmt und unter watchOS ein bekanntes und einheitliches User Interface aufweist, können so auch Drittentwickler die vorgefertigten Interface-Controller nutzen und müssen sich nur noch um eine minimale Konfiguration und die Übergabe der jeweils korrekten URLs kümmern.
Wer lieber direkt ein Interface-Element zum Abspielen von Audio beziehungsweise Video in eigene watchOS-Ansichten einbauen möchte, kann das seit watchOS 2 ebenfalls tun, und zwar mithilfe der neuen Klasse WKInterfaceMovie. Wie alle anderen Interface-Elemente wird sie direkt auf der UI platziert und dient zur Wiedergabe von Audio- und Videodateien. In den Eigenschaften der Instanz dieser Klasse legt man dann fest, wie die URL zur Quelldatei lautet, welches Bild als Thumbnail angezeigt werden und ob die Wiedergabe in einer Endlosschleife erfolgen soll.
Jetzt auch bei watchOS: Alerts
Alerts sind unter iOS ein beliebtes Mittel, um dem Nutzer kurze Nachrichten und Meldungen zu präsentieren und einzelne Aktionen auszulagern. Ab watchOS 2 stehen Alerts – zumindest in einfacher Form – auch für Watch-Apps zur Verfügung und erlauben es erstmals, dem Nutzer Mitteilungen und Meldungen direkt aus der eigenen App heraus auf dem Display anzuzeigen, ohne dafür extra einen eigenen Interface-Controller erstellen und anzeigen zu müssen. Die Abbildung 1 zeigt den entsprechenden Ausschnitt und eine Übersicht zu Alerts aus Apples Entwicklerdokumentation.
Grundlage für Alerts unter watchOS ist erneut die Interface-Controller-Klasse WKInterfaceController. Mithilfe der Methode presentAlertControllerWithTitle:message:preferredStyle:actions: ist es möglich, einen sogenannten Alert-Controller auf dem Display anzuzeigen, der ganz ähnlich aufgebaut ist wie die Klasse UIAlertController unter iOS. Die ersten beiden Parameter der Methode – title und message – definieren den anzuzeigenden Text des Alerts. Der dritte Parameter preferredStyle ist vom Typ WKAlertControllerStyle und kann einen von drei Werten annehmen: Alert,
SideBySideButtonsAlert und ActionSheet. Der Style definiert, wie der Alert aussieht und wie er aufgebaut ist.
Jeder Alert muss mindestens einen Action-Button enthalten, den Nutzer ausführen können (und sei es nur, um den angezeigten Alert wieder auszublenden). Diese Buttons werden in Form von WKAlertAction-Objekten definiert und als Array dem vierten Parameter der Methode – actions – übergeben. Für jede WKAlertAction wird ein passender zugehöriger Button für das Alert erzeugt. Dabei gilt zu beachten: Hat man als Alert-Style SideBySideButtonsAlert gewählt, muss das actions-Array exakt zwei WKAlertAction-Objekte enthalten. Bei allen anderen Styles muss es über mindestens ein WKAlertAction-Objekt verfügen.
Eine WKAlertAction ist einfach aufgebaut. Die Klasse bringt lediglich einen Convenience Initializer namens initWithTitle:style:handler: mit, über den alle benötigten Eigenschaften einer Alert-Action
gesetzt und definiert werden. Der erste Parameter title entspricht dem Titel des Buttons, der für die Action im Alert angezeigt wird. Der zweite Parameter style ist vom Typ WKAlertActionStyle und erlaubt das minimale Anpassen der Optik eines Action-Buttons. Hierfür stehen die drei Werte Default,
Cancel und Destructive zur Verfügung. Destructive weist auf einen Action-Button hin, dessen Ausführung eine Löschung oder anderweitig "zerstörende" Funktion zur Folge hat, während Cancel für eine Abbruch-Aktion gedacht ist. Für den Rest gibt es Default.
Zu guter Letzt entscheidet der Parameter handler, was genau bei der Ausführung einer Action geschehen soll. Dabei handelt es sich um einen Block ohne Parameter und ohne Rückgabewert. Betätigt der Nutzer einen Action-Button aus einem Alert heraus, wird eben jener handler-Code des zugehörigen Buttons ausgeführt.
Das folgende Listing zeigt die beispielhafte Verwendung von Alerts und verdeutlicht die Syntax, die zum Erstellen und Anzeigen von Alerts unter watchOS zu verwenden ist. Die verschiedenen Actions der Alerts sind dabei absichtlich einfach gehalten und geben so lediglich jeweils eine einfache print-Anweisung aus.
func presentSideBySideAlert() {
let cancel = WKAlertAction(title: "Cancel", style: .Cancel,
handler: { () -> Void in
print("Cancel")
})
let action = WKAlertAction(title: "Action", style: .Default,
handler: { () -> Void in
(print"Action")
})
presentAlertControllerWithTitle("Side-by-side alert", message:
"Select an action.", preferredStyle:
.SideBySideButtonsAlert, actions: [cancel, action])
}
func presentActionSheet() {
let cancel = WKAlertAction(title: "Cancel", style: .Cancel,
handler: { () -> Void in
print("Cancel")
})
let delete = WKAlertAction(title: "Delete", style: .Destructive,
handler: { () -> Void in
(print"Delete")
})
presentAlertControllerWithTitle("Confirm deletion", message:
"Do you want to proceed?", preferredStyle:
.ActionSheet, actions: [cancel, delete])
}
Mehr Features
Weitere Möglichkeiten für Apps
Die zuvor aufgeführten Neuerungen und Änderungen beziehen sich allesamt auf Möglichkeiten innerhalb von watchOS-Apps. Sie haben direkten Einfluss darauf, welche Funktionen watchOS-Apps zur Verfügung stehen und was sich damit realisieren lässt. Es gibt aber noch weitere Mittel, um die eigene App für die Apple Watch anzupassen und zu optimieren.
Der wohl bekannteste Weg sind Notifications, und sie stellen in gewisser Weise auch ein Herzstück der Apple-Watch-Funktionen dar. Mit ihnen ist es möglich, Nutzer mit einer simplen Nachricht auf Erinnerungen hinzuweisen, an Termine zu erinnern oder eine neue Nachricht anzuzeigen. Notifications sind seit watchOS 1 essenzieller Bestandteil der Watch-Architektur und lassen sich genauso umfänglich wie unter iOS für die Apple Watch umsetzen und nutzen.
Ebenfalls seit watchOS 1 existieren die sogenannten Glances (im Deutschen auch als "Checks" bezeichnet). Dabei handelt es sich um eine separate Ansicht für die eigene App, die Nutzer aus dem Zifferblatt der Apple Watch heraus per Wischgeste von unten nach oben anzeigen können. Jede App kann maximal über eine Glance (man spricht auch von einer sogenannten Glance Scene) verfügen. Glance Scenes sind einfach gehaltene Ansichten, bei denen es keinen großen Spielraum für UI-Anpassungen gibt. Sie basierten auf einem von mehreren von Apple vorgegebenen Templates und können Text und Bilder anzeigen. Sie sind nicht scrollbar und somit auf den Platz des Displays beschränkt. Ein Tap auf eine Glance Scene öffnet immer die zugehörige und zugrunde liegend App auf der Apple Watch.
Glance Scenes dienen dazu, Nutzern schnell und übersichtlich die wichtigste Information der eigenen App zu präsentieren. Beispielsweise zeigt Apples Wetter-App in einer Glance Scene immer das derzeitige Wetter für den aktuellen Ort an. Möchten sie eine Vorschau für die nächsten Stunden und Tage oder das Wetter an einem anderen Ort erfahren, müssen sie in die eigentliche Wetter-App springen und von dort aus die gewünschte Information abrufen.
Ebenso wie Glance Scenes machen auch die mit watchOS 2 eingeführten Komplikationen nicht bei allen Apps Sinn. Bei ihnen handelt es sich um die Zusatzfunktionen und -elemente, die sich auf manchen Zifferblättern der Apple Watch platzieren lassen (beispielsweise das aktuelle Datum, die Mondphase, der Status des Aktivitätsziels und der Akkustand). Zwar existieren die Komplikationen an und für sich bereits seit watchOS 1, aber erst mit watchOS 2 können auch Drittentwickler eigene für ihre Apps anbieten. Grundlage dafür ist das neue ClockKit-Framework (s. Abb. 2).
Komplikationen sind sinnvoll, wenn die eigene App sich aktualisierende Informationen enthält und diese auf passende Art und Weise mittels einer kompakten Komplikation von einem Zifferblatt aus präsentiert werden können. Denn Komplikationen steht noch weniger Platz als Glances auf dem sowieso schon kleinen Watch-Display zur Verfügung. Informationen wie die aktuelle Temperatur sind dafür ideal geeignet und erlauben Nutzern, mit einem Blick auf ihr Zifferblatt die jeweils aktuelle Information einzusehen.
WatchKit Catalog
Neben den in diesem Artikel gezeigten Beispielen für die watchOS-Entwicklung, die allesamt ab watchOS 2 zur Verfügung stehen, bietet Apple ein eigenes Xcode-Projekt zum Download an, das alle grundlegenden Themen und Bereiche der Watch-Entwicklung beleuchtet und präsentiert. Das Projekt trägt den Namen WatchKit Catalog und lässt sich von Apples Entwickler-Website kostenlos herunterladen (auch ohne Mitgliedschaft in Apples Entwicklerprogramm).
Die App zeigt, wie man unter watchOS mit Labels, Slidern, Buttons und vielem anderen mehr arbeiten kann, eben all jenen grundlegenden Elementen, die seit watchOS 1 bereits zur Verfügung stehen. Da der Code zur Umsetzung der jeweiligen UI-Elemente ebenso direkt zur Verfügung steht, kann das den Einstieg in die Entwicklung für die Apple Watch deutlich erleichtern.
Fazit
Lohnt sich die watchOS-Entwicklung?
Die Apple Watch als Hardwareplattform und watchOS als Betriebssystem stehen noch ganz am Anfang. Es ist davon auszugehen, dass Apple gerade in den kommenden Jahren viel Zeit und Energie in die
Weiterentwicklung der Hardware und des Betriebssystems investieren wird, wozu auch immer neue Funktionen und erweiterte Möglichkeiten für Drittentwickler gehören werden. Allein der enorme Sprung von watchOS 1 auf watchOS 2 lässt erahnen, welche APIs Entwicklern in Zukunft noch zur Verfügung gestellt bekommen.
Nichtsdestoweniger ist watchOS eine gänzlich andere Plattform als iOS. Das liegt vor allen Dingen daran, das watchOS-Apps nicht vollständig autark funktionieren. Es braucht seit watchOS 2 durch die genannte Änderung der Architektur nicht mehr zwingend ein erreichbares iPhone, um eine watchOS-App auszuführen. Aber watchOS-Apps selbst sind immer Bestandteil einer iPhone-App. Und so ist auch watchOS als Plattform für App-Entwickler zu sehen. Die Apple Watch ist als erweiterter Arm des iPhone konzipiert, entsprechend sollten sich watchOS-Apps darauf konzentrieren, nur die wichtigsten Features und Funktionen zugänglich zu machen oder neue Zusatzfunktionen anzubieten, die auf dem iPhone keinen Sinn ergeben. Zu versuchen, eine iPhone-App in all ihren Funktionen auf die Apple Watch zu übertragen, dürfte in einem Großteil aller Fälle scheitern.
Apple selbst definiert für die Nutzungszeit von watchOS-Apps ein Zeitfenster von zwei bis fünf Sekunden. Im Vergleich zu iPhone, iPad oder gar Mac ist dieses Zeitfenster geradezu verschwindend gering. Doch jeder, der einmal eine beliebige Smartwatch über einen Zeitraum von mehreren Sekunden ununterbrochen benutzt hat, dürfte schnell merken, wie unangenehm die entsprechende Haltung des Armes auf Dauer wird. Deswegen müssen sich App-Entwickler ins Bewusstsein rufen, das watchOS-Apps dem Nutzer schnell und effizient zu seinem Ziel führen sollen; Finger weg also von überladenen UIs, vielen Auswahlmenüs und verschachtelten Listen. Auch wenn es technisch möglich ist, muss der Fokus bei watchOS-Apps auf reibungsloser und schneller Nutzung liegen.
Ob sich somit die Entwicklung für watchOS lohnt, hängt zunächst von zwei Faktoren ab:
- Gibt es bereits eine passende zugehörige iPhone-App?
- Gibt es bei dieser iPhone-App eine oder mehrere Funktionen, die sich sinnvoll auf die Apple Watch übertragen lassen?
Nur wenn sich die beiden Fragen mit "Ja" beantworten lassen, kommt überhaupt eine Entwicklung einer watchOS-Version einer bestehenden iPhone-App in Betracht. Dann lässt sich solch eine Watch-Variante tatsächlich als zusätzlicher Nutzen sehen, mit dem man womöglich langfristig die Downloadzahlen der eigenen App erhöhen kann.
Eine Apple-Watch-Version allein ist aber kein Heilsbringer für eine erfolgreiche App. Sie kann zwar Antrieb für erhöhte Downloadzahlen sein, eine grundlegend erfolgreiche iPhone-App wird aber nichtsdestoweniger noch immer eine größere und bedeutendere Rolle spielen. Möglicherweise ändert sich das langfristig, falls Smartwatches – und in diesem speziellen Fall die Apple Watch – mit der Zeit deutlich höhere Nutzerzahlen erreichen. Wer dann mit einer watchOS-App in den Startlöchern steht, hat gute Chancen auf einen großen Erfolg; ähnlich wie seinerzeit unter iOS.
Wie geht es weiter?
Artikel zum Thema auf heise Developer:
Unbestreitbar steht die Veröffentlichung der Version 3 von watchOS in den Startlöchern. Voraussichtlich im Herbst wird Apple die finale Version des nächsten Ablegers des Betriebssystems veröffentlichen und damit auch weitere Neuerungen und Features für Entwickler bereitstellen.
Zum jetzigen Zeitpunkt ist es aber zunächst für Entwickler wichtig, die Besonderheiten und die Architektur von Apps für watchOS 2 verinnerlicht zu haben. Da seit Juni nur noch Apple-Watch-Apps im App Store zugelassen werden, die mindestens watchOS 2 unterstützen, führt kein Weg für bisherige watchOS-Entwickler daran vorbei, sich spätestens jetzt im Detail mit dieser Plattform auseinanderzusetzen.
Wer bisher zwar eine iPhone-App, aber noch keine zugehörige watchOS-App entwickelt, sollte im Vorhinein genau prüfen, ob und in welchem Umfang ein Ableger einer solchen App für die Apple Watch sinnvoll ist.
Thomas Sillmann
ist leidenschaftlicher iOS-App-Entwickler und Autor. Freiberuflich entwickelt er eigene Apps für den App Store sowie Apps in Form von Kundenaufträgen. Mit seiner Begeisterung für das Schreiben hat er bereits mehrere erfolgreiche Fachbücher und Kurzgeschichten veröffentlicht. Sillmann lebt und arbeitet in Aschaffenburg.
Online-Quellen
(ane)
