Android Makers – Business Technology

05Nous y étions !

Cette année se tenait la première édition de Android Makers, la conférence remplaçant la célèbre Droidcon paris. Organisée par la même formidable équipe, nous nous devions de sponsoriser l’événement !

Durant deux jours, iD.apps était présent, aussi bien dans l’espace sponsors que dans les conférences. Nos développeurs ont pu assister à de nombreuses sessions, toutes plus intéressantes les unes que les autres.

C’était également l’occasion d’échanger avec d’autres équipes, voir d’autres manières d’envisager nos développements, et faire le plein d’idées et de nouvelles technologies pour l’année à venir. Le tout alimenté par Google qui fournissait même le nougat !

Nous organisions également un jeu concours pour faire gagner deux Nvidia Shield ! De nombreux candidats assoiffés de devices Android sont venus tenter leur chance, mais il ne pouvait y avoir que deux vainqueurs ! Chet Haase de Google (est-il encore besoin de le présenter ?) à même participé au second tirage au sort à la fin de la conférence.

Nos top picks

Un certain nombre de conférences nous a particulièrement plu, et nous avons donc demandé à chacun de nos développeurs présents de choisir sa session préférée et nous en parler !

 

The ART of organizing resources

 

On accorde souvent beaucoup d’importance à l’architecture d’un projet et à son organisation. Malheureusement il n’est pas rare de voir des projets où la partie Java est bien organisée et les ressources un vaste chaos. Jeroen Mols (Android developer pour Phillips Hue) nous a proposé une bonne manière d’organiser les ressources. Ce fut intéressant de voir que certaines pratiques que l’on utilise chez iD.apps étaient reprises dans sa présentation. Il a terminé sa conférence avec une cheat sheet que je partage avec vous :

 

Jérémy

Launch Screens: From a Tap to Your App

Cette session mettait en avant les différentes cinématiques de lancement d’une application Android. Elle était proposée par Cyril Mottier, qu’on ne présente plus dans la droidsphère française.

On y découvre la comparaison de deux philosophies de lancement d’applications Android : l’écran de démarrage – splash screen ou branded launch – et l’écran de substitution – ou placeholder screen. Nous y avons découvert les différents critères, liés à l’expérience utilisateur ou au marketing, qui peuvent amener à choisir l’un ou l’autre.

Si vous souhaitez vous-même vous pencher sur la question, Cyril Mottier entre également en détails dans la chronologie du lancement d’une application. Il y indique la marche à suivre pour mesurer le résultat en terme d’expérience utilisateur d’un lancement rapide du squelette de votre application.

Enfin, vous y trouverez une façon de réaliser votre propre placeholder UI, et ainsi donner l’impression à vos utilisateurs que votre application se lance en quelques centaines de millisecondes.

 

Pierre

The Fabulous Journey to Material Design Award

La première journée se terminait en apothéose avec une conférence du célèbre Taylor Ling (qui a même eu l’amabilité de dessiner les t-shirts de la conférence, nous sommes tous fans chez iD.apps !). Il présentait l’application Fabulous qui a reçu un Material Design Award l’an dernier, et les principes utilisés lors de la conception.

J’ai trouvé son approche très intéressante et positive, et honnêtement, l’application Fabulous est vraiment magnifique, ce qui en fait une source d’inspiration sans limite ! Si vous vous intéressez au design de manière générale, regardez la vidéo !

Quentin

Android Things for IoT

Android Things (ou Android pour les objets connectés) est un composant peu connu de la plateforme, mais pas le moins intéressant ! Cette conférence, présentée par le Googler Wayne Piekarski, présentait toutes les bases nécessaires au développement d’un objet connecté sous Android, aussi bien au niveau du hardware que du software. On n’a qu’une seule envie en sortant de là : acheter un Raspberry Pi 3 et équiper son frigo avec un thermomètre connecté !

Quentin

How to reactively load and cache data without even trying

