Comment

Redesign : Jungl

Cela faisait un bon moment que je n'avais pas fait un redesign d'application. Pour info, un "redesign" consiste à prendre une application Android et recréer son interface utilisateur sous forme de maquette. Le but étant de montrer les possibles évolutions et améliorations possibles pour l'application concernée.

L'application

 

Pour ce redesign, j'ai donc choisi l'application Jungl. Pourquoi Jungl ? Parce que les fondateurs de cette start-up m'avaient contacté pour éventuellement réaliser l'application (ils ont préféré choisir de passer par une agence) et que je trouvais le projet sympa, tout comme les fondateurs.

Alors, qu'est-ce que Jungl ? Jungl permet de découvrir des applications via des recommandations de vos amis. Un flux d'actualité permet de voir quelles applications sont recommandées et via un simple geste "swipe" vers la gauche, on peut ajouter l'application à notre "bucket" (panier) tandis qu'un swipe vers la droite indique qu'on ne souhaite pas revoir cette application. Bien sûr, on peut aussi installer directement l'application.

Jungl est vraiment sympa pour découvrir des applications, chose qui devient difficile étant donné le nombre toujours grandissant d'applications disponibles sur le Play Store.

L'application est cependant encore en Bêta (donc il y a encore des bugs).

Le flux d'actualités (feed)

Version actuelle à gauche, redesign à droite

Première partie, le flux actualités.

La première chose qui choque, c'est le manque de la barre d'action en haut. On a bien un titre (Jungle feed) mais pas de fond associé à une barre d'outils. En dessous, on peut voir un sous-titre, "Swipe, share, discover" (Glisser, partager, découvrir), qui reflète bien l'esprit de l'application. Personnellement, je ne vois pas l'intérêt de ce sous-titre ici.

J'ai donc remplacé le titre et le sous-titre par une barre d'action. Le titre est "feed", je ne pense pas qu'ajouter "Jungl" devant chaque partie soit important, on sait déjà que l'application s'appelle Jungl. J'ai ajouté l'icône pour le menu hamburger à droite, et le fond est bleu, reprenant le bleu de "Jungl feed". On notera aussi que la barre de status (heure, wifi, batterie, ... ) a un fond bleu foncé pour l'esprit Material Design.

Passons maintenant à la liste des cards (cartes). On peut voir deux types de carte. La première, sur l'écran de gauche, permet de voir qu'un ou plusieurs amis Junglers ont partagé une application. On peut voir l'image de profil du Jungler ainsi que l'icône de l'application. Entre les deux, on a l'impression de voir du texte coincé entre deux images. Enfin, une description (coupée) de l'application partagée se place un dessous des images.

La seconde, sur l'écran du milieu, affiche une carte regroupant des commentaires sur une application partagée par plusieurs amis Junglers. On peut voir l'icône de l'application mais son nom est manquant, faute de place, ce qui est un peu gênant et la description n'est pas non plus affichée.

Notez que chacune de ces cartes est cliquable et mène vers la fiche détaillée de l'application partagée (voir un plus bas).

