Longue vie à Cordova

La semaine dernière, un sondage express est passé sur twitter pour les développeurs Cordova, pour apprécier leur ressenti sur la techno.

Les questions portent sur la documentation essentiellement, et bien sûr sur le niveau de satisfaction à l’utilisation de Cordova.

Comme à la fin il y avait un champ pour indiquer son email, pour poursuivre la conversation avec l’équipe de dév, j’ai laissé mon adresse.

J’ai reçu dès le lendemain un mail me proposant un RV téléphonique. J’ai apprécié la réactivité de l’équipe, et j’ai encore plus apprécié l’échange.

Le RV s’est passé vendredi à 17h30, avec deux développeurs américains, dont l’un de chez Microsoft. Je suis toujours surprise par l’implication réelle des développeurs de chez MS sur les projets libres. Après tout, cela fait des années que MS parle du logiciel libre comme du grand Satan, et leur récent free/libre-washing ne m’a pas vraiment convaincue. Mais force est de constater que si je continue de me méfier de l’entreprise, j’ai pleinement confiance dans les hommes et les femmes qui la composent (enfin, par au sommet, à la base, bref, les développeurs, quoi 😉 ).

L’échange a duré 45 minutes, en français et en anglais (je pense qu’on est tous sortis épuisés de cette conversation). On est revenu sur les questions sur sondage, notamment la documentation, mais les deux intervenants ont beaucoup insisté pour que j’exprime mes « frustrations » (pour reprendre leur terme) à l’utilisation de Cordova.

Celles-ci ne sont pas nombreuses mais quand j’y repense, ce sont finalement les freins à une adoption plus massive.

L’émulateur

L’émulateur met une plombe à se lancer, et il met 3/4h de plombe à émuler l’appli quand je la relance avec la commande build.

Quand je suis en plein debuggage javascript, à mettre des alert partout, je vois bien que je manque d’outils pour développer, mais en plein dév, on est dans une espèce d’urgence, et on ne prend pas le temps de chercher autre chose, mieux. Donc on soupire, on serre les dents et on patiente.

L’installation

Un point auquel je pense en écrivant cet article, mais que je n’ai pas pensé à mentionné aux développeurs, c’est la difficulté à installer l’environnement de dév. La première fois, cela a pris une journée entière, la 2e fois, une demi-journée (sur un poste différent). J’espère encore gagner un peu de temps la prochaine fois, mais je ne pense pas descendre un jour en-dessous de 3 heures. Il manque toujours un truc : un jdk, un nodejs, un PATH mal configuré… c’est un peu la plaie.

La performance

Même avec une appli très simple, Cordova est *légèrement »* plus lente. Oh, parfois c’est vraiment rien. Mais on *sent* cette différence, et tant qu’on la sentira, les applis natives seront préférées à Cordova.

Somme toute Cordova a encore un peu de boulot, mais manifestement les core-developpers y travaillent. Je ne voudrais pas faire un article qui mentionne uniquement les points négatifs, alors allons-y pour le positif.

La documentation

La doc est bien faite. Vraiment. Complète, avec des exemples. Je lui donne une note de 9/10, pas parce que la perfection n’existe pas mais parce qu’il manque parfois des exemples d’utilisations un peu bâtardes. Ou du moins, des utilisations moins standard. Mais une techno aussi bien documentée, moi je dis que ça vaut le coup de le mentionner.

Les core-plugins

Les core-plugins sont réduits à l’essentiel mais ils suffisent pour développer un projet normalement complexe : manipulation de l’appareil-photo, de la capture de sons et des medias, géolocalisation, file system, accès aux infos du téléphone (du device), gestion de la connectivité, manipulation des contacts, pour ne citer qu’une partie, tout est là.

Bon, sauf les push notifications, qui sont désormais en standard dans à peu près toutes les applis, et qui deviennent donc indispensables.

L’éco-système de plugins

Et justement, des plugins de push notifications, il en existe plein ! ainsi que d’autres, beaucoup beaucoup d’autres, pour faire à peu près tout ce que vous voulez : manipulation du calendrier natif, scan de code-barres, NFC, Bluetooth, … plus de 600 plugins existent à ce jour.

En conclusion

Cordova est un bon environnement pour développer une appli. Facile à prendre en main, multi-plateforme, maintenu à un ryhme appréciable, avec un éco-système encore un peu light mais qui progresse, et bien sûr, libre (licence Apache 2.0). Le fait qu’il soit porté par la fondation Apache et non par un éditeur lui assure un futur chargé de promesses.

