Du renouveau pour mon blogue

Je profite d’une période de changement entre deux emplois (détails à venir prochainement) pour faire un peu de ménage dans mon blogue et je quitte la plateforme Blogger pour enfin aller sur un site auto-hébergé, en WordPress. Ça ne change pas grand chose pour les lecteurs, outre un bri des liens vers les anciens billets et un changement obligatoire du fil RSS.

J’étais limité par la plateforme Blogger et j’envisageais depuis longtemps de faire le déplacement. Manque de temps, de volonté ou simplement enfin la possibilité de le faire, voici que je viens de terminer le transfert. Que de maux de têtes. L’air de rien, jouer sur les DNS et les noms de domaines, les configurations de WordPress et tout le reste, ce n’est pas ma tasse de thé.

Malgré tout, je suis assez satisfait du résultat. C’est fait et je vous invite à me laisser des commentaires, si vous en avez!

En attendant le Nexus 6, j’ai donné un nouveau souffle à mon Galaxy Nexus!

Il y a peu, j’ai fait une mise à jour de mon Netbook Asus EeePC en lui installant ChromeOS. Ça a donné certains résultats, mais l’instabilité (et mon manque de patience, il faut dire) ont eu raison de mon Netbook… Je me suis acheté un petit PC pas trop cher et bien plus puissant pour régler mes problèmes. Mais voilà que c’est maintenant mon téléphone, un bon vieux Galaxy Nexus, qui fait des siennes. Il est lent, bouffe de la batterie sans bon sens (j’ai pourtant acheté une 3600 mAh) et est pris avec Android 4.2.2 parce que Videotron n’a pas poussé la mise à jour 4.3 disponible pour l’appareil.

Bref, je devais absolument faire quelque chose. J’attends de pied ferme le Nexus 6, mais ne l’achèterai pas à sa sortie, je veux patienter le temps que les prix baissent un peu et que les premières impressions de l’appareil soient disponibles… bref, j’en ai pour au moins six mois avec mon Galaxy Nexus (GN).

Puisque mon téléphone a plus de 18 mois d’âge (pas mal plus), Google n’a pas rendu disponible la version 4.4 d’Android pour l’appareil. Damn! Je regardais pour installer une version 4.3 stock, développée pour le GN, mais tant qu’à tout réinstaller, pourquoi pas regarder du côté de CyanogenMod? Après tout, la version 11 me permettrait d’avoir 4.4.4? Voilà, mon choix est fait!

CyanogenMod? Kossé ça?

Pour la petite histoire, il y a Android et Android. Ok, c’est pas clair.

Android Open Source Project(AOSP), c’est ce qui est derrière Android, toutes versions, et qui est le backbone de Android, le système d’exploitation de tous nos appareils. Par dessus cette couche AOSP, on rajoute les services Google, qui ne sont pas inclus dans AOSP par défaut. Finalement, on peut ajouter la couche du fabricant, soit HTC ou Samsung, pour ne nommer que ceux-là, qui s’ajoute aux précédentes.

Si vous voulez en apprendre plus sur AOSP et les services Google, je vous invite à lire ce très intéressant article sur le sujet.

C’est quoi le rapport avec CyanogenMod? En fait, CyanogenMod, c’est une version d’Android basée sur AOSP (sans les services Google ni les surcouches des fabricants) communautaire et OpenSource. À partir de là, on comprend mieux. C’est un peu comme une autre distribution d’Android… Comme les diverses moutures de Linux, si vous voulez.

Cette communauté se base donc sur AOSP pour «créer» des versions d’Android qui sont spécifiques à des appareils. Plus haut, je mentionnais que Google, de façon officielle, n’offre pas plus de Android 4.3 (Jelly Bean) pour le Galaxy Nexus. Les développeurs de CyanogenMod, eux, via la version 11, offrent une solution 4.4.4 pour mon «vieux» GN.

Ça ne s’arrête pas là. CyanogenMod intègre aussi des fonctionnalités qui, par défaut, ne sont pas toujours disponibles dans Android standard. On peut parler des notifications ou de la gestion du voyant, ou bien de fonctions de développements… Dans le cas de mon Nexus One (ma première conversion à CyanogenMod), c’était pour être en mesure d’utiliser mon téléphone malgré le bris du bouton de démarrage; CyanogenMod permettait d’utiliser le Trackball ou le bouton du volume pour «réveiller» le téléphone.