L'écran de droite reflète ma solution. J'ai regroupé les deux cartes en une seule et même carte. La partie du haut permet de voir combien d'amis ont partagé l'application. En plus de cela, on peut aussi voir les "hashtags" attribués par les amis à cette application (ces hashtags sont aussi présents dans l'application actuelle même si les présents écrans ne les font pas apparaître, désolé). 

La partie centrale présente l'application. J'ai pris soin d'ajouter l'image de présentation de l'application afin d'avoir un visuel de plus. En effet, les images sont très importantes dans une application et améliorent l'esthétisme général, pour peu qu'elles ne soient pas pixelisées. Le titre est mis en avant par sa taille et la description est en fait le texte d'accroche de l'application, non une partie de la description complète.

Pour finir, la partie du bas présente les deux premiers commentaires sur cette application. J'ai volontairement limité à deux commentaires pour ne pas obtenir une carte trop longue en hauteur, l'utilisateur pourra voir les autres commentaires s'il clique sur la carte pour voir la fiche de l'application.

Au final, on obtient une carte plus claire, plus sobre et plus visuelle.

Le menu

Version actuelle à droite, redesign à gauche

Le menu est... bizarre. Cela ressemble à un navigation drawer sans en être vraiment un. Premièrement, il n'est pas assez large. Par contre il est trop grand et passe ainsi sous la barre de statut en haut et sous la barre de navigation en bas. Ce qui a pour effet d'avoir un bouton de déconnexion, en bleu, derrière la barre de navigation et presque inaccessible.

Deuxièmement, les icônes sont clairement trop petites. 

Troisièmement, on ne sait pas si l'écran actuel, feed, est sélectionné car il n'y a aucune indication visuelle.

Enfin, on peut voir une liste d'amis, qui n'a rien à faire ici. Le navigation drawer est réservé à la navigation entre les écrans de plus haut niveau, or un ami n'est pas écran de plus haut niveau, contrairement à la liste d'amis (représenté ici par la section "Friends").

J'ai donc mis à niveau tout cela sur l'écran de droite. Le menu respecte les tailles standards et la couleur dominante est le bleu de "Jungl feed". Puisque l'application ne permet de se connecter que par Facebook ou Google, autant utiliser les informations de l'utilisateur disponibles. J'ai donc ajouté une section de profil reprenant l'image de profil, la photo de profil ainsi que l'adresse email de l'utilisateur. Comme je le disais plus haut, les visuels sont très importants pour un meilleur design. J'ai déplacé le bouton déconnexion dans cette section, ce qui le rend beaucoup plus accessible.

Les icônes ont été agrandies et sont passées à la couleur dominante. La section sélectionnée est ici visible par un texte bleu, quand les autres sont noirs. J'ai choisi un fond blanc pour le menu car c'est ce qu'on retrouve sur la plupart des applications et cela permet un rendu plus clair. Sans oublier le filtre sombre sur le reste de l'écran, à droite, chose que l'on ne retrouve pas sur l'application actuelle.

Pour finir, la liste des amis a été purement et simplement supprimée.

Fiche de l'application

Version actuelle à droite, redesign à gauche

On peut voir que l'application actuelle, à droite, essaye de caser toutes les informations sur un seul écran, seule la partie centrale sur fond blanc étant scrollable, ce qui n'est pas forcément une bonne idée. De plus, la fiche apparaît sous la forme d'une pop-up (ou boite de dialogue). Un bouton "Screens" en haut à gauche permet de voir les captures d'écran de l'application en plein écran. Enfin, une section affichant les utilisateurs ayant cette application est affiché en dessous les captures d'écran, faisant doublon avec le bouton "Qui a cette app ?".

Pour ma part, je me suis largement inspiré du Play Store, je pense que cela est assez visible. Je sais que Jungle essaye de se démarquer du Play Store mais celui-ci a l'avantage d'avoir une présentation sobre, belle et claire.

J'ai néanmoins ajouté quelques éléments dont le bouton flottant bleu permettant d'ajouter l'application directement au bucket. On peut aussi voir les différents hashtags de différentes couleurs directement sous le nom de l'application.

La partie commentaires affiche les 3 premiers commentaires et présente aussi les hashtags attribués par les différents utilisateurs, reprenant les mêmes couleurs que précédemment. Un bouton en bas de l'écran permet de consulter la liste de tous les avis.

Côté détails, les bouton "Lancer l'app"/"Installer", "Partager" et "Qui a cette App ?" ont été passées au Material Design. Le bouton "Screens" a été supprimé, le mode plein écran étant atteignable simplement un cliquant sur une capture d'écran.

Petit mot de la fin

Je n'ai pas effectué un redesign complet de toutes les parties de l'applications car cela n'était pas mon but et requerrait trop de travail. Le but était de montrer que l'interface et l'expérience utilisateur pouvait être largement améliorés dans une version future de l'application, en respectant mieux les directives de design d'Android et en utilisant le thème Material Design introduit par Android Lollipop (5.0).

Comment

Comment

Développeur mobile Freelance ou agence web/mobile ?

Choix du prestataire technique

Vous êtes porteur de projet et vous souhaitez réaliser une application Android (ou iPhone) pour smartphones et/ou tablettes. Quelle est la première solution qui vous vient à l'esprit ? Une agence web/mobile bien sûr !

Évidemment, la solution saute aux yeux. L'agence est dans la majorité des cas la seule solution qui vient à l'esprit. Une agence offre de nombreux services, peut mettre plusieurs développeurs en parallèle sur le projet (e.g. un temps de développement plus court), dirigés par un chef de projet, et vous avez un responsable qui s'occupe du bon déroulement et qui vous tiens au courant des avancées projet.

L'agence vous fournira un devis basé sur votre cahier des charges technique et vous n'aurez plus qu'à attendre sagement la fin du projet. Une vraie solution "pro" !

Dans la vraie vie, les choses se passent... différemment. 

Côté technique

Premièrement, l'agence web vous proposera une solution web, de type HTML5/Javascript utilisant Cordova/Phonegap (sur Android). Logique. Car l'agence web fait avant tout des sites web, qui sont programmés avec des technologies web. Et puisqu'il est possible de créer des applications Android/iPhone avec les technologies web, pourquoi s'en priver ? Cela évite de devoir se former aux technos Android/iPhone ou bien d’employer des développeurs spécialisés Android/iPhone.

Deuxièmement, l'agence web vous avancera l'argument que grâce aux technologies web (aussi appelées "hybrides"), il suffit de coder le projet une seule fois et vous obtiendrez une application compatible Android et iPhone, c'est-à-dire qu'à partir d'un seul et même code, on produit une application Android et une application iPhone. Il est évident que dans la majorité des cas, le client désirera produire à la fois une application Android et une application iPhone, en cherchant à obtenir une interface similaire sur les deux plateformes. L'argument vous présentera les avantages suivants : gain de temps (on ne programme qu'une seule fois pour les deux applications) donc économie d'argent, une seule et même interface, mises à jour simplifiées (encore une fois, on ne programme qu'une seule fois).

Ce que l'agence ne vous dit pas, c'est que les technos web ne sont pas le meilleur choix pour réaliser des applications Android ou iPhone. Vous pouvez prendre les 100 applications les plus téléchargées de chaque app store (hormis les jeux), aucune n'utilise de technologies web/hybrides. Pourquoi ? Parce qu'il est très difficile de réaliser une application de qualité avec les technologies web. Chaque système utilise un langage natif (Java pour Android, Objective-C/Swift pour iOS) permettant d'obtenir des performances élevées ainsi qu'un ensemble d'outils intégrés au système permettant de produire des applications utilisant les éléments graphiques propres à chaque système.

Les technologies web quant à elles ne peuvent égaler le niveau de performance des technologies natives. Pire encore, elles permettent de produire un peu tout et n'importe quoi au niveau design, mais surtout n'importe quoi. Au final, on se retrouve avec une application qui ne ressemblent ni aux standards d'interface et d'expérience utilisateur d'Android, ni à ceux d'iOS.

Coté réalisation

Avant toute chose, je tiens à dire que je n'ai pas inventé pas les histoires relatées ci-après au hasard, mais qu'elles proviennent bien d'expériences de clients avec lesquels j'ai collaboré.

Ces histoires concernent des agences mobiles, utilisant des technologies natives.

La première concerne une start-up qui m'a contacté pour réaliser leur projet d'application Android. Les fondateurs étaient (et sont toujours d'ailleurs) super sympas et m'ont présenté leur projet dans leur locaux. Après plusieurs échanges d'idées et d'informations techniques, je leur propose un projet en méthode agile (le projet était trop gros pour un devis) mais 2 mois de développement me paraissait être le maximum requis, soit 20 000 € (pour 40 jours de développement).

Plusieurs mois plus tard, les fondateurs m'annoncent qu'ils ont préféré opter pour un studio (c'est-à-dire une agence). Nous étions alors fin Septembre.

Mi-février, à la sortie de leur application en version beta, je leur remonte mes remarques et mes idées concernant cette première mouture. À ce stade, l'application comporte quelques bugs (mais pour une version beta, rien d'anormal), le design laisse à désirer et  je trouve l'application très difficile à utiliser (au niveau de l'expérience utilisateur). L'un des fondateurs me répond qu'ils ne sont "pas forcément content du travail de l'agence".

Mi-mars, je reprend des nouvelles. Le même fondateur me répond cette fois qu' "En gros l'agence n'a pas du tout respecté le cahier des charges donc on a perdu beaucoup de temps et d'énergie avec tout ça [...] Concernant le CDC [Cahier des charges, NDR] est une mésentente globale et vu qu'on a aucun Dev mobile ou Dev tout court dans l'équipe, ils nous ont sans doute pris pour des pinpins... Ce qu'on est d'ailleurs.". Avant cet email, je n'avais pas retesté l'application. Aujourd'hui (le 22 mai donc), je réinstalle l'application. Le chargement initial est long mais c'est normal étant donné les fonctionnalités de l'application. L'expérience utilisateur est toujours aussi pauvre, le design est très loin d'être parfait et les standards d'Android ne sont toujours pas respectés même si on peut voir quelques améliorations depuis la dernière fois. Les performances ne sont pas au top car un simple défilement rapide sur une liste fait ralentir l'application et j'ai même eu droit à un crash car l'application avait tout simplement freezé.

Bref, après environ 6 mois de développement, l'application n'est pas vraiment ce que j’appellerai une réussite.

 

La deuxième histoire concerne là aussi une start-up, accrochez-vous. Mi-avril dernier (le mois dernier donc), je reçois un message du fondateur qui a "besoin d'une ressource additionnelle, car nous avons pris du retard sur le portage de notre application et c'est un peu le rush". Jusqu'ici, je me dis que la situation n'a rien d'extraordinaire pour une start-up. Je télécharge ensuite la version iPhone de l'application. Bon, je vous avoue que je ne suis en rien expert en applications iPhone (même si j'ai fait du développement iPhone il y a quelques années) mais je ne trouve pas l'application géniale. Étant donnée mon manque de connaissances du système, je me dis que cela doit être normal.

Le lendemain, j'ai accès au projet sur Github et je peux donc tester l'application Android. Le constat ne se fait pas attendre : le design est déplorable (il y avait même des éléments d'interface d'Android 2, 2010 : bonjour !), l'application était difficilement utilisable/compréhensible, les performances donnaient envie de désinstaller l'application directement (attendre 3 secondes pour l'application d'un filtre sur une image...) et je ne parle même pas des nombreux crashs. Tu m'étonnes qu'il ait besoin d'aide !

Je ne peux alors m'empêcher de demander au fondateur comment il est arrivé à produire une application si médiocre. L'explication est affligeante : une première version de l'application a été produite par une agence. Après plusieurs mois de développement et une application inutilisable, le fondateur décide de recommencer à zéro et de passer par une autre agence. Pas beaucoup plus de chance avec celle-ci. Il m'annonce alors vouloir publier l'application d'ici 3 semaines, en partant de la base existante et que pour cela, il engage plusieurs freelances dont certains sont déjà au travail. 

Un mois plus tard, l'application offre des performances incomparables à l'ancienne version (l'application de filtres d'image est instantané), le design a été revu pour certaines parties et l'expérience utilisateur a été amélioré. Je n'irai pas jusqu'à dire que l'application est parfaite car elle est encore loin de mes standards de design et d'expérience utilisateur mais compte tenu de la version sur laquelle nous étions partis, je trouve que c'est quand même une belle réussite. L'application devrait être publiée d'ici une semaine.

Je n'ai personnellement travaillé que deux semaines sur l'application (car évidemment, après deux échecs consécutifs, le budget de développement était plus que restreint), principalement sur les parties filtres/génération d'images et connexion/inscription. Rarement je n'ai vu un tel bazar dans le code. C'était tellement du travail d'amateur que certaines parties du code me paraissaient incompréhensibles quand bien même cela était censé être ultra basique et simple.

Toutes les agences ne sont pas comme ça...

Je vous ai peut-être fait peur avec mes histoires. J'imagine facilement que cela ferait peur à n'importe quel entrepreneur et je suis certain que les agences ne seraient pas très contentes de lire cet article. Désolé, mais c'est pourtant la réalité, tout du moins par rapport à mes expériences personnelles.

Néanmoins, il existe certaines agences qui font de l'excellent travail, je ne le conteste pas. Le problème, c'est que ces agences, comme les freelances expérimentés, sont rares. Par exemple, sur Nantes (où j'habite actuellement), sur l'ensemble des agences web/mobiles (une trentaine environ), je ne recommanderai qu'une seule agence qui réalise de superbes applications. Une seule. Et elle est spécialisée dans la production d'applications mobiles.

Alors : freelance(s) ou agence ?

La réponse est simple : Vous pouvez choisir l’un ou l’autre, le réel problème étant de trouver le freelance ou l’agence spécialisé dans les applications mobiles qui saura vous conseiller au mieux si vous êtes néophytes dans ce domaine car c’est bien cela le plus important.

Si je devais vous donner un conseil concernant les agences, ce serait d'éviter les agences "web". Car leur cœur de métier, ce sont les sites web, auxquels ils sont plus que recommandables j'en suis sûr. Mais les applications mobiles sont un tout autre domaine.

Quant aux freelances, ne jugez pas que par leur TJM (tarif journalier moyen). Certes un développeur débutant avec un TJM de 350 € semblera peut-être moins cher au premier abord. Mais le développeur expert, au TJM de 500 €, nécessitera moins de temps pour réaliser l’application. Après un rapide calcul durée x TJM, il n’est pas certain que le développeur débutant soit moins cher que le développeur expert.

Et même s’il était moins cher, il est toujours intéressant de prendre en compte l’expertise apportée par le freelance expert, à savoir les précieux conseils techniques, les connaissances pointues du système Android, du design, des standards en matière d’UI (interface utilisateur) et UX (expérience utilisateur) ainsi que la qualité de l’application finale.

Enfin, le même conseil s'applique aux freelances pour la réalisation d'applications mobiles : préférez les développeurs qui utilisent des technologies natives plutôt que des technologies web.

 

Notez que je n'ai pas écrit l'habituelle comparaison freelance vs agence où on vous sort les classiques avantages/inconvénients par rapport au coût, la communication, la flexibilité, etc... Ce n'était pas mon objectif et je suis sûr que vous pourrez trouver de nombreux articles à ce sujet via une simple recherche sur Google.

Vous noterez aussi que je n'ai pas mentionné la question du budget. D'une part, je ne connais pas les tarifs appliqués par les différentes agences et d'autre part, cela dépend en grande partie du type de projet. Certains projets peuvent nécessiter le travail de plusieurs freelances en parallèle (un graphiste, un ergonome, un développeur mobile, un développeur backend, ...) là ou une agence propose un forfait sur un projet global car l'agence peut embaucher des personnes (stagiaires, débutants, experts ou encore freelances !) au besoin. Mais le client peut aussi n'avoir besoin que d'un développeur mobile, le reste étant effectué en interne. Les projets sont diverses et variés, c'est pour cela que je ne me risquerai pas à édifier une comparaison globale.

Comment

Comment publier une librairie pour Android Studio sur Maven

Comment

Comment publier une librairie pour Android Studio sur Maven

L'avantage d'Android Studio sur Eclipse c'est la possibilité de pouvoir ajouter une librairie externe avec une seule ligne de code dans le fichier gradle. C'est aussi simple que ça :

compile 'com.exemple.masuperlib:library:1.0.0@aar'

Personnellement, je pensais pouvoir publier ma petite librairie perso sur Maven en 2 minutes. Ensuite, je pourrai utiliser ma librairie très utile dans tous mes projets en ajoutant une ligne de code dans le fichier Gradle. J'ai très vite déchanté quand j'ai passé plusieurs heures pour accomplir cette "simple" tâche. Cela m'a quand même pris une demi-journée au final ...

La procédure n'est pourtant pas bien difficile, ce sont plutôt les informations qui sont difficiles à trouver pour publier une librairie sur Maven.

Pour vous éviter ce calvaire, voici les informations dont vous aurez besoin ainsi que la procédure à suivre.

1. Créer un compte sur Sonatype

1.1 Créer un compte

Sonatype est l'un des hébergeurs de Maven. Vous devez vous inscrire pour pouvoir y publier une librairie Android (ou toute autre librairie). Bizarrement, il faut s'inscrire sur la plateforme JIRA de Sonatype. Pour ceux qui ne connaissent pas JIRA, c'est une plateforme de gestion de bugs et de projets.

1.2 Créer un ticket

Une fois inscrit, vous devez créer un ticket. La validation du ticket prend jusqu'à 48h, en fait les équipes de Sonatype vérifient manuellement chaque compte. Dans mon cas, cela n'a pris que 3 petites heures.

Attention ! Pour la case Group Id, ne renseignez que votre nom de domaine inversé. Par exemple, mon nom de domaine est www.abewy.com, j'ai donc renseigné com.abewy seulement. N'indiquez pas le nom de votre librairie comme par exemple com.abewy.masuperlib. En renseignant seulement le nom de domaine, vous pourrez par la suite ajouter plusieurs librairies, par exemple, dans mon cas : com.abewy.superlib1, com.abewy.superlib2, etc...

1.3 La console Nexus (ou OSSRH)

Une fois le compte validé, vous pouvez accéder à la console Nexus, c'est par ici. C'est dans cette console que vous allez gérer votre repository. Si vous souhaitez avoir plus de détails, vous pouvez consulter cette page (en anglais).

2. Créer votre librairie

Votre librairie est sûrement déjà créée si vous cherchez à la publier sur Maven mais si ce n'est pas le cas, vous n'avez qu'à chercher sur Google pour apprendre à créer une librairie Android (et oui, ce n'est pas le sujet de cet article et vous allez très bien vous débrouiller sans moi).

3 Publier la librairie sur Github

Si ce n'est pas déjà fait, vous devez publier la librairie sur Github ou tout autre repository. Là encore, je vous laisse vous débrouiller, la documentation sur Github n'est pas ce qui manque sur le net.

4. Créer une clé GPG

4.1 Installer GnuPG

Afin de publier sur Maven, vous allez avoir besoin d'une clé secrète GPG. Pour générer cette clé, vous allez avoir besoin de GnuPG. Installez GnuPG en téléchargant l'éxécutable correspondant à votre plateforme depuis cette page (en bas).

4.2 Générer la clé

Ouvrez un terminal de commande et entrez la ligne de commande suivante : 

gpg --gen-key

On va vous demander plusieurs infos dont votre nom, votre adresse e-mail et un commentaire pour la clé. Avant cela, on vous demandera d'autres infos, entrez les valeurs par défaut, à savoir dans l'ordre : 1, 2048, 0, y.

Maintenant que vous avez généré votre clé, vous pouvez la voir en listant les clés disponibles :

gpg --list-keys

La première ligne vous indique où est stocké la clé publique (pubring.gpg).

La 3ème ligne, commençant par pub, décrit la clé. 1024D signifie que la clé est longue de 1024 caractères, ED70DACF est l'identifiant hexadécimal unique de la clé et 2015-03-24 la date de création.

Vous aurez besoin de l'identifiant par la suite.

 

Vous pouvez aussi utiliser :

gpg --list-secret-keys

pour lister les clés privées

4.3 Publier la clé publique

Android studio va utiliser la clé privée pour sécuriser votre librairie. Pour que Maven puisse la décoder, il a besoin de connaitre la clé publique. Pour obtenir la clé publique, Maven va chercher votre clé sur des serveurs de clés publiques. Il existe plusieurs serveurs et ces serveurs se communiquent les nouvelles clés entre eux. Vous n'avez donc qu'à publier votre clé sur un seul serveur.

Entrez la ligne de code suivante dans le terminal :

gpg --output pubkey.txt --armor --export ED70CADF

en remplaçant ED70DACF par l'identifiant de votre clé. Que fait cette ligne ? Elle transforme votre clé en code ASCII et l'écrit dans le fichier pubkey.txt. Maintenant ouvrez pubkey.txt, vous devriez voir quelque chose qui ressemble à cela : 

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.7 (MingW32)

mQGiBFUR2/wRBACxBlmZUBMT2Fepkynzensdme/NIl5Pgd9ugdQA0R4JHd71XK2B
K+o7r1SlbacUa7wBRzwDz04itJ3qdoXYgLCoXLuY82JhbxnIIUl61MgjlqGO5lej
DwKH2QfLx/fz6HnvPL0rJSSLnDp/w9eCuIOfFWem0g6zTLCXN/7od5efNwCg5Fsu
3evmweNN6o8Vvf6XAF6mtG0D/R4v/46H1qCx6yt6Ains4AJtPrNrfd45jME1Y6mo
Qj7jWsCkjfjlIldWFgMw3svfyejHShwNFaySykdyhipXruI91VBjyU5GABTIsJky
srZJL3JuSg7zDpybNOQ9rt/OrtBWCb/TBzybo4pEgsdEVPx5REDC91nerdbHZbtb
ixIRA/4hfehEU14/GmfLsc8NwDz1zIlzFtS+zzXJphfswJicVq3iZQR4nj9cruQk
uvA1yeZPLyE/bvNdPodgjnxTXSRsyIS7K6dlyzHLiWMRx5LeKEWu0n2icurFQXlP
zU2fQo5DzkiIFkTOvXWGmEIMLmaZItKj8UO98FaMc8ySQrlMHbQ4Sm9uYXRoYW4g
R0VSQkFVRCAoc29uYXR5cGUpIDxqb25hdGhhbi5nZXJiYXVkQGFiZXd5LmNvbT6I
XwQTEQIAHwUCVRHb/AIbAwYLCQgHAwIEFQIIAwMWAgECHgECF4AACgkQWMavNu1w
2s90BwCdF2jNrL5HoN7BZrTeW6ksn9kWpNQAoMKAMYra3YPXU+3WDGeJzEbbfoMH
uQINBFUR2/wQCADncM9ScexqoME8AN1PVRLwKCEJJnacOpCZgDm7H3m/4OgpF2YP
iTZoNs2IAcWUq/chsHTn54WXmhUAGyQQYJNrrOrsBD7nG7Cu3BuC6ldPkHuRXRsJ
+Tvilb2OMi/irky9LcLlCGB5sAnsoZvPHIXGSJLg14ddtArGdvNCjEe5CHk6DXMR
op3NTbuTjFqfUrA+/8wGzJabg6CAOtu2ILkrzP3zMy1dGG1EcwgNdGjCLX0lKWw9
eV1/cUY9oevVi0nBtvbz8D4FEYL08oEXUAdNEyowbs1Ts+tNb5XfPXvuUhoUqVCt
OnKB/6NDhtr+70318JfXJb81l7HcF8I8LbwHAAURCAC124JyC/G2TMNptX4NjrTs
9i/rs/Ox4CXnJHJZ/N0/RMPdZG2fLNB2H7iIRnyKZyqvrtdEjmaM5DyFO3GXjLZM
Ax+UlLIMec+nUUVA0L+GOodEDrCv/Q79m99WYG5dFTAW4jPSj7Oorcir+oYXF4ZY
rEc9PD532IjabCJzRXuwY5s8FsqUmjFwxmZaRw87TGYdJDpBdKexPlYHSWaxLL2C
lHETM4nI2yO/B0N3Wsb+QfsQfSSJFnlOZQTHUaxOUdAAWi0sCclsjYuqeCerGYuH
t4xV9RVRZkhDC39a2wyrYPB8BmSnxo1CziiGrnDTioUAGWdxQ0ZkeGo3xUStOmW0
iEkEGBECAAkFAlUR2/wCGwwACgkQWMavNu1w2s/ySwCgsk6wlISS3/nwv+1RRRQY
aYKtHDAAoJCeB8HJT03HVqVhCcN+vzCOMXsM
=ZN9J
-----END PGP PUBLIC KEY BLOCK-----

Ceci est le code ASCII de ma clé publique (ne vous inquiétez pas, il n'y a aucun problème à la publier ici car cette clé ne fonctionne qu'avec ma clé privée, dont moi seul ait un exemplaire). Votre code ASCII sera forcément différent mais cela vous donne une idée de ce que vous devez obtenir. Maintenant, copiez tout le code, même les parties --- BEGIN ... et --- END... . Le plus facile est de faire CTRL-A, CTRL-C.

OK, maintenant, ouvrez https://pgp.mit.edu/ dans votre navigateur web. Dans la partie Submit a key, collez votre clé et cliquez sur Submit this key to the keyserver!. Voilà, votre clé publique est désormais publiée.

5. Configurer la publication sur Maven

Pour cela, nous allons utiliser un outil assez simple créé par Chris Banes (un ingénieur Android chez Google que je vous conseille vivement de suivre d'ailleurs). Les instructions se trouvent sur la page Github de la librairie.

Concrètement, voici les étapes à suivre : 

5.1 Créer un fichier de propriétés gradle

Vous devez créer le fichier gradle.properties suivant :

NEXUS_USERNAME=VOTRE_NOM_UTILISATEUR
NEXUS_PASSWORD=VOTRE_MOT_DE_PASSE

signing.keyId=VOTRE_ID_DE_CLÉ_GPG
signing.password=VOTRE_MOT_DE_PASSE_DE_CLÉ_GPG
signing.secretKeyRingFile=secring.gpg

 

Remplacez les valeurs par vos identifiants et mots de passe. Les valeurs NEXUS correspondent à vos identifiants de la console Sonatype Nexus (étape 1.1/1.3). 

Personnellement, j'ai placé le fichier secring.gpg (que vous pouvez retrouver à l'étape 4.2 avec la commande gpg --list-secret-keys) à la racine de la librairie (et non du projet de la librairie). Vous pouvez consulter la capture d'écran ci-dessous pour plus de détails. Vous pouvez mettre ce fichier où vous voulez du moment que vous déclarez le bon chemin dans le fichier de propriétés.

Ce fichier gradle.properties doit être placé dans votre répertoire utilisateur soit USER_HOME/.gradle/gradle.properties sur Linux, C:\Users\NOM_UTILISATEUR\.gradle\gradle.properties sur Windows.

5.2 Créer un fichier de propriétés gradle à la base du projet de la librairie

Créez le fichier gradle.properties contenant : 

VERSION_NAME=0.9.2
VERSION_CODE=92
GROUP=com.github.chrisbanes.actionbarpulltorefresh

POM_DESCRIPTION=A modern implementation of the pull-to-refresh for Android
POM_URL=https://github.com/chrisbanes/ActionBar-PullToRefresh
POM_SCM_URL=https://github.com/chrisbanes/ActionBar-PullToRefresh
POM_SCM_CONNECTION=scm:git@github.com:chrisbanes/ActionBar-PullToRefresh.git
POM_SCM_DEV_CONNECTION=scm:git@github.com:chrisbanes/ActionBar-PullToRefresh.git
POM_LICENCE_NAME=The Apache Software License, Version 2.0
POM_LICENCE_URL=http://www.apache.org/licenses/LICENSE-2.0.txt
POM_LICENCE_DIST=repo
POM_DEVELOPER_ID=chrisbanes
POM_DEVELOPER_NAME=Chris Banes

Remplacez toutes les valeurs utiles par les vôtres (ici, ce sont les valeurs d'une librairie de Chris Banes).

Ce fichier doit être placé à la base du projet de la librairie (voir capture ci-contre).

5.3 Créer un fichier de propriétés Gradle (le dernier, je vous jure !) dans votre librairie

Créez le fichier gradle.properties contenant:

POM_NAME=ActionBar-PullToRefresh Library
POM_ARTIFACT_ID=library
POM_PACKAGING=aar

Ce fichier doit être placé dans le dossier de la librairie, pas le dossier du projet de la librairie (voir capture ci-contre).

5.4 Modifiez le fichier gradle

Ajoutez la ligne suivante au fichier build.gradle :

apply from: 'https://raw.github.com/chrisbanes/gradle-mvn-push/master/gradle-mvn-push.gradle'

6. Générer et publier la librairie sur Maven

À présent, il vous suffit de générer votre librairie dans Android Studio. Pour cela, ouvrez la fenêtre Terminal dans Android Studio et tapez la ligne suivante : 

gradlew clean build uploadArchives

Si tout se passe bien, vous devriez voir un écran similaire à celui de droite ci-dessus. Si vous obtenez une erreur, c'est probablement que vos données de connexion sont erronées (voir étape 5.1).

7. Dernières étapes

Une fois votre librairie générée et uploadée, vous devriez la voir apparaître dans la console Nexus (étape 1.3). Pour cela, cliquez sur Staging repositories dans le menu de droite, ensuite filtrez grâce au nom de package de votre librairie (par exemple : com.mydomain.mysuperlib ou fr.superdomain.libdelamortquitue). Cliquez sur le nom du package et vous devriez voir apparaître un arbre décrivant l'arborescence de votre librairie.

Par exemple, ma libraire a comme nom de package com.abewy.backpack. J'ai simplement filtré sur abewy et j'ai pu trouver comabewybackpack-1000 (ne vous inquiétez pas pour le -1000 à la fin, cela est automatiquement ajouté par Sonatype et n'altère en rien votre librairie).

À ce stade vous pourriez vous dire que vous pouvez utiliser votre librairie dans votre projet en ajoutant la ligne de code magique dans Gradle. Et bien non, pas encore, il y a encore une dernière étape à effectuer. 

Une fois que vous avez vérifié que tout semble OK, vous devez cliquer sur Close et ensuite Release (en haut, sous les onglets). Vous pouvez vous référer à cette page (en anglais) pour plus de détails. Une fois que vous avez cliqué sur Release, vous devrez ajouter un commentaire au ticket JIRA précédemment créé (étape 1.2) pour indiquer que vous avez bien publié votre code et indiquer aux admins de Sonatype que vous souhaitez le mettre en ligne. Si vous n'êtes pas fan de l'anglais, écrivez simplement "I just published a first release. Thank you". 

Après quelques heures, vous devriez obtenir une réponse sur votre ticket JIRA. Voici la réponse que j'ai obtenue :

Central sync is activated for com.abewy. After you successfully release, your component will be published to Central, typically within 10 minutes, though updates to search.maven.org can take up to two hours.

Après quelques minutes (pas la peine d'attendre la réponse du ticket JIRA), vous devriez pouvoir ajouter votre librairie dans le fichier de configuration Gradle de votre projet. Voici la ligne de code que j'ai utilisée dans mon projet pour ajouter ma librairie fraîchement publiée sur Maven :

compile 'com.abewy.backpack:library:1.0.2@aar'

8. Savourez votre librairie !

Voilà, vous avez désormais publié votre librairie et vous pouvez l'utiliser dans tous vos projets Android Studio.

Si vous souhaitez ajouter une nouvelle librairie, vous devrez recommencer à partir de l'étape 5.2.

Comment

Comment

Nouvelle page

J'ai pris le temps d'écrire une nouvelle page sur mon site, qui s'adresse aussi bien aux développeurs qu'aux porteurs de projets. Cette page, intitulée "Préparer son projet", est une liste de conseils et d'outils afin de préparer au mieux son projet Android, qu'il soit au stade de simple idée ou qu'il soit déjà amorcé.

J'ai préféré créer une page plutôt qu'un article de blog car je pense que cela sera plus visible et plus utile, les articles de blog ayant la fâcheuse tendance à disparaître et à se faire oublier.

Après avoir couvert les étapes initiales du projet, j'espère bientôt publier une page sur la publication de l'application sur le Play Store, ce qui représente bien souvent la dernière étape d'un projet. 

Comment

"Chuck Norris Facts" et outils utilisés

Comment

"Chuck Norris Facts" et outils utilisés

La semaine dernière, j'ai publié une sympathique petite application du nom de "Chuck Norris Facts". Elle permet de lire (et rigoler) tous les faits incroyables (et irréels) du célèbre Chuck Norris (alias Walker Texas Ranger pour ceux qui ne connaîtraient pas). Il y avait eu un buzz sur les Chuck Norris Facts il y a quelques temps et je me suis dit qu'une petite application sur ce sujet pourrait être sympa.

Rien de très extravagant dans cette application qui reste très simple avec un écran qui permet de lire des faits aléatoirement, un écran avec la liste complète des facts et enfin un dernier écran permettant de consulter ses facts favoris. Pour le moment, seuls les facts en anglais sont disponibles mais les versions françaises devraient arriver d'ici peu.

J'ai néanmoins utilisé Material Design et implémenté un petit lot d'animations qui rendent l'application plus agréable à utiliser.

Récemment, un étudiant en DUT informatique m'a demandé quels outils (animations, menu, Material Design, ...) j'avais utilisé pour créer l'application. Donc voici une petite liste :

Comment