Dot.Blog

C#, XAML, Xamarin, UWP/Android/iOS

Cross-Plateforme : Android – Part 2 – L’OS

[new:30/05/2013]Dans la partie 1 de cette série dédié au développement cross-plateforme avec Android je vous ai présenté l’état du marché et pourquoi il faut s’intéresser à cet OS pour l’intégrer dans une logique plus vaste de développement d’applications multi-form factors. Il est temps de présenter les bases de l’OS.

Un OS est un OS (M. Lapalisse)

Je ne vais pas vous retracer tout l’historique de Android, on s’en moque un peu, comme ce qu’est un OS et à quoi cela sert. Tous les OS se ressemblent : ils font marcher un ordinateur et exposent des APIs que les applications peuvent utiliser pour leur propre fonctionnement.

Android est basé sur Linux 2.6. Linux tout le monde connait, c’est un OS libre, ouvert, et dont les qualités sont tout à fait honorables au point qu’il est utilisé assez largement dans le monde.

Pendant longtemps Linux a été vu comme un OS complexe, en mode ligne de commande, case-sensitive, se programmant en C, bref un truc de geek pas du tout adapté aux utilisateurs finaux. Pendant tout aussi longtemps les linuxiens nous ont promis le “grand soir”, le jour où enfin les qualités de Linux seraient reconnues comme un “vrai OS” méritant les mêmes honneurs que Mac OSX ou Windows.

Pendant longtemps les utilisateurs de Windows sont restés eux imperturbables aux sirènes de Linux, raillant même cette éternelle promesse de simplicité et de succès. De même les linuxiens passaient leur temps à se moquer de Windows et de ses virus alors que Linux, lui, étaient “inviolable”.

Bref, tout le monde a bien rigolé pendant longtemps. Mais ça, c’était avant…

Ces temps là sont révolus. Linux n’est pas arrivé par la grande porte sous la forme d’une Red Hat ou d’un Ubuntu ou d’une autre de ses milles variantes pour PC, non, Linux est aujourd’hui entre les mains de la terre entière dans la majorité des unités mobiles (smartphones et tablettes) sous un pseudonyme : Android.

Quant à l’inviolabilité de Linux, le nombre grandissant d’utilisateurs et d’applications a prouvé qu’aucun OS n’était inviolable et que même Linux ou Android nécessitent d’avoir des pare-feux et des antivirus comme sous Windows.

1 partout, la balle au centre.

Une fois les mythes oubliés et les bagarres de tranchées remisées au grenier dans la malle à souvenirs, que reste-t-il ?

Un OS aussi digne que les autres, aussi imparfait que Windows ou Mac OSX, mais pas moins valeureux.

Un OS capable de s’adapter aux petites machines peu puissantes qu’ont été les premiers smartphones comme aux monstres octo-cœurs tels le Galaxy S4.

Ni mieux ni moins bien qu’un autre OS, Android est aujourd’hui la preuve que le “grand soir” linuxien n’était pas un rêve fou. Ne reste plus qu’à annoncer au grand public, qu’en fait ils sont des utilisateurs heureux de Linux…

Cet OS il faut apprendre à le connaitre pour développer des applications efficaces. C’est un OS d’unité mobile donc présentant des similarités avec iOS ou Windows Phone. Les nuances se trouvent dans le jargon et quelques APIs et plus particulièrement dans la gestion de l’affichage.

Vecteur ou bitmap ?

Le vectoriel c’est le top. une définition courte de quelques points et vous avez un joli dessin qui s’adapte à toutes les résolutions. XAML est un système unique, la création la plus belle de Microsoft, un truc que j’adore plus que tout. Mais XAML est vraiment unique au sens de “isolé”… Les systèmes vectoriels posent le problème de déplacer la complexité non pas dans le stockage (qui peut être énorme pour les bitmaps) mais dans le rendu qui réclame une grande puissance de calcul.

C’est pourquoi peu de sociétés ont fait le choix de créer une gestion d’UI vectorielle sauf Microsoft. Et lorsqu’on voit la fluidité de WPF ou même de Silverlight sur Windows Phone 7 ou de WinRT sous Windows Phone 8 on peut jauger objectivement de la grande qualité des produits Microsoft, aucun OS connu ne sait gérer du vectoriel temps réel sur de si petites machines.

Donc la logique c’est que lorsqu’on ne dispose pas d’assez de puissance de calcul, ce qui est le cas sur un smartphone (surtout les premiers modèles) on a plutôt intérêt à se baser sur du bitmap. D’autant que les premiers modèles avaient une résolution tellement faible, donc une taille d’image si petite que cela ne posait pas de problème (les mémoires flash étaient déjà de plusieurs giga).

Suivant ce raisonnement implacable, Google a choisi de mettre en place une gestion d’UI non vectorielle.

Cela ne veut pas dire qu’on ne peut pas dessiner sous Android, cela signifie juste que les templates, les styles XAML, les courbes de Béziers si faciles à créer sous Blend cela n’existe pas.

