Apple Watch – Que nous promet-elle?

Le 9 septembre 2014, Apple présentait à Cupertino, son cru 2014 d’iPhone : les iPhone 6 et 6 Plus. Ces iPhone constituaient déjà une belle rupture pour Apple, avec enfin des écrans dignes de notre époque. Mais cela ne suffisait pas à Apple, qui en a également profité pour lever le voile sur un produit totalement nouveau : l’Apple Watch.

AppleWatch - Tim Cook

L’Apple Watch n’était pas disponible après la Keynote, et ne l’est toujours pas aujourd’hui. Sa sortie est annoncée pour la fin du premier trimestre 2015, sans doute uniquement aux États-Unis dans un premier temps. Pire que cela, les informations que nous avions jusqu’à récemment sur l’Apple Watch étaient très parcellaires, concernant uniquement certains écrans et quelques fonctionnalités phares. Cet état des lieux rendait très difficile pour les développeurs d’imaginer ce qu’ils pourraient faire avec la montre. Mais ça, c’était avant…

WatchKit SDK

 

En novembre, Apple a enfin fourni aux développeurs WatchKit, l’API permettant de développer des applications pour l’Apple Watch. Ou plutôt, des extensions d’applications iPhone pour l’Apple Watch, car il est aujourd’hui impossible de développer des applications autonomes pour la montre.

Que peut-on faire avec l’Apple Watch

La première question qui se pose donc à la découverte de ce SDK est claire : que peut-on faire avec l’AppleWatch ? La réponse est courte : pas grand chose. Le SDK est aujourd’hui relativement limité, et nos designers vont devoir s’adapter à un écran beaucoup plus petit que ce à quoi ils ont l’habitude. Nous allons étudier plus précisément   les différentes interactions possibles avec la nouvelle invention de la marque à la pomme.

L’interface graphique

L’interface graphique est le point le plus délicat à définir quand on travail avec une montre, quelque soit son écosystème. En effet, nos designers doivent s’adapter à des écrans d’une taille autour de 1,5″ alors que depuis quelques années, ils travaillent avec des écrans de taille supérieure à 4″. Pour cela, Apple a décidé de mettre en place une interface entièrement tournée autour du scroll. Comme on le fait sur iOS depuis iPhoneOS 2.0, une grosse partie de l’interface est basée sur un scroll vertical. Le SDK mis à disposition des développeurs est donc basé sur un principe d’empilement des éléments les uns en dessous des autres.
Il est également possible de mettre certains éléments les uns à coté des autres grâce aux groupes. Cet élément devra être utilisé avec parcimonie, pour éviter de charger trop l’interface graphique d’un élément aussi petit.

La navigation

Sur ce point, Apple innove, et n’hésite pas à le rappeler. Il s’agit de remettre en place quelque chose présent depuis le début de l’horlogerie : la molette. Cette molette permet de faire défiler horizontalement l’écran de la montre, comme il est possible de le faire avec un swipe vertical. Cette molette est mise en place pour une raison simple : Apple estime qu’il n’est pas pratique sur un écran aussi petit de faire un swipe avec les doigts. Et après avoir utiliser pendant quelques temps une montre Android, on ne peut que leur donner raison : le swipe n’est pas adapté à une montre. Reste à voir si le choix d’Apple est le bon! Nous pourrons répondre à cette question dès lors que nous aurons la montre finale entre les mains.

Les applications et le Store

Comme nous l’avons évoqué précédemment, il sera impossible dans un premier temps pour un développeur lambda de développer des applications standalone pour la montre. Les applications seront donc uniquement des extensions d’applications existantes, comme le sont aujourd’hui les widgets, les claviers, ou les extensions de partage. L’intelligence de l’application ne se trouvera donc pas dans la montre, mais dans le téléphone ; la montre se contentant de l’affichage. Cela soulève immédiatement deux points, extrêmement importants pour bien comprendre comment appréhender cette montre :

  • Les traitements se faisant sur le téléphone, le processeur et la batterie de la montre seront économisés. On peut donc se permettre de faire des traitements relativement couteux dans les extensions pour la montre, sans se soucier de la faible capacité de traitement de cette dernière
  • L’Apple Watch va vite perdre de son utilité sans iPhone (et spécifiquement iPhone) à proximité : à part afficher l’heure, elle ne pourra pas faire grand chose. La très grande partie de l’intelligence et des capteurs de l’Apple Watch sont en fait fonction… du téléphone utilisé.