Donc, pour mon GN, cette fois, ce qui m’a poussé vers CyanogenMod, c’est la possibilité de profiter de KitKat (Android 4.4.4) sur un appareil qui n’était pas destiné à le recevoir, selon Google. Un pied ne nez, si vous voulez (et un gain en fonctionnalités aussi).

Ouais, on fait ça comment, maintenant?

C’est ici que ça se corse. J’ai eu toutes sortes de difficultés à installer CyanogenMod… ou installer quoi que ce soit, en fait, merci à Samsung et à Microsoft.

Dans le cas de mon Nexus One, installer CyanogenMod n’était l’histoire que de quelques minutes. Il en fut tout autre pour le GN. La procédure est tout de même standard. Pour les détails, je vous invite à aller voir le Wiki de CyanogenMod, mais voici un aperçu*:

  1. On installe le SDK Android sur son ordinateur;
  2. On s’assure d’avoir activé le mode Debug sur l’appareil (et, au besoin, préalablement avoir débloqué le mode développeur, hein!);
  3. On y branche notre appareil en USB;
  4. On débloque le téléphone (on va voir apparaître le petit cadenas débarré au démarrage par la suite);
  5. On installe les pilotes nécessaires (c’est ici que ça se corse pour le GN et Windows 8);
  6. Via le SDK, (en fastboot sur le bootloader) on installe le recovery de son choix (clockworkmod fait bien le boulot);
  7. Ensuite, (en recovery) on pousse via les méthodes proposées (et selon celle qui fonctionne le mieux), le fichier zippé de votre version de CyanogenMod;
  8. Je vous conseille d’installer les services Google immédiatement, tant qu’à être dans cette interface;
  9. On redémarre, et hop, c’est fini.

*À noter, tout est effacé sur l’appareil et la garantie est, de fait, complètement annulée dès que l’on débloque le téléphone et qu’on change le recovery, alors imaginez en y poussant une ROM custom… Bref, à vos risques et périls, pauvres fous!

Comme je vous l’ai indiqué, pour moi, ça n’est pas passé comme une lettre à la poste. Outre l’apprentissage des commandes Fastboot et ADB, (ce qui se fait relativement bien), le pire a été de faire que mon ordinateur et mon téléphone se parlent. C’est ici que Samsung et Microsoft sont devenus mes ennemis. Argh.

Qu’est-ce que Windows et Microsoft ont à voir avec un téléphone Android??

Les pilotes, ou drivers. Tout est dit. Mon téléphone n’était pas reconnu par mon ordinateur Windows 8.1. J’ai eu le même problème avec un Windows 7, en passant… et c’est relié… à Samsung!

Si vous possédez un Nexus, vous n’avez pas à vous arracher les cheveux de la tête, car Google offre, dans le SDK, les pilotes USB pour TOUS les Nexus… sauf le Galaxy Nexus, vous l’aurez deviné. On nous dit d’aller le chercher chez Samsung. Mais ce n’est pas si simple.

En mode ADB (Android Debug Bridge), bref, quand le téléphone fonctionne normalement et est branché en USB, tout est reconnu et je peux donner plein de petites commandes ADB au téléphone via l’invite de commandes. La joie, quoi! Mais dès que je redémarre en mode Bootloader (un peu comme le Bios sur un ordinateur), on doit passer aux commandes Fastboot. Rien à faire, la commande Fasboot devices ne donne rien: aucun appareil n’est reconnu.

C’est parce que le pilote Fastboot n’est pas installé. Mon appareil n’est pas reconnu. Généralement, Windows indique «Unknown Device» ou «Android 1.0» avec le foutu petit triangle jaune au point d’exclamation, indiquant un problème.

