WatchKit : Episode I – À la découverte de l’API

Après des mois d’attente et de folles rumeurs, Apple a finalement sorti le 18 novembre dernier son SDK WatchKit, le fameux sésame requis pour le développement d’applications compatibles avec les futures Apple Watch. Et tout comme pour l’annonce de Swift, la société de Cupertino n’a pas manqué de nous surprendre avec une vision bien différente de celle adoptée précédemment dans iOS.

À l’aide de cet article, le premier d’une courte série, vous découvrirez le fonctionnement et les APIs du SDK, ainsi que les dernières nouveautés d’iOS 8, telles que Framework Dynamiques et Extensions.

Architecture

WatchKit s’intègre au sein d’un projet iOS via l’utilisation des App Extensions, introduites dans iOS 8. C’est donc un prolongement de votre projet (pbx) comme peuvent l’être les tests unitaires.

Lorsque vous ajoutez une Watch App à votre application, Xcode ajoute deux nouvelles targets à votre projet :

• WatchKit iOS Extension, qui contient la logique de l’application
• Watch App, qui contient les ressources (Storyboard, images, …)

Ces deux targets produisent deux nouveaux binaires, qui peuvent être considérés comme des mini-applications indépendantes. Au moment de l’archivage, le processus de build crée un bundle contenant :

• Votre Application iOS
• WatchKit iOS Extension
• Watch App

Parmi ces deux dernières, seule la Watch App est effectivement installée sur l’Apple Watch. Par conséquent, toute l’intelligence contenue dans l’Extension est calculée sur le téléphone, qui s’occupera de transmettre les données pré-élaborées à la Watch App.

Le fonctionnement de cette architecture est expliquée dans l’image suivante, issue de la documentation officielle Apple.

Interface utilisateur

Malgré le fait que les Watch App fassent parties de l’eco-système iOS, Apple nous fait ici sa première surprise : réaliser une interface ne ressemble en rien à ce que l’on fait habituellement sur iOS !

En effet, sachez tout d’abord que vous devez obligatoirement utiliser les storyboard pour mettre en place votre UI. Avec WatchKit vous ne pourrez pas utiliser les NIB ni créer programmatiquement des objets UIView.

Ce choix se retrouve au final très peu impactant, étant donné que les Watch Apps sont censées être une version allégée de votre application native avec très peu de vues.

Le système de layout employé sur les Apple Watch n’est ni de l’AutoLayout ni de l’AutoResizingMask. À la place, Apple a choisi une troisième solution qui ressemble au LinearLayout Android, sans en être toutefois une copie.

Son fonctionnement est assez simple et basé sur le concept de stack : à chaque fois que vous ajoutez un élément dans la hiérarchie, celui-ci s’affiche en dessous des précédents, créant une pile. Vous pouvez ensuite changer ses attributs pour modifier sa position, ou bien encore ajouter des espaces entre les éléments.

Vous avez également la possibilité d’utiliser des Groups qui vous permettront d’organiser plusieurs éléments ensemble ou encore de les positionner de manière horizontale.

Malgré le fait que ce nouveau système soit moins puissant que l’AutoLayout, cela ne l’empêche pas d’avoir de nombreuses qualités, non négligeables :

1. Une prise en main simple et rapide
2. Réaliser une UI se veut beaucoup plus rapide qu’avec AutoLayout
3. La root view est scrollable : quand la taille du contenu est supérieure au containeur, il est possible de défiler l’écran sans besoin de mettre en place un UIScrollView
4. Cacher un élément (via la méthode setHidden) le retire du flow du layout, exactement comme si celui-ci n’avait jamais existé. Un vrai changement par rapport à AutoLayout !

Ce dernier point est très important puisque, parmi les points faibles de cette version de WatchKit, on citera le fait qu’on ne puisse pas ajouter ou supprimer d’éléments au runtime. Vous devrez donc avoir prévu toute votre UI dans votre storyboard et cacher/afficher les différents éléments selon les données reçues.

WKInterface*

Comme pour AutoLayout, Apple a décidé de remplacer UIView et UIViewController par deux autres composants: WKInterfaceObject et WKInterfaceController.

La « disparition » de l’objet s’explique par le fait que WatchKit ne permet pas d’instancier manuellement des objets UIView ; à la place, les composants que l’on manipule depuis l’Extension (boutons, labels, images et autres) sont des proxies sur les UIView allouées dans Watch App. Ce sont les fameux WKInterfaceObject.

Cette limitation vient du fait que l’UI est gérée depuis la montre (par Watch App)  alors que la logique est exécutée sur le téléphone (par l’Extension).

De la même manière, WKInterfaceController retire toute référence aux UIView : pas de propriété view ni de selector initWithNibNamed:. Seuls les IBOutlet (sur des WKInterfaceObject) sont de la partie. Le rôle d’un WKInterfaceController reste néanmoins sensiblement le même que celui d’un UIViewController:

• Récupérer des données depuis un serveur distant
• Mettre à jour l’UI via les propriétés des WKInterfaceObject
• Contrôler le cycle de vie d’une view à l’aide des méthodes willActivate et didDeactivate (analogues aux méthodes viewWillAppear et viewDidDisappear de UIViewController)
• Gérer la pile des controller (push/pop). Ce rôle, en partie dévolu à UINavigationController dans iOS, est ici entièrement géré par WKInterfaceController
• Définir les valeurs initiales des composants. Cette partie est simplifiée grâce au constructeur initWithContext: qui permet de passer des données au WKInterfaceController à sa création

Plus d’info sur cette classe dans la doc Apple sur WKInterfaceController 

Conclusion

À l’aide de cet article introductif nous avons décrit l’architecture et les APIs principales de WatchKit.
Les contenus sont aussi disponibles au format vidéo ou bien sous forme de slides, issus du TechEvent Xebia du 3 décembre dernier.

Dans le prochain article nous vous montrerons comment réaliser une première application Apple Watch.