Android : La publication d'une application

Vérifier le code

TESTEZ LINKEDIN LEARNING GRATUITEMENT ET SANS ENGAGEMENT

Tester maintenant Afficher tous les abonnements
Avant de publier votre application, vérifiez le code avec l'outil Lint. Vous apprendrez également à gérer le numéro de version.
08:16

Transcription

Dans cette vidéo, on va faire un tour des petites choses à vérifier avant de publier son application sur le Play Store. Tout d'abord, vérifier que notre version d'Android est à jour. Je passe donc dans l’Android de SDK et recherche. Je suis bien à jour. Deuxième chose, on va voir comment fonctionne le « versionCode » et le « versionName », versionName, c'est facile, c'est un string. Vous mettez ce que vous voulez. Le versionCode, il faut simplement qu'à chaque nouvelle publication de votre application, le versionCode soit supérieur, à celui de la dernière publication. Donc, ici on a un, la prochaine on peut mettre deux, on peut mettre 100 et ainsi de suite. Maintenant, si on veut s'organiser, plutôt de commencer à un, deux, trois et ainsi de suite, je vous conseille de commencer à 10000. Pourquoi 10000 ? Tout simplement pour donner la version 1.0.0. J'ai publié mon application sur le store. Je travaille donc sur une nouvelle version. Au fur et à mesure de mes tests, j'incrémente. Au bout d'un moment, je publie ma version. Je passe donc en version 1.1. Donc, 1.1.0. Je continue. Je fais donc des tests pour préparer la 1.2. Et là, alors que la 1.2 n'est pas encore publiée, j'ai une erreur sur la 1.1 qui elle est en production. Je veux la modifier. Donc, j'ai besoin de revenir sur la 1.1. Et comme je viens de le montrer, je peux incrémenter ma 1.1, tout en ayant sur une autre version de mon gestionnaire de version, une version 1.2. Et au moment où je publierai, ma 1.2.quelque chose sera supérieur à n'importe laquelle de mes 1.1. Donc au final, le premier représente les versions majeures, le deuxième représente chaque nouvelle publication sur le Play Store. Si on fait une publication majeure, on incrémente le premier. Et les deux derniers représentent les publications intermédiaires, donc, celles de développement. Voilà une façon de travailler avec le versionCode. Il arrive qu'on rencontre ce genre de versionName, « -dev », « -prod » et ainsi de suite. Ça nous permet juste de pouvoir afficher le versionName dans notre application, celui-ci est accessible assez facilement. Autre point à vérifier. La version « minSdkVersion ». Ici, j'indique que je suis rétrocompatible jusqu'à la version 16 d'Android. Il faut vérifier que c'est ce que l'on souhaite. Le « targetSdkVersion », représente jusqu'à quelle version vous avez testé votre application. C'est-à-dire qu'ici, si je mets 22, j'omets toutes les versions qui sont après, c'est-à-dire Marshmallow et Nougat. Comme je passe en targetSdkVersion 22, je considère que je n'ai pas testé toutes les fonctionnalités ajoutées par Nougat et Marshmallow, par exemple les permissions à un volet. Avec cette version, je ne gère pas les permissions à la volée. Donc, je n'aurai pas le pop-up qui me demande de gérer la permission à la volée. Mais, contrepartie, je ne pourrais pas utiliser les nouveautés de Marshmallow. Continuons, avec l'outil d'analyse de code. Je vais prendre mon projet, et je vais faire un clic droit, « Analyse Inspect code » et donc, je vais inspecter mon projet. Cet outil s'appelle « Lint ». Ce n'est pas marqué ici, mais c'est le nom de l'outil. C'est un outil proposé par le SDK. Qu'est-ce qu'il va faire ? Il va simplement parcourir tout votre code, et vous remontez des warnings ou des erreurs. Elles ne doivent pas forcément être toutes corrigées. C'est juste des signalements. On va faire un tour des différentes erreurs qui sont remontées sur mon projet. Ici, par exemple, il indique qu'utiliser un plus sur les compiles Gradle, ce n'est pas recommandé, car, si la librairie évolue, votre projet évoluera avec, sans que vous ayez pu tester les nouvelles versions. Ici, je sais ce que je fais. Je peux donc pour ces librairies-là, les mettre sans trop de problèmes. Ici, il indique que pour le « LayoutInflater », il faut éviter de mettre « null ». Que c'est plus recommandé de mettre le parent. Sauf qu'à ce moment-là, on n'a pas le parent. Donc, on ne peut pas le faire. L'internationalisation, va nous faire ressortir tous les textes écris en dur. Par exemple, ici, nom de la station est écrit en dur. Il nous l'indique, qu'il vaut mieux utiliser un « string ressource ». Même chose pour tous les autres. Il peut aussi de nous faire ressortir, que pour une certaine valeur, je n'ai pas fait les traductions. Ici, il m'indique qu'il vaut mieux éviter de concaténer du texte. Qu'il vaut mieux passer par un string, avec des paramètres. Mais ici, je m'en sers pour convertir un entier en string. Ici, il m'indique que j'ai un string qui n'est pas utilisé. Ici, il me propose de créer un fichier de backup. Ici, nouveauté apparu avec Marshmallow. Donc, il va même plus loin que vous signaler un problème. Il indique même un lien où trouver plus d'infos, et comment corriger le problème. Ici, il nous indique qu'il ne peut indexer notre application, mais c'est pour Firebase. On n’utilise pas Firebase donc ça ne pose pas de problèmes. Mais, c'est la même chose, c'est le genre d'erreurs où on va taper le message d'erreur dans Google, et avoir plus d'information sur les bonnes pratiques des choses à faire. Celle-ci évolue régulièrement. Au niveau des icônes. Ici, il m'indique que mon icône ne respecte pas les guidelines. Il y a des pixels aux mauvais endroits. Ça, c'est le fait d'avoir modifié mon icône de dev. Du coup, j'ai perdu la transparence, et donc je ne respecte plus certaines guidelines. Ici, j'ai un problème au niveau des typages. Il m'indique, que c'est mieux d'utiliser AsyncTask typée. Donc ici, j'ai utilisé une AsyncTask que je n'ai pas typée, et il me reporte cette erreur en m'indiquant que c'est mieux de typer les AsyncTask. Ici, il faut plus voir ça comme un avertissement qu'une erreur. Même chose pour les autres. Ici, il m'indique que cette classe n'est utilisée que dans le package. Je pourrais donc limiter sa portée au package et je pourrais donc retirer le public. Même chose ici. Ici, il m'indique que certaines variables ne sont jamais remodifiées. Je pourrais donc les déclarer en final. Ce chapitre, c'est toutes les méthodes qui ne sont pas utilisées. Donc, ici, on peut voir que les getters et les setters ne sont pas forcément utilisés. Il y a les classes les méthodes et les variables. Ici, il indique tous les templates qui ont été générés, mais qui sont vides. Si on veut suivre les guidelines, il faut ici rajouter un commentaire sur, à quoi sert cette classe. Ici, il nous indique qu'il y a une petite erreur. Que cette variable-là n'est pas utilisée. C'est que j'ai peut-être oublié de l'utiliser. Donc, soit je la supprime, soit je l'utilise. « Spelling », ça va être toutes les erreurs liées aux noms de vos variables. Certaines syntaxes qui veulent qu'on ait des noms de variable qui correspondent à des mots anglais, et il va faire une correction orthographique de vos variables et de vos commentaires. Sauf qu'ici, tout mon code est en français. J'ai énormément de warnings sur mes noms de variables, car les mots français ne sont pas toujours reconnus en anglais. Ici, il m'indique, qu'il n'y a pas de namespace, car normalement dans un fichier au format XML, la première ligne indique le « Namespace » du fichier. Même chose ici. Lint, est capable de vous faire ressortir des morceaux de code ou des erreurs qui ne sont pas rétrocompatibles aussi loin, que ce que vous avez indiqué sur votre fichier des gradles. Par exemple, si vous utilisez « background tint » dans un fichier XML de boutons, background tint étant apparu à partir de Lollipop, il le fera ressortir en indiquant, attention, vous avez utilisé une ligne de code qui ne sera compatible qu'à partir de Lollipop. C'est un outil qu'il est intéressant de lancer, avant la publication de son application.

Android : La publication d'une application

Abordez la publication d’une application Android sur le Google Play Store. Nettoyez votre code avant la diffusion, gérez les éventuels crashs, récupérez un exécutable signé, etc.

1h04 (13 vidéos)
Aucun commentaire n´est disponible actuellement
Logiciel :
Spécial abonnés
Date de parution :6 juin 2017

Votre formation est disponible en ligne avec option de téléchargement. Bonne nouvelle : vous ne devez pas choisir entre les deux. Dès que vous achetez une formation, vous disposez des deux options de consultation !

Le téléchargement vous permet de consulter la formation hors ligne et offre une interface plus conviviale. Si vous travaillez sur différents ordinateurs ou que vous ne voulez pas regarder la formation en une seule fois, connectez-vous sur cette page pour consulter en ligne les vidéos de la formation. Nous vous souhaitons un excellent apprentissage avec cette formation vidéo.

N'hésitez pas à nous contacter si vous avez des questions !