Il faut donc bien considérer cette montre comme une extension de son iPhone. Elle ne sert à rien sans lui, tout du moins dans cette première version. A partir de là, les applications Watch sont à mettre en parallèle des widgets du panneau aujourd’hui : une interface qui doit être dénudée, un traitement qui doit être rapide pour un affichage immédiat, et une utilisation comme affichage complémentaire de son application compagnon.

On va par exemple utiliser la montre pour afficher des notifications de l’application, pour afficher des informations géolocalisées pertinentes, ou encore pour un traitement minimal sur les données de l’application.

Ainsi, nous avons un fort potentiel sur l’Apple Watch, mais le travail va surtout être pour nos ergonomes et nos designers. Leur challenge va être de réussir à proposer des applications adaptées à un usage dont nous n’avons aujourd’hui pas l’habitude. Chez iD.apps, notre équipe d’ergonome est impatiente de pouvoir tester ces nouvelles possibilités.

FX

 

Retour de WWDC (2/2) : Regard à froid sur les annonces

Le D de WWDC = “Developer”.

Tous les ans, durant la WWDC Apple présente à ses développeurs enregistrés les nouvelles API et fonctionnalités qu’ils pourront utiliser quelques semaines plus tard.

Il y a néanmoins un moment de la WWDC qui n’est traditionnellement pas réservé aux développeurs : la keynote d’ouverture. Cette dernière est l’occasion pour Apple de présenter à la presse ainsi qu’au grand public les nouveautés fonctionnelles des prochaines versions d’iOS et de OSX, ainsi que des principaux logiciels de la firme.
Bien que ce fût encore le cas cette année, cette keynote a eu un goût particulier pour les développeurs. En effet, plus du tiers de cette keynote leur était réservé. Alors que le grand public a regardé de façon étonnée, sans trop y comprendre grand chose, cette fin de keynote, pour les développeurs, l’excitation est tout de suite montée, et l’on pouvait s’attendre à un très grand cru 2014 de la WWDC. Vous trouverez dans cet article uniquement les nouveautés intéressant les développeurs iOS. Je n’évoquerai donc pas, ou très peu, les nouveautés concernant uniquement les utilisateurs (notifications interactives, App Preview, …).

Swift, bien sûr

L’annonce la plus importante de la keynote de la WWDC, pour les développeurs, fût bien évidemment l’arrivée de Swift : un langage de programmation entièrement nouveau.

swift-logo-hero