La mise en page sous Android suit ainsi une logique hybride se situant entre XAML (format XML, existence des styles, conteneurs de type stackPanel, etc) et HTML (pour avoir un bouton de forme bizarre, il faut fournir une image de fond pour chaque état ayant cette forme bizarre).

Une fois qu’on a compris cette différence on a compris l’essentiel des différences entre Windows Phone et Android et j’exagère à peine.

Langage

Bon, reste une autre différence, chez Google on a choisi d’utiliser une “sorte de java” comme langage de développement. Je dis bien une “sorte de java” car en réalité un procès intenté par Oracle, gagné en première instance par Google mais relancé en appel par Oracle dernièrement tourne autour de ce fameux “Java”. L’affaire est complexe, pleine de rebondissement et n’a pas grand intérêt pour nous ici, sauf pour la petite histoire.

Dans la même situation Microsoft avait revu sa copie et s’était “vengé” en sortant C#, Google semble être plus têtu !

Le Java de Android fonctionne grâce à une machine virtuelle : Java Dalvik . Le code s’écrit et se teste en utilisant Eclipse. Un classique des développeurs Java.

Côté langage nous disposons donc d’un standard de type Java et d’un EDI pas si mauvais, même si nous qui connaissons Visual Studio le trouvons un peu préhistorique.

Le plus amusant dans tout ça ?

C’est qu’on s’en fiche !

On s’en fiche complètement car nous nous allons utiliser C# sur Android … Grâce à Xamarin 2.0 (anciennement MonoDroid et MonoTouch) qui nous offre les bienfaits à la fois de ce langage simple et puissant mais aussi les joies du framework .NET puisque Xamarin est basé sur le projet MONO…

On peut travailler de deux façons : soit par le biais de Xamarin Studio, une copie sous Mono de Visual Studio tout à fait correcte avec designer visuel et tout ce qu’il faut pour écrire, déboguer et tester une appli, soit par le biais de Visual Studio car Xamarin installe aussi un puglin VS. Dans ce dernier cas on bénéficie de la puissance et du confort de VS. Xamarin Studio est cross-plateforme on peut donc développer sur une machine Mac ou Linux et pas seulement sur PC.

Pour ce qui nous préoccupe, à savoir le développement cross-plateforme impliquant du code Microsoft, l’option Visual Studio n’est pas juste une question de confort vous l’aurez certainement compris : En utilisant le C# Xamarin dans Visual Studio nous allons pouvoir créer des Solutions VS qui contiennent à la fois des applications Android et des applications Windows ! Et tout cela va se compiler gentiment sans souci en partageant du code...

On pourra pour simplifier encore plus le partage de code agrémenter ce “montage” de la librairie “MvvmCross” dont j’ai présenté les principales caractéristiques dans un série de trois longs billets à laquelle je renvoie le lecteur intéressé. En gros, MvvmCross est une solution MVVM un peu comme Mvvm Light ou Jounce ou Prism, mais dont le principal avantage est d’être cross-plateforme pour pouvoir partager le même code (sans recopie) entre des applications pour PC, Android et iOS.

Je ne reviendrais pas sur ces détails déjà traités ou que je traiterais plus en profondeur plus tard mais on comprend mieux maintenant où se trouve le cross-plateforme dans tout cela et la place que tient que chaque outil dans cet environnement.

Pour résumer

Android est un OS tout à fait honorable, construit sur Linux, proposant un système d’affichage bitmap plutôt que vectoriel et un langage Java.

Mais pour ce qui nous concerne, nous utiliserons Android au travers de Xamarin, c’est à dire en C# et avec le support de .NET ce qui va nous faire gagner beaucoup de temps en formation… Le tout en se reposant sur la puissance de Visual Studio et de ses éventuels plugins comme ReSharper.

Grâce à MvvmCross nous allons pouvoir fédérer le code le plus important, celui des ViewModels, dans des librairies de code portables Visual Studio. Seules les interfaces (UI) seront spécifiques aux cibles (Android, WPF, WinRT, etc). MvvmCross nous apportera une aide supplémentaire : le support du binding dans les UI Android avec une syntaxe proche de celle de XAML (mais formalisée en JSon).

Les versions d’Android

Android évolue sans cesse. Certaines nouveautés n’étant pas forcément compatibles avec les anciens matériels et les gens conservant malgré tout leur téléphone ou leur tablette un petit moment, il y a foisonnement de versions en activité sur le marché. Au-delà, Android étant un OS libre et ouvert, chaque fabricant de mobile peut lui ajouter sa propre “couche” maison pour offrit telle ou telle fonction spécifique permettant de se démarquer de la concurrence.