Renommer une appli ou comment transformer une bonne idée en désastre

J’ai mis à jour Cordova il y a quelques temps et depuis, les applis que je build portent systématiquement le nom de CordovaApp, ce qui est un peu casse-pied vu qu’on s’emm… à créer le container en indiquant le nom avec

cordova create repertoire nomPackage nomPublic

En faisant une petite recherche, j’ai vite trouvé comment modifier cela : il faut modifier le nom de l’app dans le manifest, par exemple dans AndroidManifest.xml :

<activity android:configChanges="orientation|keyboardHidden|keyboard|screenSize|locale" 
android:label="@string/activity_name" 
android:launchMode="singleTop" 
android:name="CordovaApp" 
android:theme="@android:style/Theme.Black.NoTitleBar" 
android:windowSoftInputMode="adjustResize">

Changez CordovaApp par le nom de l’app.

Oui mais voilà, en faisant cela, on se retrouve avec un joli message d’erreur :

Unfortunately, AppName has stopped.

Et plus rien en marche, évidemment : impossible de lancer l’app sur l’émulateur ou un téléphone. Voilà donc 10 minutes perdues en cherchant comment renommer une app et 1h perdue pour comprendre pourquoi l’appli ne fonctionne plus.

Si ça vous est arrivé, tout remettre en place n’est pas compliqué, il suffit de désinstaller la plateforme (sauvegardez vos éventuelles autres modifications) puis réinstallez-la :

cordova platform remove android 
cordova platform add android

Si vous souhaitez absolument modifier le nom par défaut de l’app, il faut aller plus loin et la renommer partout. Ci-dessous un lien vers l’explication (attention, non testé, non validé).

http://stackoverflow.com/questions/25717734/rename-application-package-stops-android-cordova-app-from-accessing-internet

 

Application mobile avec Phonegap / cordova : oui mais

Récemment j’ai eu l’occasion de répondre à un projet qui demandait une application mobile. Un petit tour d’horizon m’a permis de définir les 3 choix qui s’offraient à moi : une application web HTML5, une application native, ou bien une application hybride avec PhoneGap/Cordova.

Chaque solution avait ses avantages et ses inconvénients. Développer une appli native était exclu car je ne maîtrise ni Objective C ni Java (et il me fallait les 2 car le projet demande une portabilité pour Android et iOs, sans compter que Windows Phone arrivera dans un second temps).

Le choix a été rapidement fait, en fonction des contraintes du projet : ce serait de l’hybride.

Un apparté : hybride est un terme mal choisi mais faute de mieux, c’est celui que j’utiliserai.

PhoneGap est un projet open-source (ce qui me convient parfaitement) qui propose de développer son application en HTML/CSS/JS en ajoutant une sur-couche qui permet d’accéder à des API pour manipuler le device (le smartphone ou la tablette).

Autre apparté : pourquoi dit-on PhoneGap et/ou Cordova ? Historiquement PhoneGap appartenait à Adobe (et avant eux, à une autre boite gobée par Adobe). Comme ils ne savaient pas trop quoi en faire (ça faisait de l’ombre à Air), ils l’ont refourgué à la fondation Apache, ce qui est une bonne chose car ainsi, on est assuré de la pérennité de la licence. Sauf que Apache, pas trop sûr d’avoir le droit de continuer à l’appeler PhoneGap, a préféré le renommer en Cordova, comme ça, on est tranquille. Dans les faits, PhoneGap et Cordova sont le même outil.

Une fois l’appli réalisée, elle est packagée comme une appli native et déployable de la même manière, c’est-à-dire sur les stores ou, pour Android, à partir de n’importe où (store, web, usb…).

Oui mais…

Sauf que ce que j’ignorais, c’est que pour déployer mon appli pour iOs, il me faudra quand même un mac (compter au moins 900€ pour un mac Book Air) avec xCode (3,99€) et un compte sur l’apple Store (compter 100$ / an). Ouch.
Pour déployer mon appli pour Windows 8/Phone, il me faudra un PC sous Windows et bien sûr un compte sur le Windows Store.

Bref, rien d’insurmontable, mais des coûts non prévus qui peuvent faire mal. Je comprends pourquoi il y a moins de développeurs pour iOs que pour Android…

À noter, pour avoir un compte sur Google Play, c’est également payant, mais ça fait moins mal : 25$, à payer une seule fois.