J’ai essayé une quantité assez phénoménales de méthodes, en allant même jusqu’à donner des droits spéciaux à Fasboot.exe pour réussir à pousser des commandes au téléphone… sans succès. Le pilote était simplement non installé, et j’étais incapable de le pousser. Jusqu’à ce que je trouve ce billet qui explique comment activer le Fastboot sur Windows 8. Je vous invite à consulter si, comme moi, vous n’êtes pas capable d’installer les bons drivers pour Windows 8.

J’ai finalement réussi.

Ensuite, un jeu d’enfant. On télécharge les deux bons fichiers (la version de CyanogenMod et les applications Google), on les dépose dans le bon répertoire (à la même place que Fastboot.exe et ADB.exe). On utilise la méthode push and install ou sideload (perso, la première n’a pas fonctionné, mais le sideload a été rapide et efficace) et zou! c’est fini.

On démarre la bête et on configure CyanogenMod. C’est un tout autre univers qui s’offre à nous (surtout quand on était pris avec un Android 4.2.2!!).

Compliqué, ton affaire…

Ouais, bon… ok, c’est peut-être un peu compliqué pour le néophyte. Je l’avoue.

Mais je suis un vieux de la vieille, faut croire. J’avais installé, il y a un peu plus d’un an, CyanogenMod sur mon Nexus One, alors j’ai appliqué la même méthode… sans réaliser qu’il y en a une nouvelle. Ben oui!

Il y a maintenant une version «Installer» de CyanogenMod. Je ne sais pas ce que ça vaut, ni c’est efficace… Si vous l’essayez, vous m’en donnerez des nouvelles. Ça semble relativement simple.

Et ça vaut vraiment la peine?

Oh oui! Passer de 4.2.2 à 4.4.4 est un pas assez intéressant dans le monde Android, surtout pour un Galaxy Nexus. Je profite de bonnes améliorations de l’interface et des performances de l’appareil, en plus de nouvelles fonctionnalités (comme la gestion des profils) qui me sont fort utiles.

Mon appareil a gagné en autonomie, et ce, grandement. J’ai pu activer des fonctions d’économie d’énergie qui n’étaient pas disponibles avant. Je ne puis dire si ce sont des améliorations propres à CyanogenMod ou à Android 4.4.4.

Contrairement au passage de Windows 7 à Chromoe OS, la conversion de Jelly Bean à Kit Kat semble être un succès. Je viens de me donner au moins six mois avant d’avoir à changer de téléphone!

J’aurai le temps de voir baisser les prix du Nexus 6 sans trop ronger mon frein!

Si vous n’êtes pas sur le Web, tant pis pour vous!

Cas vécu ce soir. Je viens de terminer des rénos, je travaillais sur un dessus de comptoir pour l’îlot de la cuisine. Bien que ce n’était pas prévu, nous avons décidé de mettre un rabat pliant à un bout pour nous permettre d’allonger la surface.

Jusqu’ici, pas besoin du Web, seulement des efforts physiques pour raboter/sabler/couper/coller/clouer… bref, des rénos. M’enfin, je vous montre le produit fini (enfin, presque, il reste deux couches d’huile à mettre… et un petit extra).

Comme vous pouvez ne pas le constater puisque le rabat est fermé, je n’ai pas de système pour tenir celui-ci. J’ai donc regardé sur Internet pour trouver les pièces nécessaires. Premier arrêt, Lee Valley, un de mes commerces habituels pour ce genre de trucs. Pas de chance, il n’y en a pas. Bon, on continue les recherches.

Pour ceux qui, comme moi, ignore le nom de ce que je recherche, ça s’appelle un «Drop Leaf Mechanism». Aucune idée du nom en français.

Je fais donc une recherche sur Google. J’en trouve chez Amazon (.com). Joie, la paire, moins de 6$. Comme je le fais souvent, pour des raisons de frais de douanes et pour simplifier le tout, je fais une recherche sur Amazon.ca. J’en trouve deux modèles, un à 20$, l’autre à 22$. Ouf. On repassera (et ils ne sont pas même pas beaux!). Bref, je veux passer ma commande mais, pas de chances.

Ça va pas bien, mon affaire. Ok, je sais qu’il y a un magasin à Québec où je pourrais trouver ce genre de truc. Je vais taire son nom, c’est trop honteux.