Pour comprendre le pourquoi de Swift, il faut faire un peu d’histoire. En 1996, alors qu’Apple est au bord du gouffre, la société rachète NeXT fondée par Steve Jobs, pour fournir un nouveau système d’exploitation aux Macintosh. NextSTEP, le système d’exploitation de NeXT évoluera vers Mac OSX, puis vers OSX. En plus de ce système d’exploitation, Apple récupère le langage utilisé pour toutes les API de NextSTEP : l’Objective-C.
L’Objective-C est, comme le C++, une surcouche du C. Il est donc compatible avec ce dernier. Il est en revanche beaucoup plus confidentiel que le C++. Bien que GCC et d’autres compilateurs populaires sachent très bien compiler du code Objective-C, aucun système d’exploitation, mis à part OSX et iOS, ne propose d’API Objective-C, cantonnant par la même l’Objective-C à l’écosystème Apple. L’Objective-C est de plus un langage à la syntaxe très particulière, et très éloignée de tout ce que les développeurs ont l’habitude de voir. Bien que les développeurs familiers avec Objective-C apprécient énormément cette syntaxe, elle pose un frein énorme à l’entrée vers la plateforme. En effet, il est beaucoup plus facile de former, par exemple, un expert Java vers le C++ (ou vice-versa) que vers l’Objective-C. L’Objective-C porte également le poids de son héritage : le C, langage développé dans les années 70, dont il ne peut se défaire, malgré de nombreuses lourdeurs telles qu’une gestion problématique du multi-thread, une gestion complexe et entièrement manuelle de la mémoire, un typage faible, …
Depuis plusieurs années, Apple travaille à corriger ces derniers points en masquant la complexité du C aux développeurs, avec par exemple Grand Central Dispatch pour la gestion du multithread, ou l’Automatic Reference Counting pour la gestion de la mémoire.
Malgré tous ces efforts, Apple ne peut que masquer cette lourdeur du C, sans la supprimer entièrement, et ne résout pas le problème de la difficulté d’accès à la syntaxe de l’Objective-C.

Enters Swift

Le but de Siwft est exactement celui-ci : fournir un langage moderne, rapide, puissant, et léger avec une syntaxe proche des langages de script populaires d’aujourd’hui.

Une évolution en douceur

Apple a l’habitude des évolutions matérielles ou logicielles lourdes : que ce soit au niveau du passage des API Carbon vers Cocoa, de l’architecture PowerPC vers X86, ou encore X86 vers ARM, Apple a fait un grand nombre de switch que la concurrence est bien souvent incapable de mener à bien. Afin de s’assurer que les développeurs réussiront à passer vers Swift en douceur, et sans avoir à réécrire tout leur code, Swift est entièrement inter-opérable avec le code Objective-C existant. Pour faire simple : on peut rajouter du code Swift dans une application Objective-C, et on peut rajouter du code Objective-C dans une application Swift. Dans la pratique, malgré quelques problèmes (voir plus bas), cette intégration se passe sans que le développeur s’en rende compte, et permet aux développeurs de se mettre immédiatement au Swift, y compris sur des projets pré-existant.

Un langage optimisé

Swift a été développé sous la direction de Chris Lattner, le créateur de Clang et LLVM, depuis 2010. En éliminant la lourdeur historique du C, l’équipe de Lattner a réussi à créer un langage particulièrement efficace. Apple parle de gain de performances de 20 à 30% entre Objective-C et Swift.
Bien que nous n’ayons pas obtenu de chiffres aussi spectaculaires, nous avons pu, dans nos propres tests, atteindre facilement les 15% d’amélioration de performances.
Ce gain de performances tient autant de l’optimisation de LLVM à Swift, que des fonctionnalités intrinsèques du langage. Toutes les fonctions extrêmement consommatrice en cycles CPU ont été optimisées avec Swift. Nous pouvons nous en rendre compte ainsi dès la première ligne de code : les boucles, les switch de thread, la gestion des compteurs, … sont fait de manière extrêmement moderne, les rendant facile à coder, et optimaux dans leur exécution.

Un langage simple

Vous n’aimez pas les .h ? Moi non plus, comme la plupart des développeurs de moins de 50 ans. Bien que ces fichiers de header aient été obligatoires pour déclarer l’interface d’une classe dans les années 70, pour séparer le code exécutable des simples déclarations, cela fait très longtemps que ce n’est plus le cas. Tous les langages modernes, Java, C#, Ruby, Perl, … se passent de ces fichiers de header, et c’est naturellement le cas pour Swift. La déclaration et l’implémentation sont maintenant réunies dans un même fichier. Et, comme pour tous les langages modernes, les développeurs n’auront pas à regarder ces fichiers, mais uniquement la documentation générée pour savoir utiliser les API.
Swift supprime également, du moins en surface, les pointeurs. Le développeur n’a plus à s’occuper de la gestion de la mémoire. Cette suppression reste néanmoins uniquement une suppression en surface. Il est en effet indispensable, pour des fonctionnalités de bas niveau, de reprendre la main sur la gestion de la mémoire, et Swift laisse cette possibilité aux utilisateurs avancés.
Un autre point très important pour la simplicité d’utilisation de Swift est la syntaxe du langage en elle même. Alors que l’Objective-C prenait clairement une approche très différente des autres langages, la syntaxe de Swift est, pour sa part, très proche de celle des autres langages utilisés aujourd’hui. Cela pour permettre aux développeurs de rapidement se l’approprier.