C’est d’ailleurs ce qui a fait en partie le succès de Android. Windows Phone ou iOS sont rigides, identiques partout. Chez Apple, vu qu’il n’existe qu’un modèle, cela se ne voit pas trop. Pour Microsoft je pense que ce détail n’a pas aidé à l’adoption massive de Windows Phone. Tous les téléphones sous Windows Phone avaient tendance à se ressembler, tous offraient les mêmes possibilités. Personne n’aime acheter un objet qui dès le départ se noie dans la masse de l’uniformisation. Chacun se sent différent et veut l’afficher à la face du monde. Pas seulement les utilisateurs, les constructeurs aussi veulent se différencier des concurrents et même les distributeurs comme Orange veulent leur petite “couche” à eux qui fait la différence avec Free ou SFR. Si Android a connu le succès c’est aussi grâce à sa souplesse face à la rigidité de iOS et l’inflexibilité de Windows Phone qui ont déplu aux constructeurs et aux distributeurs.

C’est pourquoi je me garderai bien comme certains de fustiger Android et ses différentes versions en circulation. On entend souvent cette critique, mais elle est au contraire l’une des clés du succès… D’autant que cela est un faux débat : une application fonctionnera sur tous les téléphones Android pour peu qu’elle vise une version suffisamment basse et largement répandue, ce qui est le cas en pratique des 800.000 applications du Play Store.

Aujourd’hui il est naturel d’utiliser Android 2.2 ou 2.3 comme base pour développer bien que nous en soyons déjà à la version 4.x. Cela ne gène pas vraiment les applications.

Les améliorations des constructeurs eux-mêmes ne posent aucun problème. Par exemple pendant que Microsoft essayait (et tente toujours) de transformer les PC avec écran de plus en plus large en grosses tablettes full-screen, Samsung ou LG sur leurs smartphones offrent désormais le multi-fenêtrage pour avoir deux applications fonctionnelle en même temps… Ironie du sort, quasi paradoxe qui confirme certains choix hasardeux de Microsoft à contre courant des besoins des utilisateurs et qui explique certainement l’adoption plus que lente de WinRT et Windows 8 même sur les PC de bureau… Ces modifications “constructeur” n’ont pas d’impact sur les applications qu’on peut écrire pour Android. Si on ne prend pas en compte la couche Samsung ou LG pour le multi-fenêtrage l’application tournera full-screen comme la grande majorité des autres, c’est tout. Si on vise une clientèle spéciale uniquement équipée de certains modèles comme le Galaxy S3, on prendra en charge la fonction et on acceptera de limiter l’audience de l’application, c’est un choix assumé sans impact pour les applications “standard”.

Ici encore, pour résumer, disons qu’il existe effectivement de nombreuses versions d’Android en circulation, voir même par dessus des couches constructeurs (ce qui multiplie les combinaisons) mais que cela est un élément de la réussite de Android et que le développeur est en réalité fort peu gêné par tout cela sauf les hyper geeks qui veulent absolument utiliser les derniers gadgets (ce qui ne fait pas forcément une bonne application pour autant).

Pour le lecteur intéressé je conseille la lecture de l’historique des versions Android sur Wikipédia.

Android-Versions

Et pour la petite histoire sachez que les versions portent toutes des noms de sucrerie en suivant l’ordre alphabétique (CupCake, Donut, Eclair, Froyo, GinderBread, etc).

Il faut aussi savoir que les versions d’Android, en dehors de leur nom gourmand sont assorties d’un numéro de version de l’API qui est différent… Cela trouble un peu au départ.

Ainsi la version Gingerbread (pain d’épice) est la version 2.3, mais son API est de niveau 9. On retrouve d’ailleurs une 2.3.3 (jusqu’à la 2.3.7) toujours sous l’appellation Gingerbread 2.3 mais en API de niveau 10…

Lorsqu’on développe une application on doit choisir le niveau d’API (ce qui semble logique) ce qui n’a donc rien à voir avec la “version” d’Android.

En choisissant un niveau 10 par exemple, choix assez standard à l’heure actuelle, cela signifie qu’on visera au minimum Gingerbread 2.3.3 et que l’application tournera sur toute machine équipée de cette version ou d’une suivante (2.3.5 par exemple ou 4.0).

Conclusion

Cette partie 2 est courte et finit de brosser le décor. Nul besoin de décortiquer l’OS, ces APIs ou de rester des heures sur Java ou Eclipse que nous n’utiliserons pas.

En revanche comprendre la nature de Android, sa provenance (Linux), ses principales différences avec notamment Windows Phone, la façon dont son nommées les versions, tout cela est pratique et sera utile à un moment ou un autre. Développer plus chaque point n’aurait guère d’intérêt, le Web ainsi que les librairies sont remplies de documentations et de livres pour les lecteurs qui souhaiteraient entrer dans les détails. Dans le cadre de la démarche très orientée pratique que je vous propose, tout cela est accessoire (intéressant mais pas indispensable à creuser). Mieux vaut faire court pour entrer le plus vite possible dans le vif du sujet.

Ce moment va vite arriver en réalité puisque la partie 3 va aborder le cycle de vie d’une application Android…

Comme d’habitude…

Stay Tuned !

blog comments powered by Disqus