Je vais donc sur leur site, il y a un catalogue. Je commence à naviguer (après l’affreuse animation d’accueil). Ok, c’est dans quelle catégorie… je ne sais pas… on clique sur une catégorie, on voit une liste… à puces. Non cliquable. Pas de catalogue. Ok, je vais faire une… recherche? Quoi? pas de moteur de recherche????

Un commerce qui a un site qui annonce plein de produits, de façon textuelle, sans détails, non cliquables, sans prix? en 2014??

Voilà. C’est fait.

Je suis allé sur le site du commerce qui annonçait sur Amazon.com, j’ai commandé les pièces pour 5,25$, plus livraison, je m’en tire pour moins de 20$. Combien de personnes pensez-vous vont faire la même chose? Être un commerce qui ne vend pas sur le Web, en 2014, c’est un aveu de faiblesse face à la technologie.

Chute drastique du taux de rebond?

Je regardais les statistiques de visites sur mon blogue aujourd’hui, et j’ai remarqué une très grosse baisse du taux de rebond des visites. Je dois avouer que j’étais un peu médusé par cette statistique…

Que s’est-il passé? en fait, ça correspond à la date où j’ai changé mon code Google Analytics pour le mettre à niveau avec Universal Analytics. Un collègue m’a indiqué que c’est probablement dû à la présence de deux codes de Google Analytics dans mes pages…

Hummm… Aucun code dans le HTML du gabarit, en regardant la source non plus…Mais d’où vient ce second code?

Ah! Voilà. C’est Google Tag Manager, mon nouvel ami… J’ai effectivement configuré Google Tag Manager pour qu’il fasse le lien avec Universal Analytics directement dans mon blogue. Je me retrouvais donc avec deux codes GA sans le vouloir.

Je viens de retirer l’ancien code de Google Analytics, on verra ce que ça va donner.

C’est quoi, ça, Google Tag Manager??

Oh… j’ai oublié de vous le présenter… Oui, bon, Google Tag manager, c’est un outil offert par Google pour faire du «tagging», du suivi d’événements, sans avoir à jouer dans le code de notre CMS ou de notre site.

Au premier abord, c’est un peu complexe. J’ai cherché comment l’utiliser et je n’ai pas encore tout à fait compris. Malgré tout, comme j’ai pu le constater, ça ajoute le code Universal Analytics quand on lui demande de le faire 😉

Il existe une multitude de fonctions, de paramètres et d’actions que l’on peut mesurer. Je vous invite fortement à y jeter un oeil. Je vais moi aussi tenter de l’exploiter un peu plus et vous reviendrai avec mon expérience (si je réussis à sortir des trucs intéressants).

Mais c’est comme toute nouvelle chose, quand on l’apprivoise, des fois, ben, on se plante!

Des outils pour créer votre première application Android

Édition: Mise à jour du 10 septembre 2014, de nouveaux outils ont été ajoutés suite à l’essai d’une nouvelle approche de développement

Nous commençons, dans mon équipe, à regarder la possibilité de développer des applications Android et iOS. C’est tout à fait logique, puisque nous avons déjà ciblé des besoins de certains clients. Ainsi, le premier travail que nous désirons faire est de créer une application qui encapsule un site Internet avec quelques fonctionnalités natives de l’appareil. Rien de bien compliqué en soi.

Ainsi, un collègue et moi travaillons à mettre en place des solutions de développements pour applications mobiles Android. Pas très stressant, vous pourriez dire. Après tout, on installe Android Studio et ce qui vient avec, on configure et hop! c’est parti! Eh bien, non, ce n’est pas toujours si simple…

nous travaillons dans une grosse organisation gouvernementale et nous n’avons pas toutes les latitudes que le possesseur d’un poste de travail personnel peut avoir. Ainsi, nous devons nous assurer que les outils que nous allons utiliser seront adaptés à nos environnements.

Un autre défi auquel nous faisons face est le manque criant à l’interne de développeurs pour iOS (objective C) ou Android (Java). Nous devons donc apprendre le fonctionnement des divers environnements et langages en même temps que les méthodes de développements d’applications. Je suis privilégié d’avoir eu, dans mon passé récent, une expérience assez bonne avec l’environnement de développement Java. Une chance, sinon je n’y comprendrais rien.