Un langage sûr

Un des mots clefs du développement de Swift a certainement été le typage. Contrairement au C et à l’Objective-C, Swift est un langage extrêmement typé : dès la déclaration d’une variable ou d’une constante, cette dernière est typée, et il est impossible de modifier son type.
Ce typage peut être fait de façon dynamique, en affectant une valeur à la variable dès sa déclaration (si on met une String dans une variable à sa déclaration, on ne pourra pas y mettre un int à posteriori), soit de façon statique, en précisant le type de la variable lors de sa déclaration.
Ce typage s’étend à tous les types : une classe, une énumération, un protocol, … sont tous typés et peuvent tous être stockés dans des variables. Cette approche permet de très facilement stocker n’importe quel type dans une variable : un type primitif, un objet, ou même une classe, une méthode, ou un protocol.
La vérification de type étant faite dès la compilation, le développeur est immédiatement averti lors d’une erreur de typage.

To be nil or not to be nil

Swift n’aime pas le nil, mais alors pas du tout. Il n’aime tellement pas le nil, qu’il est impossible pour une variable, ou une constante, d’être nil. Il y a là un avantage indéniable : fini les tests systématiques d’existence d’une variable, et surtout, fini les accès à des variables non initialisées, entraînant les tant redoutés segfault (que nos amis Javaistes connaissent mieux en tant que NullPointerException).
En revanche, un nouveau problème se pose bien évidemment : comment avoir une variable sans valeur? Nous avons tous, dans nos expériences de développeur, eu besoin de variables qui, a un moment ou a un autre, ne seront pas initialisées. Avec Swift, cela reste bien évidemment possible avec les variables optionnelles. Celles-ci sont un peu particulières dans le sens ou elle contiennent une énumération à deux états : None ou Any. Dans le cas None, la variable est vide, dans le Cas Any elle contient une valeur, encapsulé dans le Any. Pour une variable optionnelle, le développeur devra obligatoirement (sinon le compilateur le “gronde”) vérifier si elle est None ou Any avant son utilisation.

Un langage et des outils très jeunes

Tout n’est malheureusement pas rose dans le joli monde de Swift. Loin de là.
Swift est un langage extrêmement jeune, et certainement pas encore mature. La dernière béta en date (béta 3 à l’heure de la rédaction de ces lignes) le montre avec un changement en profondeur de certains éléments de syntaxe. Ces changements nous ont fait, chez iD.apps, repousser notre date de démarrage des développements en Swift : nous ne voulons pas perdre de temps à créer du code qui ne compilera plus en septembre.
Un autre point montrant la jeunesse de Swift est le manque de certaines fonctionnalités fondamentales. Il est par exemple impossible, aujourd’hui, de déclarer des variables privées en Swift.

chat_schrodinger

Enfin, les outils de développement ne sont aujourd’hui absolument pas au niveau. Nous avons l’habitude des beta de Xcode difficilement utilisables. Avec Xcode 6, Apple franchit un nouveau pas : nous sommes au niveau du chat de Schrödinger : il est impossible de savoir, avant de compiler son code, si ce dernier va compiler ou non. Ce problème vient principalement de l’intégration entre Swift et Objective-C. Pour pouvoir faire ces intégrations, Xcode crée des header permettant de faire le bridge entre les deux langages. Dans certains cas, ce bridge fonctionne très bien, et tout va pour le mieux dans le meilleur des mondes. Dans d’autres cas, nous nous retrouvons obligé de supprimer les fameux DerivedDatas pour réussir à compiler. Et dans le pire des cas, le chat est mort : nous n’avons pas réussi à faire fonctionner les header de bridge sans refondre en profondeur le projet.