La conférence de Mike Nakhimovich, du New York Times avait pour sujet “How to reactively load and cache data without even trying”. Elle présentait la librairie open source “Store” (https://github.com/NYTimes/Store), développée en interne pour répondre aux problématiques de chargement et persistance des données dans leur application Android.

En plus d’être un orateur clair et sympathique, Mike offre à la communauté des développeurs Android un socle générique pour standardiser le workflow d’acquisition et persistance des données.

La librairie, développée sur une base de RxJava, est un framework visionnaire et très prometteur… Celui-ci offre de nombreuses possibilités de personnalisation (du requêtage, parsing et caching), et des middlewares sont déjà disponibles pour l’intégration avec des librairies tierces bien connues telles que Gson, Moshi, Guava Cache, ou encore Okio.

Aujourd’hui, on ne se passerait plus de Glide ou Picasso qui ont fait la même chose pour le chargement d’images. Il y a fort à parier que ce sera le cas demain pour la gestion de nos données avec Store.

Thank you, Mike!

Christophe

Toothpick: a fresh approach to Dependency Injection on Android

Il y a quelques années, j’ai eu l’occasion d’utiliser RoboGuice. Il était facile à utiliser mais, malheureusement, relativement peu performant. Et puis, dans le cadre d’un autre projet, j’ai voulu utiliser Dagger. Et là… La performance était au rendez-vous, à tout le moins du point de vue de l’exécution ! Côté développeur, la performance a été revue à la baisse 🙂

C’est donc en espérant retrouver cette simplicité dans la syntaxe tout en gardant des performances correctes que je suis allé voir la conférence sur Toothpick. Et j’ai été conquis : un framework d’injection de dépendances simple et performant ! Avec en prime de nouveaux scopes pour des cas particuliers pas si rares que ça dans nos développements (tunnels de paiement, rotation d’écran).

Il va maintenant falloir tester cela sur de nouveaux projets, et voir si les promesses de l'(excellent) orateur sont tenues avant d’inclure Toothpick dans notre trousse à outils.

Retrouvez tous les slides de la conférence ici :

David

L’évolution des notifications – Tips & tricks

Notification : artefact d’interface facilitant les interactions et les feedbacks d’une application avec son utilisateur via le système.

Dans cette présentation, Jeremie Martinez, Trainline (Captain Train), nous a présenté l’évolution des notifications depuis les origines d’Android jusqu’à Marshmallow avec une pointe de visibilité sur Nougat.

Celles-ci sont devenues au fur et à mesure du temps de plus en plus complètes tout en gardant leur simplicité graphique. Mais faut-il encore ne pas en abuser pour ne pas spammer les utilisateurs et les noyer d’informations inutiles !

“Même #Batman peut être spammé de notifications pour sauver #Gotham

Ce simple graphique permet de positionner votre application et de définir si celle-ci a réellement besoin de notifier l’utilisateur pour lui apporter des informations utiles.

Dans le cas présenté, Trainline, l’application informe l’utilisateur à tous les moments cruciaux de son voyage :

  • Quelques heures avant
  • Lorsque le train ne va pas tarder
  • A l’arrivée du train sur le quai
  • Au changement d’horaire possible (avec une mise en couleur du titre et des actions pour se différencier des autres informations moins sensibles)
  • A l’arrivée du train à sa destination finale
  • Et même quelques minutes après l’arrivée pour souhaiter une bonne journée au voyageur ! (notification qui s’auto efface au bout de 15 minutes d’affichage sans action de l’utilisateur)

Toutes ces notifications sont informatives mais permettent une certaine sérénité pour le voyageur. Pour ma part la dernière notification est à considérer comme du spam, pour Trainline c’était juste pour le fun.

Pour conclure il faut peu de notifications pour avoir un utilisateur heureux.

Vous pouvez retrouver tous les slides de la conférence ici :

Melaine

 

Ivre, il commercialisa des apps Android tout seul

Développer ou faire développer son application pour devenir riche voire très riche : utopie ou réalité ? Tel est le sujet abordé par Pierre Benayoun dans sa conférence.

Une présentation pleine de gifs !

A travers son expérience, Pierre Benayoun, nous a montré quels étaient les points clés pour la réalisation et la commercialisation d’une application :

  • Qu’est ce qu’une bonne appli ?
  • Comment l’application trouve-t-elle son public ?
  • Comment gagne t’on de l’argent ?

Plusieurs paramètres non négligeables entrent en ligne de compte pour répondre à ces 3 questions

mais surtout ne pas hésiter à faire, refaire et re-refaire tout en analysant et en apprenant de ses succès comme de ses erreurs.

Tout en gardant à l’esprit que …

L’instant hype de la présentation : la notation rôti avec les mains :

  • 5 doigts OK j’ai tout compris et la présentation était parfaite
  • 0 doigt, poing fermé (petit rôti) : présentation suicidaire, j’aurais mieux fait de rester au lit 😉

Vous pouvez retrouver tous les slides de la conférence ici :

https://docs.google.com/presentation/d/1afPtkSb_BUtD6t61wV2eaVLVzbnYQ9D6quaFCG9D4LI

Melaine

 

Le design mobile c’est pas facile

Nous étions présents dans l’espace sponsors, nous étions dans les rangées de spectateurs avides de connaissances, mais nous étions aussi là-bas, dans la lumière, sur l’estrade tant convoitée des speakers d’Android Makers.

Quentin, un de nos experts Android, passionné de design (et de séries), nous a présenté les difficultés que nous pouvons (et que vous pouvez) rencontrer face à un client ou quelqu’un qui n’est pas du métier.

A travers différentes saynètes, il nous a présenté les solutions qui peuvent être envisagées, afin que tout le monde y trouve son compte : le client, le développeur, le designer, mais surtout, l’utilisateur final.

Vous pouvez retrouver tous les slides de la conférence ici :

David

Show must go on

Pour terminer la conférence, nous avons assisté à un véritable spectacle de la part de Chet, nous laissant ravis de ces deux jours et le sourire aux lèvres, la tête remplie de nouvelles idées à essayer sur nos prochaines applications. Nous vous laissons avec la vidéo si vous souhaitez comprendre un peu mieux le titre de cet article, ou juste rire un moment.

 

Merci à iD.apps pour l’expérience, et à l’an prochain !

Introduction à Android TV

Les applications TV sont aujourd’hui présentes pour mettre en avant du contenu en accès rapide et avec très peu de contraintes. Afin de conserver la meilleure expérience possible il est nécessaire de respecter certains aspects.

Au début, le développement d’une application TV est assez proche du développement d’une application smartphone et tablette. Cependant la documentation pour ce type d’appareil est très pauvre.

Pour aider les développeurs, Google recommande de respecter une certaine ergonomie, expliquée dans une documentation de base (https://www.google.com/design/spec-tv/android-tv/introduction.html). Ce qui change globalement c’est la navigation. En effet, sur TV, la navigation dans l’application se fait par l’intermédiaire de la télécommande, sans contact tactile avec l’écran. C’est pourquoi l’ergonomie des applications TV ressemble finalement assez peu à ce dont on a l’habitude et possède ses propres codes, gestes.

La librairie Leanback, mise à disposition par Google, propose plusieurs composants et différents types de fragments. Certains de ces composants sont présentés dans la documentation précédemment évoquée. Malheureusement celle-ci ne propose pas d’exemple de code. Pour vraiment pouvoir vous lancer dans la création de votre première application TV, il faut se référer au tutoriel officiel suivant : https://codelabs.developers.google.com/codelabs/androidtv-adding-leanback/index.html?index=..%2F..%2Findex#0

Ce tutoriel présente les composants et fragments de base via des exemples de code bien expliqués, bien utile pour se familiariser rapidement avec les applications TV.

Pour aller plus loin, le DIY est de mise. En effet, le développement d’applications TV n’étant pas encore très répandu il faut chercher ce que l’on souhaite faire dans des exemples d’applications proposés par Google. Les deux meilleurs samples de code disponibles et mis à jour régulièrement sur GitHub sont :

atv-leanback-all

Fragments et vues abordés dans l’exemple Github androidtv-Leanback

Figure 2 : Fragments et vues abordés dans l'exemple Github leanback-showcase

Fragments et vues abordés dans l’exemple Github leanback-showcase

Ces deux projets se complètent bien même si le deuxième présente plus de diversité.

 

Ça donne quoi en vrai ?

Dans notre cas, nous avons développé une application présentant différents quiz regroupés par thèmes.

Cette application nous a servi d’expérience pour tester certaines fonctionnalités d’Android TV.

Nous avons commencé par implémenter un BrowseFragment (https://developer.android.com/reference/android/support/v17/leanback/app/BrowseFragment.html) pour l’affichage des quiz de chaque thème. L’ajout de listes de quiz se fait via un ArrayObjectAdapter utilisant un ListRowPresenter (adapter permettant d’ajouter plusieurs élements de type ListRow contenant un header et une liste de card).

Ensuite pour chaque élément de la liste il est possible d’utiliser des CardViews prédéfinis ou des CardViews custom selon le besoin. Le BrowseFragment est au début aisé à prendre en main de part les exemples cités précédemment. En effet, l’adapter permettant d’ajouter des lignes de Cards dans le fragment est plutôt intuitif. En revanche lorsque l’on essaie de customiser les vues la complexité s’accroit car il faut se débrouiller par soi-même pour arriver au but que l’on s’est donné. Il y a en effet très peu d’informations sur les vues personnalisées dans les tutoriels.

Figure 3 : BrowseFragment présentant la liste des thèmes et les quiz correspondant

Le BrowseFragment présente la liste des thèmes et les quiz correspondants

Nous avons également utilisé le DetailFragment afin d’afficher le détail d’un quiz. Par défaut la description et l’image adoptent des layouts prédéfinis, mais il est bien entendu possible d’utiliser les nôtres. Dans ce fragment il est possible d’ajouter des listes de suggestions d’éléments. Dans notre cas, nous avons suggéré les quiz du même thème. Le DetailFragment est le plus difficile à mettre en place car aucun exemple n’explique concrètement comment mettre en place l’adapter afin de réaliser une apparence personnalisée. Notre conseil pour réussir une page sympa est d’utiliser un ArrayObjectAdapter avec en paramètre un ClassPresenterSelector (cela permet d’ajouter et d’ordonner plusieurs adapter différents afin, par exemple, de pouvoir proposer des suggestions sous la description de l’élément courant).

Figure 4 : En tête du DetailFragment d’un quiz

Entête du DetailFragment d’un quiz

Figure 5 : Bas de page du DetailFragment d’un quiz, liste de suggestion

Bas de page du DetailFragment d’un quiz avec une liste de suggestions

Pour la recherche d’un quiz nous avons exploité le SearchFragment qui lui est facile à prendre en main. Le fragment de base suffit, il faut simplement spécifier les différents adapter à utiliser pour l’affichage des résultats.

Figure 6 : SearchFragment après la recherche “sport”

SearchFragment après la recherche “sport”

Le GuidedStepFragment est quant à lui très pratique et facile d’utilisation pour de la configuration. En revanche, dans notre cas, nous l’avons utilisé pour la connexion via email et mot de passe, et cela a posé quelques complications lors de l’ajout des champs de saisie de texte. En effet, ce fragment est principalement élaboré pour contenir des boutons classiques et/ou radios.

Figure 7 : GuidedStepFragment proposant le choix du type de connexion

GuidedStepFragment qui propose le choix du type de connexion

Pour notre application nous avons également implémenté une page de paramètres via le SettingsFragment. Cette page se présente comme un Drawer sur la partie droite de l’écran. Le fichier XML de settings est identique à celui que l’on peut trouver sur les smartphones/tablettes.

Figure 8 : SettingsFragment donnant le choix d’activation de certaines fonctionnalités

SettingsFragment qui donne le choix d’activation de certaines fonctionnalités

 

Le mot de la fin

Comme vous avez pu le constater, la réalisation de cette application nous a permis de passer en revue de nombreux composants Android TV fournis par Google.

La programmation d’applications pour Android TV est très intéressante car elle permet une approche différente des applications utilisées sur nos smartphones/tablettes même si une bonne dose de DIY est nécessaire !

Crosswalk : la WebView du futur !

Comme tous les ans avant la Google I/O, il y a la soirée Day 0 Intel Party. Le nombre de participants à l’I/O ayant augmenté cette année, ce fut encore plus difficile d’y entrer. Mais armés de notre patience, nous avons tout de même réussi ce challenge.

Nous sommes donc entrés dans un lieu insolite, à mi-chemin entre le bar et la place à Food Trucks, le tout accompagné de stands sur divers projets Intel liés au mobile. Le sujet de cet article est l’un de ces projets qui pourra répondre à un besoin que nous avons fréquemment : la WebView.

Aujourd’hui, pour intégrer une WebView dans notre application, nous avons, au choix, les Chrome Custom Tabs, ou une WebView classique.

Intégrer une WebView directement dans l’application n’est pas forcément compliqué, mais amène deux soucis majeurs : les performances et les comportements anormaux qui diffèrent par rapport au browser natif (ou pas à jour).

Intel a pensé à nous et a sorti une librairie qui répond à ces problèmes : Crosswalk (https://crosswalk-project.org/). Celle-ci est disponible sur Android, iOS, WP et Cordova.

Elle intègre une WebView performante qui a toujours le même comportement suivant les versions d’Android. Il s’agit ni plus ni moins que d’une réimplementation de Chromium et son moteur Blink, sous forme de librairie.

Elle a aussi l’avantage d’intégrer des APIs non disponibles dans la WebView standard, comme :

  • WebRTC
  • WebGL
  • Vibration API
  • Presentation API
  • Predictable layout
  • CSS feature queries

Sur le papier, le projet vend du rêve mais il faut tout de même noter un point négatif : le poids de la librairie (19 Mo).

Si cet inconvénient n’est pas un problème pour votre projet, je vous invite fortement à tester cette librairie qui pourra vous éviter pas mal de galères. La migration est très simple car la WebView de Crosswalk a la même interface que la Webview standard, il faudra juste modifier les imports et le nom de la classe.

Pour en savoir plus, voici une vidéo de présentation faite par Intel sur le sujet.

Google I/O : nous y étions !

Mis en avant

Cette année, iD.apps était présent à la Google I/O, avec pas moins de trois participants à la conférence annuelle de Google pour les développeurs. C’est généralement durant cet événement que la firme de Mountain View annonce à la fois ses nouveaux produits pour le grand public, mais aussi les nouveautés à venir sur Android, ou encore les nouveaux outils qu’elle met à disposition des développeurs.

Bien entendu, nous avons envie de vous parler de tout un tas de nouveautés que nous avons adoré ! Mais avant, nous voulions vous faire un petit tour d’horizon de ces trois jours de conférence dans la Silicon Valley !

IMG_20160519_201327

 

Google I/O day 0 et keynote

Cette année, la Google I/O se déroulait pour la première fois au Shoreline Amphitheatre, à Mountain View, juste à côté des locaux de chez Google. Il s’agit d’un amphithéâtre, généralement utilisé pour des concerts, et pouvant accueillir plus de 20000 personnes !

Grande nouveauté donc, la conférence s’est déroulée en plein air, le parking ayant été aménagé d’espaces pour les conférences et autres démos technologiques.

Afin d’obtenir de bonnes places pour la keynote, il était impératif d’arriver le plus tôt possible pour le retrait des billets, le jour précédant celle-ci. En effet, les meilleures places étaient attribuées aux premiers arrivés. Forts de notre envie d’être au premier rang, nous sommes donc partis attendre l’ouverture des retraits de badges, dès 5h du matin ! 2h plus tard, nous avions nos badges, et une place dans la section 101, la mieux placée.

C’est donc au premier rang de la section 101, juste derrière les Googlers, que les experts iD.apps étaient prêts à découvrir les nouveautés que Google allait annoncer. Et nous n’avons pas été déçus !
IMG_20160518_090459

Tout d’abord, Google Home, un boîtier équipé du Google Assistant (évolution de Google Now), qui vous permettra, par la voix, de poser une question, écouter une chanson sur Google Music, ou lancer un appel Hangouts. Si vous connaissez Echo d’Amazon, vous voyez probablement de quoi il s’agit. Si vous voulez en savoir plus, vous pouvez aller visiter la page officielle : https://home.google.com . Sortie cet automne pour en savoir plus !

Google a également présenté deux nouvelles applications : Allo et Duo. Le premier se présente comme un remplaçant de Hangouts, tandis que le second est une sorte de Facetime à la sauce Google. L’intégration de l’assistant Google les rend néanmoins particulièrement puissantes. Les deux applications devraient être disponibles durant l’été !

La VR était également de la partie, avec l’annonce de standards de construction de smartphones VR ready pour Android, sous la marque Daydream. Le tout s’accompagnera d’une nouvelle interface entièrement dédiée à la VR pour ces téléphones. Plus d’informations seront disponibles cet automne.

Google nous a également présenté (ou plutôt re-présenté) les nouveautés à venir sur Android N (notamment le multi-window). Petite surprise néanmoins : les instant apps. D’ici la fin de l’année, il sera possible aux utilisateurs d’Android d’utiliser certaines parties d’une application, sans avoir à l’installer ! Vous pourrez par exemple consulter le détail d’une réservation d’hôtel, sans avoir à installer l’application de la chaîne d’hôtel en question. Le tout disponible à partir de KitKat. Plutôt pas mal non ?

IMG_20160517_073652

Côté développeurs,  Android Studio a désormais une version 2.2 (disponible en version Canary), qui intègre de très nombreuses nouveautés, dont le constraint layout (qui devrait simplifier la vie des développeurs pour construire les interfaces), ou encore un enregistreur de tests fonctionnels pour Espresso. Nous écrirons un article bientôt pour vous donner notre ressenti sur toutes ces nouveautés vraiment intéressantes. En attendant, vous pouvez aller voir la conférence What’s new in Android Studio sur Youtube !

 

Enfin, le meilleur pour la fin : Firebase ! Vous connaissez cette entreprise, récemment acquise par Google, pour sa base de données temps réel très populaire. Désormais, Firebase inclut également un nombre très important d’outils formidables pour les développeurs Android. On y trouvera entre autres :

  • des statistiques d’application poussées (à la Google Analytics) avec de la gestion d’audience
  • du crash reporting (à la Fabric)
  • du paramétrage d’applications (comme Parse le permettait par exemple)
  • de la gestion de liens dynamiques
  • de l’hébergement de ressources web statiques
  • DU PUSH

Oui, vous avez bien lu, du push ! GCM est désormais FCM (Firebase Cloud Messaging), et permet l’envoi de pushs depuis la console Firebase, avec une gestion très poussée des audiences, liée aux statistiques de la partie analytics.

Le plus important : l’ensemble est GRATUIT. Plus besoin donc de passer par des solutions tierces (très) coûteuses pour de l’envoi de pushs ciblés. Le tout fonctionnant sous Android comme iOS. Nous reparlerons bien entendu plus en détails de tous ces changements qui vont avoir un impact important sur notre travail chez iD.apps.

IMG_20160519_142226

 

Les conférences, et autour

En trois jours, nous avons eu l’occasion d’assister à de très nombreuses conférences, sur de nombreux sujets. Bien entendu, Android, mais aussi Firebase, le Material Design, Play Games, ou encore les applications pour les pays émergents. Il fallait s’armer de patience pour assister aux conférences les plus courues, les gens faisant parfois la queue près de 2h en avance !

Heureusement, l’attente se faisant en extérieur, le cadre très agréable et le soleil de Californie adoucissaient un peu ces “pauses”. C’était aussi l’occasion de discuter avec d’autres développeurs venant du monde entier, et d’échanger sur les problèmes que nous rencontrons avec nos clients au quotidien. Et il n’y a pas tant de différence que ça entre la France et la Silicon Valley à ce niveau-là ! Et pour contrer la chaleur, Google n’avait pas lésiné sur les boissons et autres serviettes glacées. Les conférences, ce sont les rencontres avant tout, non ?

Baby foot

Les experts iD.apps prennent une pause entre deux conférences

Malgré ces longues files d’attente, nous avons pu assister à des conférences avec certaines célébrités de Google, comme Chet Hasse, Romain Guy, Nick Butcher ou encore Chris Banes ! Nous avons également vu sur scène le CTO d’Epic games (Unreal Engine), le CEO d’Unity Technologies, et même le très connu Tim O’Reilly. On croise de vrais légendes à la Google I/O !
IMG_20160519_130000

Nous avons également eu l’occasion d’aller tester quelques produits Google (pas Google Home malheureusement), et discuter avec les équipes produits. Comme vous pouvez vous en douter, nous avons longuement dialogué avec les équipes de Firebase, ou encore d’Android Studio. Nous avons aussi testé la réalité virtuelle avec une animation autour de Bohemian Rhapsody de Queen, ou encore la communication entre Android et un robot, avec un bras mécanique non dépourvu de talent artistique ! Sans oublier le projet Tango (https://www.google.com/atap/project-tango/), avec des tablettes montées sur des fusils Nerf pour faire la chasse aux monstres sous un chapiteau. Oui, on a l’air ridicule à courir après des créatures qui n’existent pas.

 

Le mot de la fin, avant la suite

Conclusion : la Google I/O, c’était génial ! Nous avons beaucoup de nouveautés à tester maintenant que nous sommes revenus en France, et il est probable que certaines annonces changent notre travail de tous les jours (avec un gain de productivité peut-être :)). Et nous sommes impatients de tester les nouveaux produits qui sortiront dans les mois à venir. Seule déception (en plus de l’absence de cadeau) : pas de nouveaux téléphones ou tablettes annoncés, mais l’on pouvait s’y attendre.

Suivez de près notre blog dans les semaines à venir pour en savoir plus sur ce que nous avons vu, et nos retours sur les nouveautés Android !

IMG_20160518_100448

Electric Dreams

Mais enfin c’est quoi un Daydream ?

Tout le monde connaît les fameux économiseurs d’écran. Qu’il s’agisse d’un simple logo qui bouge, ou d’un véritable aquarium virtuel, ils existent depuis bien longtemps. Néanmoins, dans le monde du mobile, c’est une notion qui n’existe pas vraiment.

Pourtant, il existe une fonctionnalité qui s’en rapproche sur Android : le daydream (API 17). Celui-ci peut en effet satisfaire les amateurs de poissons rouges en 3D, mais aussi et surtout réaliser tout un tas de traitements utiles : appeler un web service, afficher un flux RSS, et même offrir de l’interaction ! Cela permet d’afficher quelque chose de sympathique lorsque son appareil est en charge ou sur un dock.

Et pour les développeurs Android, il est vraiment très simple de faire vos propres daydreams. Alors, vous êtes convaincu de vous embarquer dans l’aventure ?

 

En route !

Créer un daydream est enfantin ! La première étape consiste à simplement créer une classe héritant de DreamService.

Vous aurez ensuite 4 méthodes à surcharger :

  • onDreamingStarted() : c’est là que les affaires commencent ! Vous pouvez lancer par exemple des animations. Après tout, s’il s’agit d’un économiseur d’écran, il faut que ça bouge un peu !
  • onDreamingStopped() : on se réveille ! C’est ici que le rêve s’arrête, ainsi que les traitements et animations commencés dans la méthode onDreamingStarted
  • onDetachedFromWindow() : à ce moment-là, vous pouvez libérer d’éventuelles ressources comme les listeners.

Vous devez également ajouter votre service à votre manifest. Et voilà, vous êtes prêt !

Nous vous conseillons d’aller voir la doc pour en savoir un peu plus :http://developer.android.com/reference/android/service/dreams/DreamService.html

Quelques méthodes bien utiles…

… A appeler dans la méthode onAttachedToWindow

  • setContentView : pour ajouter une vue à votre daydream
  • setFullscreen : si vous souhaitez conserver ou non l’interface du système
  • setInteractive : indique si l’utilisateur peut interagir avec le daydream ou non. A noter qu’il sera dans ce cas à vous de gérer le réveil (entendez par-là la sortie du daydream).

 

Jusqu’au bout du rêve

Vous vous en serez rendu compte, on peut tout faire, ou presque, sur un daydream ! Chez iD.apps, nous avons décidé de nous amuser à créer un diaporama de photos issues de l’API picture of the day de la NASA (https://api.nasa.gov/api.html). Cela permet d’égayer nos journées avec un joli défilé de photos spatiales.

Space

Et pour vous prouver que vraiment, ce n’est pas compliqué, nous avons publié sur Github le code de notre daydream. N’hésitez pas à aller y jeter un coup d’oeil, et éventuellement le forker pour modifier la source des images. N’hésitez pas non plus à nous soumettre une pull request si vous voulez nous aider à l’améliorer.

https://github.com/idapps/Interstellar-Daydream

Actuellement, le daydream affiche les photos de l’API, ainsi que leur nom et leur description. Ceux-ci changent toutes les minutes, afin de vous laisser le temps de lire le texte.

 

Vers l’infini et au-delà !

Notre daydream de l’espace n’est bien entendu qu’une première version, et pourrait facilement être amélioré. Il est par exemple possible d’ajouter une base de données embarquée pour pouvoir faire défiler des photos venant d’une période de temps plus longue, ou le rendre compatible smartphone et tablette. On pourrait même imaginer un écran de paramètres pour configurer diverses choses comme les temps de transition !

La conclusion est simple : les possibilités sont infinies. Il ne reste plus qu’à trouver l’API de vos rêves !

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

 

Ok Glass, Treat an incident (2/2)

Following our previous article, we are still working on MBAAS and GPS guiding. In this article, we focus on retrieving the information saved in Parse and then talk about the geo-point search.

This time, we will talk about treating an incident already registered. First, we need to choose among the declared incidents, and then go to its location. To do that, we retrieve from Parse the ten closest incidents still in progress. When they are retrieved, the user can choose among them the one he wants to treat. He is then directed to a map displaying his current location and the incident location. On this view he can also access the incident description and a related picture. Then he can go through to a simple guiding screen. At this point, the user can only see the distance as the crow flies and the incident general direction. He can also access a map that shows his current location and the incident location. However, the map won’t actualize as the user moves.

This time the speech recognition understands what I said on the first trial. Oh, again don’t try to search for any car there is none.

Retrieve closest incident with Parse

Incident_retrieved

We begin our flow by searching for the ten closest incidents that are still in progress. Each of them is displayed in its own card as follow: in first its id, then its type and finally its creation date. The cards are bundled in a ScrollView as for the type choosing part in the report application. We also retrieve the first report and the incident picture. Since we cannot display them right away, we pass those to the next screen.

public void onLocationChanged(Location location) {
	// Called when a new location is found by the network location provider.
	mUserLatitude = location.getLatitude();
	mUserLongitude = location.getLongitude();

	mLocation = new ParseGeoPoint(mUserLatitude, mUserLongitude);

	ParseQuery<ParseObject> query = ParseQuery
			.getQuery(Poc_TreatAnIncident_Constants.INCIDENT_LOCATION);

	query.whereNear("location", mLocation);
	query.whereEqualTo(Poc_TreatAnIncident_Constants.INCIDENT_TREATED,
					false);
	query.setLimit(10);

	query.findInBackground(new FindCallback<ParseObject>() {

		@Override
		public void done(List<ParseObject> objects, ParseException e) {
			if (e == null) {
				Card card;
				mCards = new ArrayList<Card>();
				String _footer = "/" + objects.size();
				ParseObject po;

				for (int i = 0; i < objects.size(); i++) {
					card = new Card(IncidentSearchActivity.this);
					po = objects.get(i);
					mClosestIncidents.add(po);

					card.setText(dispalyIncidentInfo(po));
					card.setFootnote((i + 1) + _footer);
					mCards.add(card);
				}

				mCardScrollView = new CardScrollView(
						IncidentSearchActivity.this);
				IncidentTypeCardScrollAdapter adapter = new IncidentTypeCardScrollAdapter();
				mCardScrollView.setAdapter(adapter);
				mCardScrollView.setOnItemClickListener(mClickAdapter);
				mCardScrollView.activate();
				setContentView(mCardScrollView);
				mLocationManager.removeUpdates(mLocationListener);
			} else {
				Toast.makeText(IncidentSearchActivity.this,
						"Failed to retrieve incidents", Toast.LENGTH_SHORT)
						.show();
			}
		}
	});
}

Here, we retrieve the ten nearest incidents with findInBackground() with the query whereNear(). We specify that we only want the ten closest with setLimit().

Additional information: location, picture and description

incident_map

On this activity the user can see where the incident is located and he can consult its description by swiping backward. The picture of the incident is also available by swiping forward when the map is displayed. As in our previous application, the map comes from Google static maps. Here, we didn’t use a card because it doesn’t seem to be in any way able to display only an image, apart in background. On cards you can only have text, a background image or a mosaic of pictures on the left side of the card.

Direction with Glass

To guide the user to the incident scene, we chose to give only a general direction and the distance as the crow flies. To provide this guiding we have a mark that moves depending on the Glass camera orientation regarding the incident.

direction front When the user is heading in the rigth direction the mark moves from one side of the screen to the other in accordance to the incident direction. direction left When the direction to the incident isn’t in front of the user but on his left. direction right When the direction to the incident isn’t in front of the user but on his right.

Caution: the camera is located on the movable arm used to tune the angle of the prism. This might introduce a small difference regarding the real angle.

Provided with only this indicator, it would be pretty hard for the user to direct himself solely with this information. Thus, we provide him with the possibility to check his position. By swiping backward, the user can access a map where his current location and the incident location are displayed. As for all of our maps, this one is also a static one and will not be refreshed as the user is moving. It will only refresh when the user will check again his position.

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:id="@+id/orient"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context="com.example.orientingtest.DirectionActivity$PlaceholderFragment" >    
    <ImageView
        android:id="@+id/incident_on_left"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_alignParentLeft="true"
        android:layout_centerVertical="true"
        android:src="@drawable/mleft"
        android:visibility="gone" />

    <ImageView
        android:id="@+id/incident_on_right"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_alignParentRight="true"
        android:layout_centerVertical="true"
        android:src="@drawable/mright"
        android:visibility="gone" />

    <ImageView
        android:id="@+id/incident_in_front"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_alignParentLeft="true"
        android:layout_centerHorizontal="false"
        android:layout_centerVertical="true"
        android:src="@drawable/mfront" />
    
    <ImageView android:id="@+id/map_current_position"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:visibility="gone" />

    <TextView
        android:id="@+id/information"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_alignParentTop="true"
        android:layout_centerHorizontal="true"
        android:layout_marginTop="@dimen/card_margin"
        android:ellipsize="end"
        android:singleLine="true"
        android:text="@string/swipe_left_for_info"
        android:textAppearance="?android:attr/textAppearanceSmall" />
    
    <TextView
        android:id="@+id/distance"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_alignParentBottom="true"
        android:layout_centerHorizontal="true"
        android:layout_marginBottom="@dimen/card_margin"
        android:ellipsize="end"
        android:singleLine="true"
        android:text="@string/wait_result"
        android:textAppearance="?android:attr/textAppearanceSmall" />
</RelativeLayout>

At initialization, the default orientation is north. You need to move to refresh your real orientation. There can be some time before it properly refresh.

public void directionTo(double heading) {
	float bearing = MathUtils.getBearing(mUserLatitude, mUserLongitude,
			mIncidentLatitude, mIncidentLongitude);
	float differentialAngle = (float) (bearing - heading);

	if (differentialAngle < 0)
		differentialAngle += 360;

	// The view displays 90 degrees across its width so that one 90 degree head rotation is
	// equal to one full view cycle.
	float pixelsPerDegree = (mTipsContainer.getWidth() - 68) / 90.0f;

	double distancem = 1000 * MathUtils.getDistance(mUserLatitude,
			mUserLongitude, mIncidentLatitude, mIncidentLongitude);

	mTipsView.setText(mDistanceFormat.format(distancem) + " m");

	if ((differentialAngle >= 45 && differentialAngle <= 180)) {
		mLeftMark.setVisibility(View.GONE);
		mRightMark.setVisibility(View.VISIBLE);
		mMarkFront.setVisibility(View.GONE);
	} else if ((differentialAngle > 180 && differentialAngle <= 315)) {
		mLeftMark.setVisibility(View.VISIBLE);
		mRightMark.setVisibility(View.GONE);
		mMarkFront.setVisibility(View.GONE);
	} else if ((differentialAngle >= 0 && differentialAngle < 45)
			|| differentialAngle == 360) {
		mLeftMark.setVisibility(View.GONE);
		mRightMark.setVisibility(View.GONE);
		mMarkFront.setVisibility(View.VISIBLE);

		mMarkFront.setLayoutParams(positionL);
		RelativeLayout.LayoutParams pos = positionL;
		int margin = (int) (((mTipsContainer.getWidth() - 68) / 2) + (pixelsPerDegree * differentialAngle));

		pos.setMargins(margin, 0, 0, 0);
		mMarkFront.setLayoutParams(pos);
	} else if (differentialAngle > 315 && differentialAngle < 360) {
		mLeftMark.setVisibility(View.GONE);
		mRightMark.setVisibility(View.GONE);
		mMarkFront.setVisibility(View.VISIBLE);

		mMarkFront.setLayoutParams(positionL);
		RelativeLayout.LayoutParams pos = positionL;
		int margin = (int) ((pixelsPerDegree * (differentialAngle - 315)));

		pos.setMargins(margin, 0, 0, 0);
		mMarkFront.setLayoutParams(pos);
	}
}

If differentialAngle is between 0 and 180 degrees, the incident is on the left of the user. It is only true once we have normalize differentialAngle between 0 and 360 degrees.

Intent intent = new Intent(Intent.ACTION_VIEW);
intent.setData(Uri.parse("google.navigation:q=48.649469,-2.02579"));
startActivity(intent);

Instead of our rough guiding, it also would have been possible to give a turn by turn guiding but we wanted to test how the Glass handles direction and orientation by ourselves. This intent came from people analyzing the log of the Glass embedded command “Get direction”, so it might change in future updates, making this possibly not reliable (see How can I launch Directions from GDK).

Once the user is within ten meters from the incident, he can use a tap interaction to continue with the flow.

Picture and report after the incident is treated

After the incident is treated, the user must take a picture of the solved incident and issue a final report.  The user takes the picture as in the previous applications. He can preview it and retry until he is satisfied. In the same way, we use the speech recognition to record the user final report after the picture has been taken. We use the same implementation as for our previous application. The report and the picture are then saved in Parse with the saveInBackground() function.

Conclusion

With this application we have been able to test out the orientation sensor, alongside with the location providing features of Glass. We have also seen that it is really simple to retrieve data from Parse even with just a location constraint. The complexity is nicely hidden behind a nice and friendly function.

This article concludes our work on location and MBAAS. We will continue to work on Glass and we will come back to you when we have more to share.

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.

Retour de WWDC (1/2) : Ambiance

2 de nos Experts iOS, David et FX sont rentrés de San Francisco avec des souvenirs plein la tête et bien évidemment une expertise renforcée. Pour cela, nous vous proposons un retour sur l’expérience WWDC de nos Experts en 2 articles.

1. L’ambiance de l’événement et des lieux

2. Un retour à froid sur les annonces techniques de la WWDC                            Quelles sont les avancées vraiment importantes pour les utilisateurs, pour les développeurs ? Y-a-t-il eu des annonces un peu “surfaites” ?

–  L’ambiance de l’événement et des lieux –

Vous retrouverez dans ce premier article une interview de David sur l’ambiance de la WWDC et de San Francisco.

Salut David, alors comment s’est passé ce voyage à San Francisco ?

C’était top, 10 jours de bonheur.

Concernant l’organisation, l’hôtel était très bien placé, à 5 minutes du Moscone Center. Il est très facile de se déplacer : entre le métro, le tram, le bus et le train, les moyens de transport sont nombreux. Un bémol tout de même, il n’y a pas une, mais au moins trois sociétés de gestion des transports, il faut donc autant de tickets et/ou de pass hebdomadaires.

Ensuite, au sujet de la WWDC en elle-même, après une Keynote bien plus chargée que ce à quoi nous nous attendions, nous avons assisté à 4 jours de conférences claires et rondement menées. Bref des journées studieuses pour assimiler toutes les nouveautés.

Peux-tu nous raconter en quelques mots votre découverte de la ville et son ambiance ? Est-ce réellement le paradis des geeks ?

“Paradis des Geeks” : je ne sais pas. Honnêtement d’après nos impressions, je dirais que non . 😉 Ce qui est certain, c’est que la WWDC ne pouvait pas passer inaperçue. En effet, plus de 6000 ingénieurs fans de la marque à la pomme se sont promenés dans les rues de San Francisco pendant une semaine. Et nous étions reconnaissables grâce à une “jolie” veste estampillée WWDC 14, offerte à l’inscription. Difficile de nous rater !

IMG_2865

Tiens! Des gens avec la veste WWDC 14 !

Hormis les participants à la WWDC, San Francisco ne nous a pas laissé une impression de ville de geeks. Nous étions en plein centre-ville alors que l’activité informatique se trouve plus au sud de la baie : du côté de Palo Alto et Sunnyvale.

IMG_2759

Ballade en vélo

Selon vous, comment s’est déroulée la WWDC ? Comment se passe une conférence avec 2000 personnes ?

Il a fallu, tout d’abord récupérer notre pass le dimanche, puis direction le Moscone où iOS 8 et Mac OS Yosemite étaient déjà à l’affiche.

IMG_2864

A conserver précieusement !

Le lendemain : levé à 4h30 du matin pour la Keynote! FX n’avait pas sommeil 😉 et a patienté jusqu’à 10h00 que la Keynote commence. De mon côté, je suis arrivé à 7h00 avec les cafés à la main et j’ai pu rejoindre FX à quelques mètres de l’entrée. Il n’y avait pas de places pour tout le monde dans la plus grande salle de conférence. Si nous étions arrivés trop tard nous aurions assisté à la Keynote dans une 2ème salle en vision conférence 🙁 Tant qu’à être à San Francisco, autant voir Tim Cook en chair et en os !

IMG_2871

La longue file d’attente à 7h00 qui fait le tour complet du bloc…

Avec 2000 personnes, les conférences se sont étonnamment bien passées! Il faut dire que les moyens étaient là : une sonorisation de qualité avec deux ingénieurs son dans chaque salle, des écrans de grandes tailles et une gestion de la foule au cordeau. Les ingénieurs Apple étaient parfaitement rodés et leurs présentations claires avec quelques touches d’humour. Les Macs étaient toujours en double voire en triple pour assurer les démos. Néanmoins, nous avons eu droit à quelques crashs sur les Macs tournant avec la bêta de Mac OS Yosemite et celle de Xcode 6. Cela n’a pas manqué de faire réagir l’assemblée.

Et concernant la Keynote : quelle ambiance, quelle population ?

Lors des conférences, l’ambiance était très studieuse : chacun sur son Mac à prendre des notes. Il faut dire que plus de 30% de la population n’est pas anglophone. Il faut être concentré pour ne rien manquer. Les intervenants étaient vraiment bons. J’ai déjà vu des conférences en français moins compréhensibles. Chacune impose une heure de concentration à essayer d’assimiler le plus possible les nouveautés sur lesquelles nous devrons travailler dès notre retour en France. Septembre va arriver vite !

Le premier soir, une rencontre francophone fut organisée à proximité du Moscone. Ce fut un bon moment pour rencontrer des compatriotes et échanger nos impressions sur cette Keynote. Tout le monde était très emballé par les nouveautés annoncées !

Et le retour, alors pas trop dur… ?

Non, cela a été. Le décalage horaire a été moins difficile que prévu. Dès le mardi, nous avons fait le bilan avec FX et préparé des retours pour nos collègues développeurs. Nous partagerons ainsi bientôt avec vous certains de ces éléments.

Ton top TOP 3 des souvenirs Whaouu!! ?

  • La Keynote en Live et Tim Cook en vrai 😉
  • Tous les monuments de SF en vrai
  • 6000 fans de la marque à la Pomme dans un seul et même bâtiment !

 Ton TOP 3 des “si je devais y retourner, je …” ?

  • Je retournerais avec FX pour qu’il fasse la queue à 4h30 pour la Keynote 2015.
  • Je ferais un tour sur les campus Apple, Google plus au sud de la baie de SF.
  • Je passerais plus de temps dans le Parc National de Yosemite 🙂

Le mot de la fin ?

Vraiment une superbe expérience, autant sur le plan professionnel que personnel. Nous espérons pouvoir y retourner tous les ans mais il va falloir laisser la place à ceux restés au bureau cette année.

A bientôt pour le retour technique sur la WWDC !