Note aux amateurs de la pomme: je ne parle ici que de développement d’applications Android, mais sachez que des situations semblables ont été rencontrés du côté de iOS et que mes collègues travaillent aussi à mettre en place des solutions de développement pour que nous puissions faire des apps pour vos appareils. Non, vous ne serez pas en reste, ok?

Autre petite note: Si je partage ici les informations recueillies, c’est parce que je crois que ça peut servir à des collègues qui, eux aussi, en sont à leurs premières armes en ce qui a trait au développement d’applications Android. J’espère ainsi pouvoir aider d’autres personnes en le faisant. En aucun cas mon opinion se veut pour ou contre quoi que ce soit, je tente de garder une certaine neutralité…

Le défi: faire une application qui affiche Hello World!

Mon collègue et moi avons donc regardé diverses avenues, et pour arriver à faire son Hello World, il a rapidement renoncé à utiliser les appareils du bureau et s’est rabattu sur une solution impliquant son ordinateur personnel. J’ai décidé de reprendre là où il avait dû s’arrêter pour réussir à faire, moi aussi, un Hello World, mais cette fois en utilisant les capacités et limitations du contexte de travail.

Il faut d’abord comprendre que je n’ai pas de droits d’administration sur mon appareil, comme n’importe quel employé d’une grosse organisation. On me fournit une machine viruelle (Windows XP) pour le développement, sur laquelle j’ai les droits… et des accès Internet un peu plus poussés. Une chance!

Je vais donc exposer ici mon parcours du combattant et présenter les diverses solutions qui sont offertes actuellement sur le marché pour développer des applications Android. Attachez votre tuque avec de la broche, c’est pas toujours facile!

Les contraintes

Tel que mentionné plus haut, je travaille dans un environnement sécurisé avec beaucoup de contraintes techniques: postes barrés, Internet contrôlé, accès limités… Bref, le cas typique du travailleur du gouvernement ou de la grosse entreprise. Ces contraintes sont majeurs pour les équipes de développement car plus souvent qu’autrement, notre travail nécessite d’avoir un contrôle total sur la machine et un accès complet à Internet.

C’est pourquoi on nous fournit des machines virtuelles normalisées. Celles-ci ont un accès quasi complet à Internet et j’ai les droits d’administration. Ceci dit, ce n’est pas rose non plus. Ce sont des machines virtuelles, pas des machines physiques. On retrouve donc plusieurs limitations, outre celles des performances (on pourrait probablement allouer plus de puissance, mais dans le cas présent j’ai une machine standard) et on a de la difficulté à configurer certains trucs, comme le USB (j’en parle plus tard).

Bref, c’est le topo. Maintenant, comment arriver à développer des applications Android dans ce contexte? Voici trois options qui ont été regardées…

Les solutions testées

Mon collègue avait déjà essayé Android Studio sur sa machine virtuelle du bureau et ça avait été un échec. J’ai donc commencé à regarder d’autres alternatives qui pourraient nous servir et c’est pourquoi je commence avec deux solutions différentes…

Codenvy

Codenvy.com est un site Internet qui comporte un IDE en ligne (SaaS) pour le développement sur diverses plateformes ou technologies. Il existe un module spécifique pour Android.

J’ai fait le premier test tout simple, la version publique disponible sur leur site. En 30 secondes (j’ai un témoin), j’ai réussi à faire un Hello World! J’ai pu télécharger le fichier APK, l’installer sur mon téléphone. Un succès sur toute la ligne!

La preuve que j’ai réussi! J’ai seulement changé le texte de l’application de base, l’ai téléchargée et installée sur mon téléphone. Voilà!

Ça a commencé à se gâter quand j’ai créé mon compte sur le site (l’utilisation de Codenvy est gratuite) et que j’ai fait mes premiers projets. J’ai essayé de configurer un «repository» autre que celui de base (je me suis créé un GitHub), j’ai voulu m’assurer que mon code ne serait pas «buildé» dans l’environnement public de Codenvy… sans grand succès. Mais ce n’est pas tout. Quand vient le temps de tester l’application, il faut faire affaire avec un outil externe d’émulateur Android, Manymo.