Au final Swift est un langage extrêmement prometteur. Ses défauts de jeunesse ne remettent absolument pas en question le fait qu’il sera très clairement utilisé par une majorité de développeurs, et ce dès cette année.

Il n’y a pas que Swift dans la WWDC

Bien que Swift ait occupé une grande partie de notre temps à la WWDC, et de nos tests depuis, il est très loin d’être la seule nouveauté importante proposée par Apple lors de cette semaine.

CocoaTouch, revu et corrigé

Encore un peu d’histoire ici. Apple a créé le premier iPhone avec une taille de 3.5″ en 2007. Cette taille, considérée comme énorme à l’époque pour un téléphone, est devenue ridicule au fil du temps. Apple a donc créé un nouvel iPhone, à peine plus grand, en 2012, de 4″. Entre temps une nouvelle famille d’appareil iOS est apparue : l’iPad, avec une taille de 9.7″ (et son corollaire mini de 7.9″). Nous le savons déjà : nous aurons cette année de nouvelles tailles des périphériques : l’iWatch (ou autre nom) d’un écran qui sera à priori autour de 2″, et les nouveaux iPhone, avec des tailles autour de 5″. Je vois déjà les développeurs Android dans le fond se mettre à rigoler doucement : la fragmentation arrive chez Apple.

semi-restore-restore-iOS-device-without-loosing-jailbreak-FSMdotCOM

Alors que nous avions, hier, à gérer deux tailles d’écrans : 3.5″ et 9.7″, et avant-hier une seule avec le 3.5″, nous aurons demain à en gérer 7 : 3.5″, 4″, 5.x” et 6.x” pour les nouveaux iPhone, 9.7″ et 7.9″ pour les iPad, et 2.x” pour la montre. Il est évident que nous allons devoir changer notre méthode de développement des interfaces graphiques.
Et heureusement, encore une fois, Apple a pensé à nous, et y a même pensé en avance. Depuis 2012 et iOS 6, nous pouvons utiliser des contraintes pour designer nos interfaces graphiques. iD.apps y est passé depuis 2012, et j’espère que c’est également le cas pour vous, sinon le passage de l’hiver 2014 risque d’être difficile.
Les contraintes permettent de spécifier le positionnement des éléments à l’écran, non pas de façon absolue, ou uniquement en fonction de leur conteneur, comme dans les versions précédentes d’iOS, mais les uns par rapport aux autres. L’utilisation des contraintes est relativement difficile à appréhender, mais une fois le concept maitrisé, il est d’une puissance sans pareil.
Avec iOS 8, Apple propose une nouvelle abstraction : les rapports de taille. On peut maintenant designer dans Xcode des XIB un peu particuliers : des XIB carrés. Ces XIB carrés signifient une chose et une seule : ils ne sont pas spécifiques à une catégorie d’appareils, mais représentent une interface commune à tous les appareils. Les éléments et contraintes rajoutés dans ces XIB carrés seront les mêmes pour toutes les interfaces.
Vous savez, néanmoins, qu’il est impossible de faire la même interface pour tous les périphériques : iPad, iPhone, et iWatch. Ces nouveaux XIB carrés permettent de le faire.
Comme pour les contraintes, il va falloir apprendre une nouvelle gymnastique. Ces XIB génériques permettent, en fonction des tailles, de définir des contraintes, des éléments, des placements spécifiques. Les tailles sont définies en fonction de la hauteur et de la largeur, en Small ou Regular. En jouant sur toutes ces tailles, il va être possible de définir une interface très personnalisée à chaque taille d’écran, et ce dans un seul et unique XIB.
La gestion des tailles d’écrans n’est bien sûr pas limitée aux XIB, et tout peut également être géré depuis le code. Les différentes classes de taille sont accessibles dans le code, et on peut interagir avec à souhait. Il est par exemple possible dans une animation de savoir si on devient Regular en largeur, et de faire l’animation convenant.

