1. Introduction▲
L'objectif de cet article est de vous aider à préparer la livraison de vos projets Android sur GooglePlay. Je pars du principe que vous savez déjà signer et générer l'apk de votre application et que vous êtes inscrits sur GooglePlay.
Cet article a surtout pour objectif de vous permettre :
- de préparer votre livraison et d'organiser vos espaces de livraison ;
- de cibler les appareils sur lesquels votre application peut être installée.
Mais avant tout, effectuez deux actions necessaires sur votre application.
Premièrement, rendez votre application non debuggable, en rajoutant la balise debuggable="false", comme indiqué dans l'exemple suivant.
<application
android:name= ".SmsListenerApplication"
android:icon= "@drawable/ic_launcher"
android:label= "@string/app_name"
android:theme= "@style/AppTheme"
android:debuggable= "false" >Ensuite, modifiez vos degrès de log pour les passer en mode debug (Log.e, Log.w, Log.i deviennent Log.d) ou bien supprimez les de votre code. Vous gagnerez en perfomrance.
2. Prérequis▲
Vous avez déjà signé votre application avec votre clef de production. Si ce n'est pas le cas, cet article est pour vous : Déployer son application Android et obtenir sa clef MapView.
Ensuite vous avez créé un compte développeur sur GooglePlay en ayant fait bien attention de ne pas utiliser votre adresse mail personnelle ! Si ce n'est pas encore fait c'est ici que ça se passe : https://play.google.com/apps/publish/Home .
Vous êtes donc maintenant à l'étape de la livraison de votre projet.
Attention à l'unicité des noms de vos packages roots. Toutes les applications doivent avoir un nom de package unique (et quand je dis toutes, c'est toutes celles qui existent dans le monde, pas que les vôtres).
3. Packager son application▲
Il est d'une importance primordiale de bien cibler les appareils qui pourront installer votre application. Pour cela il faut utiliser le fichier AndroidManifest.xml de votre application et ajouter les restrictions qui permettent de restreindre les appareils pouvant l'installer.
En effet, GooglePlay s'appuie sur votre fichier Manifest pour connaître les appareils éligibles à l'installation de votre application. C'est la notion de filtre. Quand un appareil se connecte sur GooglePlay, celui-ci est analysé par les serveurs Google et, en fonction de ses caractéristiques, GooglePlay filtrera les applications que l'appareil peut télécharger.
Typiquement, pour qu'une application ne soit jamais proposée aux appareils dont l'écran est de type XLarge, il suffit de rajouter les informations suivantes dans votre Manifest :
<supports-screens android:xlargeScreens"false"/>
De même, si vous voulez exclure les appareils ne possédant pas de
flash, il vous suffit de rajouter le bloc suivant à votre
manifest :
<uses-feature
android:name="android.hardware.camera.flash"
android:required="true" />
Enfin, si vous ne souhaitez pas voir votre application proposée au
GoogleTv (car elle a toute les chances d'être parfaitement horrible,
vous ne l'avez pas désigné pour la GoogleTv), il suffit de rajouter
la ligne :
<uses-feature
android:name="android.hardware.touchscreen"
android:required="true" />Eh oui, il n'y a pas de TouchScreen sur les GoogleTv.
Toutefois, quand vous mettez en place ces filtres, soyez vigilant. Votre objectif est d'exclure les appareils sur lesquels vous êtes sûrs que votre application ne fonctionne pas ou n'est pas adaptée. Ce n'est certainement pas 90 % du parc qu'il faut exclure, soyez donc vigilant à ne mettre que le strict minimum.
Enfin, sachez que votre application est analysée par le store, elle est décompilée et le store détecte certaines lignes de code et en déduit certains filtres de manière automatique. Ainsi ajouter un listener de toucher d'écran (la méthode setOnTouchListener) dans votre code sera détecté et générera le filtre « nécessite que l'appareil soit équipé d'un TouchScreen ». Pour pallier ce genre de chose vous pouvez expliquer dans votre Manifest que cette fonctionnalité n'est pas nécessaire au bon fonctionnement de votre application, en mettant :
<uses-configuration
android:reqTouchScreen= "notouch"/>
ou
<uses-feature
android:name="android.hardware.touchscreen"
android:required="true" />Tout un programme.
3-1. Spécification du fichier AndroidManifest.xml pour filtrer les appareils sur lesquels s'installer▲
3-1-1. Les écrans compatibles▲
Il y a deux balises permettant de spécifier les écrans supportés, la première est présentée dans ce paragraphe, la seconde le sera dans le paragraphe suivant. Ainsi la balise support-screen définit si votre application doit bénéficier du mode de compatibilité d'écran qui permet à Google de gérer l'affichage de votre application.
En effet, si votre application ne fonctionne pas quand elle est redimensionnée pour remplir différentes tailles d'écran, vous pouvez utiliser cette balise pour spécifier qu'elle doit être distribuée sur des « petits écrans » ou si votre GUI doit être zoomé pour remplir l'espace. Je vous suggère d'utiliser l'attribut compatible-screen décrit dans le paragraphe suivant pour filtrer les tailles d'écrans plutôt que cette balise-ci qui a plus pour vocation de mettre en place le mode compatibilité d'écran.
La balise support-screen :
<supports-screens android:resizeable =["true"| "false"]
android:smallScreens=["true" | "false"]
android:normalScreens=["true" | "false"]
android:largeScreens=["true" | "false"]
android:xlargeScreens=["true" | "false"]
android:anyDensity=["true" | "false"]
android:requiresSmallestWidthDp="integer"
android:compatibleWidth="integer"
android:largestWidth ="integer"/>où les attributs sont :
- resizeable est Deprecated => il ne faut plus l'utiliser ;
- smallScreens, normalScreens, largeScreens et xLargeScreens permettent de définir si votre application est compatible avec ces tailles d'écrans. Si l'attribut est à false, l'application sera filtrée sur GooglePlay ;
- anyDensity => almost deprecated, il ne faut pas l'utiliser ;
- les attributs requiresSmallestWidthDp, compatibleWidthLimitDp et largestWidthLimitDp sont disponibles depuis la version 13.
Ces trois derniers attributs méritent une attention particulière.
Ainsi, requiresSmallestWidthDp permet de spécifier la plus petite taille de l'écran qui doit être disponible pour que votre application puisse s'afficher correctement (en dp). Cette taille est celle réellement disponible pour l'application, c'est-à-dire la taille réelle de l'écran moins l'ensemble des éléments qui pourraient prendre de l'espace (sytème.). Cette taille est indépendante de l'orientation, elle ne change pas quand l'orientation change, car elle est la plus petite taille (largeur / longueur) de l'écran de l'appareil. Cet attribut enclenche un filtrage sur GooglePlay.
Les deux autres attributs sont liés à l'enclenchement du mode de compatibilité d'écran.
La compatibleWidthLimitDp permet de spécifier la limite à partir de laquelle le mode de compatibilité d'écran (mise en place du zoom automatique de l'application) est proposé à l'utilisateur sans pour autant qu'il soit activé (un icône apparaît dans l'ActionBar, permettant d'activer ou de désactiver ce mode). Cette variable spécifie la plus grande petite taille d'écran compatible avec votre application, au-delà de cette taille, votre application proposera d'activer le mode de compatibilité (« les pixels prendront plus de place », la densité de l'écran sera logiciellement réduite de manière à ce que votre application remplisse l'écran). La valeur de cette variable doit être inférieure à 320 dp (density independant pixel) sinon rien ne se passe.
La largestWidthLimitDp permet de forcer l'enclenchement du mode de compatibilité au-delà de la valeur spécifiée. L'utilisateur n'a pas le choix, il ne pourra le désactiver. Doit être inférieur à 320 dp sinon rien ne se passe.
3-1-2. Les tailles et densités d'écrans compatibles▲
Cette balise permet de spécifier les tailles d'écrans et les densités d'écrans compatibles avec votre application. Vous pouvez ainsi spécifier pour chacune des 16 configurations possibles, celles qui sont supportées par votre application. En fait, dès qu'un couple est compatible avec votre application, il faut qu'il soit déclaré.
<compatible-screens>
<screen android:screenSize=["small" | "normal" | "large" | "xlarge"]
android:screenDensity=["ldpi" | "mdpi" | "hdpi" | "xhdpi"] />
...
</compatible-screens>Les attributs de cette balise étant pour une fois limpides, nous ne nous éterniserons pas dessus, mais donnons un exemple exhaustif qui nous permettra par simple copier-coller de définir l'ensemble des écrans compatibles avec votre application :
<compatible-screens>
<!-- all small size screens -->
<screen android:screenSize="small" android:screenDensity="ldpi" />
<screen android:screenSize="small" android:screenDensity="mdpi" />
<screen android:screenSize="small" android:screenDensity="hdpi" />
<screen android:screenSize="small" android:screenDensity="xhdpi" />
<!-- all normal size screens -->
<screen android:screenSize="normal" android:screenDensity="ldpi" />
<screen android:screenSize="normal" android:screenDensity="mdpi" />
<screen android:screenSize="normal" android:screenDensity="hdpi" />
<screen android:screenSize="normal" android:screenDensity="xhdpi" />
<!-- all large size screens -->
<screen android:screenSize="large" android:screenDensity="ldpi" />
<screen android:screenSize="large" android:screenDensity="mdpi" />
<screen android:screenSize="large" android:screenDensity="hdpi" />
<screen android:screenSize="large" android:screenDensity="xhdpi" />
<!-- all extra-large size screens -->
<screen android:screenSize="xlarge" android:screenDensity="ldpi" />
<screen android:screenSize="xlarge" android:screenDensity="mdpi" />
<screen android:screenSize="xlarge" android:screenDensity="hdpi" />
<screen android:screenSize="xlarge" android:screenDensity="xhdpi" />
</compatible-screens>
Ainsi, il vous suffit de copier-coller ce bloc dans votre Manifest
et dès que l'une de ces configurations n'est pas compatible avec
votre application, supprimez-la.
3-1-3. Texture OpenGL▲
Vous pouvez avoir besoin de définir le mode de compression de vos textures OpenGL.
C'est ici : <supports-gl-texture>
3-1-4. Configurations d'interaction avec l'appareil compatible ▲
Cette balise indique quels sont les caractéristiques matérielles ou logicielles nécessaires au bon fonctionnement de votre application. Ces caractéristiques sont les suivantes :
<uses-configuration android:reqFiveWayNav=["true" | "false"]
android:reqHardKeyboard=["true" | "false"]
android:reqKeyboardType=["undefined" | "nokeys" | "qwerty" | "twelvekey"]
android:reqNavigation=["undefined" | "nonav" | "dpad" | "trackball" | "wheel"]
android:reqTouchScreen=["undefined" | "notouch" | "stylus" | "finger"] />Comme pour les balises des écrans compatibles (compatilble-screen), vous devez déclarer chacune des configurations qui sont compatibles avec votre application.
L'exemple suivant explique ce concept :
<uses-configuration
android:reqFiveWayNav="true"
android:reqKeyboardType="qwerty"
android:reqTouchScreen="finger" />
<uses-configuration
android:reqFiveWayNav="true"
android:reqKeyboardType="twelvekey"
android:reqTouchScreen="finger" />Les attributs commencent tous par « req » pour required.
L'attribut reqFiveWayNave spécifie que votre application a besoin du mode de navigation « five ways », qui n'est autre que la capacité à aller à droite, à gauche, en haut, en bas et à lancer une action sur l'élément courant (celui qui est sélectionné).
L'attribut reqHardKeyboard spécifie que votre application a besoin d'un clavier physique.
L'attribut reqKeyboardType spécifie le type de clavier requit par votre application. La valeur undefined permet de spécifier que l'application ne se soucie pas de la présence d'un clavier. La valeur noKeys spécifie qu'un clavier n'est pas nécessaire à votre application. La valeur qwerty implique que l'application a besoin d'un clavier standard (avec toutes les touches d'un clavier QWERTY ou AZERTY, c'est pareil). La valeur twelvekey, elle, spécifie que votre application a besoin d'un clavier de type téléphone (les anciens, ceux avec les touches 0 à 9,* et #).
L'attribut reqNavigation permet de spécifier le type de navigation requit par votre application. La valeur undefined permet de spécifier que votre application ne se soucie pas du type de navigation, la valeur nonav qu'elle n'en a pas besoin. La valeur dpad spécifie le besoin d'un dpad (le directional pad est utilisé par les GoogleTv, par exemple). La valeur trackball spécifie le besoin d'un trackball et wheel spécifie le besoin de la molette de la souris (sur une tablette ou un téléphone ?o?, ils sont fous chez Google).
Enfin le dernier attribut permet de spécifier le type de « touchscreen » requit par votre application, en d'autres termes la façon dont l'écran doit interagir avec l'utilisateur. Elle peut s'en fiche (undefined), ne pas en avoir besoin (notouch), être compatible avec le stylet (stylus) ou avec les doigts (finger).
On aura ainsi souvent tendance à soit ne pas mettre ce type de balise soit a cibler les téléphones et les tablettes.
Ainsi, si vous souhaitez spécifier que vous êtes compatibles uniquement avec les téléphones ou les tablettes, vous aurez tendance à mettre :
<uses-configuration
android:reqFiveWayNav="false"
android:reqHardKeyboard="false"
android:reqKeyboardType="qwerty"
android:reqNavigation="undefined"
android:reqTouchScreen= "stylus"/>
<uses-configuration
android:reqFiveWayNav="false"
android:reqHardKeyboard="false"
android:reqKeyboardType="qwerty"
android:reqNavigation="undefined"
android:reqTouchScreen= "finger"/>3-1-5. Les pièces matérielles (UseFeature) compatibles ou nécessaires▲
Cette balise est extrêmement utile pour spécifier les caractéristiques matérielles/logicielles nécessaires au bon fonctionnement de votre application. Vous avez besoin du flash, du GPS, du Wifi ou du Bluetooth, vous devez le déclarer avec cette balise. Cette balise possède en outre le bon goût de permettre de déclarer l'utilisation d'une pièce matérielle tout en spécifiant que si cet élément ne se trouve pas sur l'appareil, l'application fonctionnera quand même (vous avez mis en place un workaround pour résoudre l'absence du dit matériel).
<uses-feature android:name="string"
android:required=["true" | "false"]
android:glEsVersion="integer" />
Chaque caractéristique se déclare indépendamment :
<uses-feature android:name="android.hardware.bluetooth" />
<uses-feature android:name="android.hardware.camera" />Normalement pour chaque « feature » déclarée, vous avez fait une demande de permission pour son utilisation :
<uses-permission android:name="android.permission.CAMERA" >
</uses-permission>
<uses-permission android:name="android.permission.BLUETOOTH" >
</uses-permission>Enfin, pour chaque permission demandée pour l'utilisation d'une caractéristique qui n'est pas déclarée dans le bloc uses-features, GooglePlay supposera que cette caractéristique est nécessaire.
L'attribut name permet de déclarer le nom de la caractéristique et l'attribut required permet de spécifier si elle est nécessaire. En d'autres termes si votre application fonctionne (ou pas) lorsque l'appareil ne possède pas cette caractéristique. Par défaut required égale true. L'attribut glEsVersion s'utilise quand vous déclarez la caractéristique OpenGL ES et vous permet de spécifier la version de ce dernier.
Vous trouverez la liste des caractéristiques matérielles ici :
et celles des caractéristiques logicielles ici :
3-1-6. Versions du système compatibles et cibles▲
Enfin la dernière balise, de loin la plus importante de manière générale, est celle qui spécifie la version minimale, maximale et cible du système de l'appareil. En ces temps de fragmentation, cette balise peut vous permettre d'assurer le bon déploiement de votre application sur les versions de systèmes compatibles.
<uses-sdk android:minSdkVersion="integer"
android:targetSdkVersion="integer"
android:maxSdkVersion="integer" /> L'attribut minSdkVersion (respectivement maxSdkVersion) vous permet de spécifier quelle est la version du système minimale (respectivement maximale) pour le bon fonctionnement de votre application.
Il y a une rumeur sur l'attribut maxSdkVersion : en effet, lors des updates du système (l'appareil se fait upgrader sa version), toutes les applications sont revalidées. Si la nouvelle version du système dépasse votre maxSdkVersion, votre application sera purement et simplement désinstallée de l'appareil. Cette rumeur est vraie pour les versions antérieures à Donut (1.6). (moins de 0.3 % des appareils).
L'attribut targetSdk permet de spécifier pour quelle version du système votre application fonctionne sans avoir besoin de mode de compatibilité. Par exemple, votre minSdk est Froyo (8) mais vous avez designé votre application et l'avez testée pour ICS (14) et elle fonctionne nickel. Dans ce cas votre targetSdk est 14.
A contrario, si vous avez déclaré votre targetSdk pour GingerBread (10) quand elle tournera sur un ICS (14 ou 15), le mode de retrocompatibilité sera enclenché et votre application tournera dans cet environnement. Cela lui interdira l'ensemble des nouveautés de cette version (thème, mode de compatibilité d'écrans).
Enfin, si cet attribut n'est pas spécifié, il est considéré comme égal à votre minSdkVersion.
3-2. Livrer plusieurs apk pour une même application.▲
Il faut savoir que vous pouvez livrer plusieurs apk pour une même application, chacune ayant des cibles (des restrictions définies dans son Manifest) différentes. Cela est permis pour les balises suivantes :
-
format de compression de vos textures OpenGL
- en utilisant l'élément <supports-gl-texture> ;
-
taille de l'écran (et, optionnellement densité de l'écran)
- en utilisant l'élément <supports-screens> ou <compatible-screens> ;
-
version du SDK
- en utilisant l'élément <uses-sdk> .
Et de mon point de vue, cela peut être la meilleure stratégie pour atteindre la satisfaction cliente tout en conservant un code propre avec plusieurs projets. Mais ce sera dans un autre article sur « Comment combattre la fragmentation ».
4. Soigner sa livraison▲
4-1. Configuration de votre espace de livraison▲
Pour cela je préconise dans votre projet Eclipse de faire un dossier delivery et dans ce dossier faire un sous-dossier par version livrée sur GooglePlay.
Pour chaque dossier de version (par exemple delivery\v1.0), il faut mettre :
- les captures d'écran ;
- l'icône en haute résolution ;
- les éléments graphiques : image promotionnelle, « featured » image et la vidéo ;
- le fichier texte décrivant votre application dans les différentes langues information-en, information-fr ;
- le fichier apk correspondant à votre livraison ;
- le fichier d'extension principal et le fichier d'extension correctif (si vous en avez).
Nous revenons sur ces différents éléments dans les paragraphes qui suivent.
4-2. Préparation des éléments graphiques à fournir▲
Tout d'abord il vous faut votre application .apk. Attention le logo de votre application doit être en Png .
Les ressources graphiques suivantes sont nécessaires :
- deux copies d'écrans minimum et huit maximum, au format PNG ou JPEG, sans canal alpha, 24 bits, pas de bordure. Utilisez la vue DDMS et sa capture d'écran pour cela.
- une icône haute résolution de votre application : 512*512 en 32 bits PNG (avec alpha) d'une taille maximum de 1024 kB
Les ressources suivantes ne sont pas nécessaires mais fortement préconisées en termes de marketing (bref c'est quasiment obligatoire) :
- une image promotionnelle de 180*120, 24 bits PNG ou JPEG sans alpha, pas de bordure.
- une « featured » image: 1024*500, 24 bits PNG ou JPEG avec une image utile de 924*400 le reste de l'image risquant d'être rogné.
- un lien vidéo Youtube vers une vidéo durant entre 30 s et 2 mn
À part la vidéo, considérez que vous devez livrer votre image promotionnelle et votre « featured » image.
4-3. Préparation des éléments textuels à fournir▲
Le plus simple est encore de créer un fichier texte par langue (Word, OpenOffice ou texte cela n'a pas d'importance) que vous nommerez information-en.txt (ou doc) et information-fr.txt au minimum pour nous autres développeurs français.
Ce fichier doit contenir les paragraphes suivants :
- titre (30 caractères max) ;
- description (4000 caractères max) ;
- modifications récentes (500 caractères max) ;
- texte promotionnel (80 caractères max) ;
- type d'application (Application ou Jeu) et catégorie (vous pouvez trouver le liste des catégories ici : Category type ).
5. Livrer votre application▲
Si vous avez tout préparé, la livraison sera rapide, si vous n'avez pas encore tout préparé, he bien finissez de préparer les fichiers à remplir.
Allez à l'adresse suivante : https://play.google.com/apps/publish/Home .Et suivez le processus, vous avez déjà tous les éléments pour livrer votre application.
6. Conclusion▲
J'espère que cet article vous a plu, vous êtes maintenant capable de livrer vos applications sur GooglePlay en ayant conscience des enjeux et des contraintes associés, félicitations.
À bientôt pour d'autres articles sur le développement Android.
7. Référence:▲
Les références générales à GooglePlay:
Android Market Featured-Image Guidelines
Les références permettant une excellente compréhension du fichier Manifest :
8. Android2EE: La Formation et l'Expertise Android à votre service▲
 |
Android2EE
|
|
|
|
9. Récupération des tutoriels▲
Cet article n'est associé à aucun tutoriel, désolé. Vous pouvez toujours le retrouver sur le site Android2ee. À l'adresse suivante : Article sur la livraison GooglePlay.
10. Articles, conférences et autres tutoriaux made in Android2EE▲
Vous pouvez trouver d'autres articles sur developpez.com rédigés par Android2EE.
Vous pouvez trouver les projets Android open sources d'Android2EE sur GitHub.
| Android2EE sur Github |
|
GDirectionsApiUtils pour vous simplifiez l'utilisation du service REST Google Api Direction (les itinéraires entre deux points). Le MythicServiceHelper est un projet simplifiant la communication entre les services et les activités. Il est mieux d'utiliser, à l'heure d'aujourd'hui, EventBus ou Otto. Vous pouvez aller le voir quand même par curiosité. Le Bluetooth avec Android expliqué. Ce projet est un chat bluetooth qui vous montre, par l'exemple, comment mettre en place une communication BlueTooth entre deux appareils Android. Le projet ForecastYahooRest a pour objectif de vous expliquer comment mettre une architecture saine pour vos projets Android pour effectuer des appels REST. Ce projet est lié à la conférence "An Android Journey" que vous pouvez retrouver sur Android2ee. Le projet SignInWithGoogleTutorialvous explique comment mettre l'authentification Google au sein de vos applications. Il est lié à la conférence Google Sign In que vous pouvez retrouver sur Android2EE. |
Vous pouvez trouver les supports des conférences d'Android2EE sur SlideShared.
| Android2EE sur SlideShare |
|
Retrouvez la liste des tutoriaux Android2EE de la formation complète. C'est pas ma meilleure conférence :) An Android Journey La conférence 2014 d'Android2EE qui vous donne toutes les astuces, les bonnes pratiques et les bons conseils à mettre en place dans vos applications pour en faire des applications exceptionnelles. ActionBarCompat Cette conférence vous explique comment mettre en place l'ActionBar dans vos applications pour toutes les versions du système en utilisant l'ActionBarCompat. GoogleSignIn L'authentification Google vous est expliquée dans cette conférence. Android ProTips Cette conférence a été donnée à la DroidCon Paris 2013 pour vous présenter les meilleurs conseils sur le développement Android donnée aux GoogleIo. Ce sont mes bonnes pratiques favorites. Architecture Android Une peu d'architecture, ça vous dit? Cette conférence est dédiée à l'architecture, quels sont les problèmes rencontrés et les bonnes pratiques à mettre en place. Android, un nouveau futur s'ouvre à nous Cette conférence, donnée à Brazzaville, présente les enjeux de la mobilité et en particulier ma vision du futur relative à Android. Combining the power of Eclipse with Android Cette conférence, donnée à l'EclipseDay 2012, présente comment utiliser la DDMS et chasser les fuites mémoires au sein de vos applications Android. A Quick OverviewCette conférence, donnée au CocoHeads Toulouse en 2012, est une introduction à la programmation Android. Android A Quick Course @DevoxxFr Cette présentation est un extraie de la conférence "Android A Quick Course", donnée à DevoxxFrance, pour apprendre le développement Android. Les vidéos (3 heures tout de même sont disponibles sur le site Android2EE ou sur Parleys) |
Les vidéos de certaines de ces conférences sont disponibles à l'adresse suivante : Les vidéos
11. Le site Android2ee, une référence pour le développement Android.▲
Le site Android2EE vous propose des tutoriels, des articles, des vidéos, des conférences, des eBooks en libre consultation pour monter en compétence sur la technologie Android.
Vous trouverez tout cela dans la partie « Open Resources ».
N'hésitez plus visitez-le ! Android2EE
12. Android2ee vous présente l'Ebook de programmation Android▲
Le nouveau système d'exploitation de Google pour les téléphones portables et les nouvelles tablettes est là. Sa réputation est solide, il envahit le monde de la téléphonie, il est ouvert et offre des outils de développement Java au monde des programmeurs. Il ouvre les portes du développement mobile à tous les développeurs objets avec un coût minime pour la montée en compétence. Une seule question se pose :
Êtes-vous prêts ?
L'objectif de ces livres est très clair : vous permettre en un temps record d'être autonome en programmation Android. Si vous êtes un programmeur Java (débutant ou confirmé), le but est que vous soyez autonome en moins de dix jours. C'est cet objectif qui est à l'origine de ce livre, permettre aux collaborateurs de mon entreprise de monter en compétence sur cette technologie avec rapidité et efficience. Vous serez alors à même de concevoir une application, de l'implémenter, de la tester, de l'internationaliser et de la livrer à votre client.
Lancez-vous dans la programmation Android et faites-vous plaisir !
Vous serez aussi capable de connaître et comprendre quelles sont les considérations à avoir lorsque l'on a à charge une application Android en tant que professionnel de l'informatique. Quelle est la stratégie de tests à utiliser ? Comment signer son application ? Comment la déployer ? Comment mettre en place la gestion du cycle de vie de l'application ? Comment implémenter l'intégration continue ?
Soyez efficient dans l'encadrement de vos projets Android d'entreprise.
L'achat d'un EBook vous donne accès à l'ensemble des tutoriaux Android2EE, plus de 50 projets Android qui vous apprendrons à mettre en place une notion spécifique (SlidingDrawer, Parsing d'un service REST, Mise en place d'un service, d'un ContentProvider...). Vous pouvez dès maintenant vous lancer dans la programmation Android, n'hésitez pas faîtes vous plaisir, il y a 75% de réduction sur les EBooks en ce moment:
| Apprendre la programmation Android avec les EBooks Android2EE |
Android, A Complete Course, From Basics To Enterprise Edition (fr). Android, A Quick Course (fr). Android, An Entreprise Edition Vision (fr). Les eBooks sont disponibles en français et en anglais, à votre convenance. |
Nota Bene: l'ouvrage "Android, A Complete Course, From Basics To Enterprise Edition" réunit, au sein d'un même document, les livres "Android, A Quick Course" et "Android, An Enterprise Edition Vision" permettant au lecteur d'avoir dans un même document la totalité des préoccupations liées à la mise en place de projets Android, de la montée en compétence en tant que développeur à la gestion du cycle de vie du projet.
13. Remerciements▲
J'adresse ici tous mes remerciements à Feanorin pour son implication, son aide et sa sympathie et à jacques_jean pour l'excellence de ses corrections orthographiques.
Je remercie le correcteur technique Feanorin pour la pertinence de ses remarques.
Je remercie spécialement Monsieur Adam Daniel, ancien DRH de développez.com, pour ses mails nocturnes, ses encouragements et son aide qui m'a été précieuse et je souhaite la bienvenue à Sara Galloy à ce poste.