Le produit semble excellent et fort pratique, mais il n’est pas gratuit, il faut payer…

Finalement, en consultant le tutoriel Google pour la création d’applications Android, j’ai vite déchanté. On retouve des fonctions dans Android Studio qui ne sont pas offertes dans le IDE de Codenvy. Bien que tout soit possible de façon manuelle (comme le «add activity»), c’est beaucoup plus complexe et, vu notre niveau de connaissances dans le domaine, un peu d’aide de l’interface n’est pas de refus….

Bref, bien qu’une solution fort pratique, efficace et adaptée pour certaines organisation, dans notre contexte, elle perd de son charme. On se rend bien compte que Codenvy ne permettra pas de répondre à nos besoins internes. Peut-être que la solution plus étoffée, ultérieurement, pourra être à envisager, mais malheureusement pas à court terme.

J’ai donc dû continuer à investiguer pour d’autres solutions…

PhoneGap

Avant d’aller plus loin, je tiens à rappeler que notre principal objectif, pour nos premières applications, est de créer une coquille qui encapsule un site Internet mobile et qui permet d’utiliser certaines fonctions natives de l’appareil. J’ai donc fait des recherches en ce sens. Ce qui m’a mené vers Phonegap.

Le fonctionnement de Phonegap est complètement différent de Android Studio ou autres. C’est en fait un serveur Web qui roule dans un application et qui permet de faire fonctionner un site HTML-CSS-JS local. Bref, exactement ce que je voulais (ou à peu près). J’ai donc commencé à regarder de ce côté.

La beauté de cette solution, c’est que les applications sont développées en HTML-CSS-JS, des technologies maitrisées par notre équipe, et on ne fait que les encapsuler dans PhoneGap. Encore mieux, l’outil est hybride et permet la création d’applications iOS ou Android! Bref, une belle idée. Elle existe en plusieurs «déclinaisons», dont une version, disons, lignes de commandes, et une autre qui a été mise en place par Adobe. J’ai essayé les deux.

PhoneGap installé sur ma machine virtuelle

Tout d’abord, je dois dire que c’est assez… aride, comme outil. Le retour de la bonne vieille ligne de commande! Il faut commencer par installer Node.js, puis on lui passe des commandes pour installer PhoneGap. Ça se passe généralement bien, en autant que nous ayons les droits d’administration sur le poste. J’ai donc tout fait sur ma machine virtuelle.

L’installation se fait relativement simplement, c’est à l’utilisation que ça se complique…

Une fois la commande intstall complétée et create faite, ça commence à se gâter. Je n’ai jamais réussi à faire le run android, la fonction qui me permettrait de créer l’application Android. Pourquoi? j’obtiens une erreur avec Ant, un outil qui permet de «builder» des applications.

Oh, je vous vois venir, petits coquins… vous allez me dire: «Ben voyons! c’est parce que tu n’as pas configuré tes variables système, pauvre cloche!». Ce à quoi je répond: «Non, mais, vous me prenez pour qui, hein?». Bien entendu que j’ai configuré les variables d’environnement, tsé. Hein. (Me semble, ouais! pfff! Sans blagues… continuez comme ça et je m’en vais!)

Euh.. bon… ok. J’en étais aux variables d’environnement, hein… Donc, Ant ne fonctionne pas. J’ai configuré les variables d’environnement comme il se doit, mais je suis incapable de faire fonctionner le tout sur la machine distante. Pour fin de comparaison, j’ai fait le même exercice sur ma machine physique et, cette fois, la commande s’exécute sans problème et me donne une erreur, qui était attendue (puisque c’était seulement un test, Ant répond en me signalant une erreur – sur la machine virtuelle, Ant n’est même pas reconnu).

Dans la portion du haut, on voit que la commande ant n’est pas reconnue par le système, or, sur ma machine physique, qui possède les mêmes configurations de variables d’environnements, la commande s’exécute et donne l’erreur attendue.

J’ai cessé les recherche à ce moment, un peu découragé. Je me suis tourné vers la version Adobe.

PhoneGap Build version Adobe