Une autre nouveauté intéressante proposée par le SDK 8 est la réunification des différents contrôleurs iPad et iPhone. Nous pouvons ainsi utiliser un SplitViewController sur un iPhone. Sur iPad, le SplitViewController se comportera exactement comme aujourd’hui. Sur iPhone en revanche, la vue Master s’affichera en tant que RootViewController d’un NavigationController, et les vue détails seront poussées sur ce NavigationController. Il est également possible de faire des UIPopover sur iPhone : ces dernières s’afficheront en modale sur l’iPhone, alors qu’elles continueront à s’afficher normalement sur iPad.
Tous ces changements sont clairement faits pour faciliter le développement d’applications sur plusieurs types de périphériques, et à l’usage, c’est extrêmement agréable.

iCloudDrive et CloudKit

Depuis 2007, les développeurs et les utilisateurs critiquent ouvertement la fermeture d’iOS, et en particulier la quasi-impossibilité des applications de discuter entre elles. iCloudDrive, avec les extensions, sont deux grands pas vers la communication inter-applications dans iOS 8.
Alors que iCloud, depuis iOS5, permettait aux applications de lire et de sauvegarder uniquement leurs propres données, avec iCloudDrive, les applications peuvent enregistrer des documents, qui pourront être lues par n’importe quelle autre application gérant le format.

apple-to-challenge-dropbox-and-box-with-icloud-drive

Sur le papier il s’agit d’une excellente fonctionnalité. Dans la réalité, Apple retombe dans ses vieux démons. Toutes les solutions Cloud d’Apple, que ce soit d’abord MobileMe, puis iCloud et maintenant iCloudDrive ont eu des démarrages plus que laborieux : perte de connexion, perte de données, données à moitié synchronisées…
Dans le cas de iCloud, malheureusement, il n’y a pas le démarrage qui fût laborieux laborieux… Bien que les choses soient un peu mieux depuis un an, les développeurs se sont tous détournés de l’utilisation de iCloud pour passer par des services tiers, tellement la qualité de services était mauvaise. Nous sommes aujourd’hui avec iCloudDrive dans le même cas. Nous sommes bien sûr qu’au début de la technologie, mais il va falloir qu’Apple inverse sérieusement la tendance si la société ne veut pas que sa technologie soit complètement inutilisée par les développeurs.

CloudKit pour sa part est un MBAAS, comme Parse et d’autres. Il a l’avantage d’être gratuit pour une application de taille moyenne. Comme pour iCloudDrive, sur le papier il est excellent, mais à l’utilisation pas encore suffisamment fiable.

Extensions

Les extensions sont un nouveau moyen d’étendre les fonctionnalités du système. Apple a introduit quatre types d’extensions avec le SDK 8. Toutes ces extensions ont deux points communs : elles sont livrées avec une application, et ne peuvent pas communiquer directement avec cette application (ce sont deux binaires différents, s’exécutant dans des espaces mémoire différents). Elles peuvent en revanche avoir accès aux données de l’application.

1402068118-Screen Shot 2014-06-06 at 05.20.12 PM-2

Les widgets

Attention les amateurs d’Android, je vous vois encore ricaner dans le fond! Les widgets d’iOS 8 ne sont clairement pas comparables avec ceux d’Android. Alors que sur Android on peut rajouter des widgets absolument n’importe où, sur iOS cela ne sera qu’à un seul endroit : dans le panneau Aujourd’hui. Les widgets permettront de fournir des informations, comme des itinéraires, des images, des infos météo…
A l’utilisation, mis à part sur la beta 3 extrêmement bugée, les widgets sont très faciles à développer. Composés d’une seule vue, de préférence simple, ils ont comme seule contrainte de devoir se charger très rapidement, pour fournir aux utilisateurs une expérience optimale.