Adobe offre une solution de création d’applications encapsulées par Phonegap build. Je me suis donc branché, j’ai créé un fichier HTML tout simple avec un «Hello world» en H1, «uploadé» et, zou! j’avais une application Android (j’aurais pu la faire iOS ou BlackBerry ou même Windows si je voulais… Il ne me manquait que les clés nécessaires).

J’ai eu plus de succès avec la version Adobe, puisque j’ai réussi à créer une «application» en quelques secondes. Un fichier HTML avec un H1 qui dit «Hello World», encapsulé dans l’application.

Ouah! ça c’est efficace! Une minute à peu près et j’avais fait mon Hello World! Mais il devait y avoir un petit quelque chose de travers, non? Eh bien oui. L’application, à l’installation, me demande TOUTES les permissions. Il faut accepter qu’elle puisse accéder au micro, appareil photo, GPS… Bref, un peu exagéré…

Quelle ne fut pas ma surprise de voir le nombre d’autorisations requises, pour un simple fichier HTML encapsulé! Et ça va plus bas en plus!!

Ok, probablement que ça se change, via une configuration ou autre, j’ai pas poussé plus loin. Une autre raison c’est que ça ne satisfaisait pas le besoin initial, soit d’encapsuler un site Internet qui, lui, ne serait pas local. Il ne m’était pas possible de prendre le site et l’envoyer dans le truc Adobe. Bref, encore un dead end.

Ça peut tout de même servir pour certains trucs, ça reste à voir!

Android Studio sur une machine virtuelle

Bon, eh bien, me voici revenu à la case départ. Je devais reprendre là où mon collègue avait jeté la serviette et essayer de faire fonctionner Android Studio sur ma machine virtuelle.

Ironiquement, c’est relativement simple à faire. On installe Android Studio, on le démarre, pour se rendre compte qu’il manque le JDK, qu’on va aussi installer… On redémarre Android Studio, pour apprendre à nouveau qu’il faut installer le Visual C++ 2010 service pack 1 parce qu’une DLL est absente. Joie. Bon, on peut commencer maintenant?

Oui, c’est possible. Enfin. Donc on configure le SDK, on ajoute des émulateurs via le Android Virtual Device manager et, là, on est prêt à se lancer dans le vide en suivant le tutoriel.

Oui, ça fonctionne. Je suis capable de faire des trucs, rouler une application et jouer sur les configurations, mais c’est d’une lenteur exécrable. Les émulateurs sont instables, quand ils fonctionnent… Il faudrait allouer beaucoup plus de ressources à la machine virtuelle pour que ce soit fonctionnel, mais bon, ça peut marcher… jusqu’au moment où on veut gérer un appareil physique…

Basic4Android (basic for android)

Une nouvelle famille d’outils se sont joints à l’arsenal du développeur pour nous permettre de rapidement mettre en place des solutions mobiles, soit Basic4Android, un outil de développement sur Windows qui utilise le SDK Android et qui traduit les commandes Basic en éléments propriétaires pour la plateforme mobile.

Je dois dire que je ne suis pas un spécialiste, ni de Java, ni de Basic (ça va mal, hein?), mais il semblerait que ce soit une solution prometteuse. Surtout qu’il existe le pendant pour Java, B4J, qui fonctionne sur le même principe et qu’une solution pour iOS est dans les cartons. Bref, une idée qui a un certain charme, surtout lorsque le personnel de l’équipe connaît Basic et .Net, mais pas Java!

Des premières preuves de concept ont été faites et ça semble fort prometteur. Nous n’avons utilisé que la version gratuite (démo) pour l’instant, ce qui ne nous permet pas de pousser à fond l’utilisation de certaines librairies qui ne sont pas disponibles pour cette version (ex. Google Maps), mais on a déjà des éléments de Back-end et de Front-end qui fonctionnent.

Les écueuils

On a vu, tout au long de mes expérimentations, que j’ai vécu des désagréments à plusieurs niveaux. À certains moments, c’était purement technologique, d’autres fois, presqu’idéologique (comme les permissions). Aucune solution ne semble meilleure qu’une autre jusqu’à maintenant.

«Oh, mais la solution avec Android Studio sur la machine virtuelle, c’est correct, non?» vous entends-je dire. En fait, j’y viens à l’instant.

Brancher un appareil en USB

Une des particularités du SDK Android, c’est qu’il nous permet de gérer un appareil physique (téléphone ou tablette) par le biais du port USB de notre ordinateur. C’est via les commandes ADB qu’on peut le faire. C’est d’ailleurs grâce au SDK que j’ai déjà réussi, il y a quelque temps déjà, à installer CyanogenMod sur mon Nexus One. Pas facile au premier abord, mais franchement utile (surtout que le bouton on/off de mon appareil venait de rendre l’âme…).

L’autre utilité est de pouvoir tester une application en développement sur l’appareil physique plutôt que sur un émulateur. Ça peut donner des résultats surprenants (on l’a bien vu lors de tests d’utilisabilité).

Voilà donc que le problème se pose avec une machine virtuelle. Celle-ci n’est pas en mesure d’accéder au port USB de l’appareil qui appelle la machine distante (car elle est sur un serveur distant, hein, je ne vous l’avais pas dit celle-là!). Ça règle la question: pas de ADB sur USB.

Quand vient le temps d’installer le SDK sur mon poste physique, ça fonctionne après plusieurs étapes dont je vais vous faire grâce, mais impossible d’installer le pilote de la tablette ou du téléphone… je ne suis pas administrateur du poste.

Je tourne donc en rond. Encore.

C’est là que Basic4Android vient ouvrir une porte intéressante, soit l’opportunité d’utiliser une connexion Wifi pour communiquer avec un appareil physique, soit une solution ADB over Wifi. Ok, ça nécessite que les deux appareils soient sur le même réseau Wifi, on devrait être capable… reste qu’avec une machine virtuelle, il va falloir faire quelques tests encore.

Conservation du code source

Dans les solutions en ligne, telles que Codenvy et Adobe PhoneGap, un problème assez important est la propriété du code source, là où sont déposés les builds, ce qui se passe avec… bref, encore des problèmes à régler.

Nous avons un GIT interne pour nos développements, mais il n’est pas accessible de l’externe… et est-ce une bonne idée? Une passerelle? une autre solution? Ça reste à explorer… nonobstant les autres problèmes rencontrés.

Lenteur de la VM

Bien que la solution de la VM soit à peu près viable si on exclut l’accès au USB, il n’en demeure pas moins qu’elle présente un gros problème de lenteur. Au point où chaque clic de souris prend de une à trois secondes avant que l’action se passe. Ça empire dès lors où je commence à entrer des commandes ADB.

Un test avec une VM plus puissante donne des résultats semblables. Peut-être est-ce simplement lié au fait que ce ne sont pas des machines physiques. Nous avons d’ailleurs eu un problème avec les émulateurs, qui nécessitent des accélérateurs ou des accès au processeur, ce qui n’était pas possible sur la VM. Bref, des performances à valider.

En conclusion

Note: suite au test de Basic4Android, j’ai dû revoir ma conclusion 😉

Quelle est la meilleure solution? Actuellement, aucune. Il n’est pas possible de développer des applications Android présentement avec les ressources actuelles. Nous avons mis en place des solutions alternatives grâce aux équipes sur le plancher, mais elles sont embryonnaires et nécessitent plus de tests. je dois dire que nous regardons très fort du côté de Basic4Android et de B4J. Il devient donc possible d’envisager la création d’applications Android avec une équipe qui n’est pas spécialiste Java et avec des machines virtuelles.

Bien entendu, une telle solution a tout de même de grosses limites. Nous devrons tout de même nous assurer de développer des connaissances internes dans les divers langages utilisés, ne seraita-ce que pour régler des bugs et nous assurer d’une performance des applications développées.

Donc, à court terme, nous allons pousser plus loin de ce côté, nous verrons pour du plus long terme.

Je tiens à rappeler que c’était une preuve de concept. Je partage dans ce bloque les résultats car je crois que mon expérience vécue pourra fort probablement aider d’autres personnes dans des organisations, gouvernementales ou non, à avancer dans la mise en place d’environnements de développement pour Android.

Si vous avez d’autres pistes de solutions à me proposer, je suis preneur!