Les extensions de partage

Les extensions de partage étaient très attendues. Elles permettent, comme sur Android, de fournir un service centralisé de partage. En s’enregistrant comme extension de partage, les utilisateurs pourront utiliser votre service de partage de photos, vidéos, textes, … depuis n’importe quelle application utilisant la popup de partage du système, et ce sans aucune modification de l’application utilisant la popup de partage.
Les extensions de partage peuvent utiliser l’interface native proposée par le système, ou fournir leur propre interface graphique. Leur développement est relativement aisé, mis à part la validation des données à partager et le partage de plusieurs données.
Pour le premier point, la validation des données à partager est étonnamment compliquée de la part d’Apple. Toutes les données sont à désencapsuler et convertir, avant de voir si elle seront compatibles avec notre service de partage. Pour le deuxième point, l’upload des données passent par les services en background d’Apple (ce qui est une très bonne chose). L’extension se faisant tuer pratiquement dès sa fenêtre fermée, il est impossible de faire les upload directement depuis l’extension. Dans le cas où nous avons plusieurs données à partager, il faudra donc lancer plusieurs tâches d’upload en background.

Les extensions Safari

Les extensions de Safari permettent d’interagir directement avec le navigateur. 1Password l’utilise par exemple déjà dans sa dernière beta pour remplir automatiquement les mots de passe sur les pages Web.

En plus de ces trois types d’extensions, Apple a ajouté une extension permettant d’ajouter directement des filtres aux images.

TouchID

Lors de la présentation de l’iPhone 5S, la première question que nous avons reçue de la plupart de nos clients était : “pourrais-je l’utiliser dans mon application“. La réponse était malheureusement non à l’époque.

iphone-touch-id-logo

A partir du SDK8, cela sera maintenant possible. La technique va même plus loin que TouchID : il sera possible d’utiliser le mot de passe du périphérique pour déverrouiller des fonctionnalités de l’application.
Dans la technique, tout cela passe par la keychain. Les développeurs peuvent maintenant stocker des informations dans la keychain qu’ils définiront comme nécessitant l’authentification de l’utilisateur. Quand l’application souhaite accéder à ces données, le système demandera automatiquement à l’utilisateur son empreinte ou son mot de passe. Si la mauvaise empreinte, ou le mauvais mot de passe, est saisi, l’application n’aura alors pas accès aux données protégées.

Home Automation

Avec Home Automation, Apple veut faire son entrée dans la domotique, et pas par la petite porte. Home Automation n’est pas une application, mais un framework, permettant d’interagir avec le matériel compatible.
Home Automation a l’avantage d’utiliser une base de données unifiée. Après avoir rajouté un matériel, et réglé ce dernier, dans une application utilisant Home Automation, il sera disponible, et avec ses réglages, dans toutes les autres. Il sera donc possible de choisir de changer d’application frontend de Home Automation sans perdre toute sa configuration.

screen-shot-2014-06-02-at-11-36-26-am

Home Automation est composé, dans l’ordre : de maisons, de pièces, et d’équipements (chaque pièce fait partie d’une maison, et chaque équipement d’une pièce). Ce groupement permet de faire des actions automatisées comme éteindre toutes les lumières d’une maison, ou fermer tous les volets électriques d’une pièce, …
L’intégration avec Siri marche extrêmement bien. Nous n’avons pu la tester que via le simulateur d’équipement (il n’y a pas, à notre connaissance, de périphériques Home Automation sur le marché), et nous avons facilement pu dire à notre Smartphone d’ouvrir notre portail, ou d’éteindre toutes nos lumières.

Cet article ne se veut pas exhaustif : il a pour but de vous présenter ce que nous considérons comme le plus important de la WWDC. Il nous serait impossible sur un seul article de vous parler de tout ce que nous avons appris pendant cette WWDC, qui s’est avéré être un excellent cru.