Mac4Ever : développer d'iOS à Android
Par Didier Pulicani - Publié le
Beaucoup de choses ont été écrites au sujet d'Android, qui est en passe de dépasser Apple en terme de terminaux installés. Si le nombre d'applications est en retrait par rapport à iOS, le retard accumulé se comble chaque semaine. Malgré tout, comme nous vous l'avions signalé dans notre test d'Android sur un Samsung Galaxy S, le niveau qualitatif des applications du système de Google est encore un cran en dessous de celui de l'iPhone.
Mac4Ever développant en interne toutes ses applications (iPhone, iPad et Android), voici quelques éléments que nous souhaitons vous faire partager afin d'expliquer peut-être ce différent niveau de qualité, mais aussi destinés aux développeurs qui voudraient franchir le pas.
Permettre aux constructeurs d'utiliser n'importe quel écran, avec des densités de pixels différentes est une excellente idée... sur le papier. Dans les faits, il s'agit du problème numéro 1 lorsqu'on développe sur Android. Cela oblige les développeurs à avoir des textures de taille différente, sans jamais avoir la
Mais le problème ne se situe pas seulement sur les images, il touche aussi l'interface elle-même : sur un téléphone, la place est limitée et chaque pixel a son importance. L'optimisation des contenus sur un écran de 3 pouces sera très différentes de celles d'une tablette, qui peut atteindre les 10 à 13" de diagonale !
La solution de ce petit jeu sans fin, c'est de tester les téléphones courants (Samsung, HTC, Google), ce qui représente une grosse douzaine de modèles clefs. A moins de s'appeler Facebook ou Google, peu d'entreprises peuvent se permettre de maintenir un tel parc de téléphones et d'adapter ses interfaces spécifiquement à certains modèles du marché.
On parle souvent de différences de versions d'Android, qui s'étalent en gros, de la 1.6 à la 2.3. Dans les faits, la plupart des téléphones récents (et utilisables) sont en version 2.x.
Par ailleurs, Google fournit à ses développeur un moyen de trier ses API en fonction de la version de l'OS, ce qu'Apple ne fait pas (ou plutôt, pas assez clairement) et ce qui évite d'utiliser les derniers frameworks alors qu'ils ne sont pas présents sur les anciennes versions.
Lorsque vous avez développé sur XCode/Interface Builder et que vous découvrez le SDK d'Android, vous constatez assez vite qu'on ne joue pas dans la même cour. Le
Quand vient le moment de créer votre interface, et que Google ne propose pour cela que de façonner des XML, on se demande dans quel siècle on se trouve ! Oubliez Interface Builder, on ne rattrape pas 20 ans de développement en 6 mois. Pire, le
Très connu des développeurs, le choix de Java permet d'éviter l'apprentissage d'un nouveau langage. Par ailleurs, l'absence de gestion de la mémoire ainsi que les nombreuses fonctions haut niveau très appréciées des programmeurs, permettent de développer le coeur de l'application bien plus rapidement que sur iOS.
A l'inverse, qui dit Java, dit JVM, dit ByteCode, bref, si pour les calculs linéaires, les performances sont désormais similaires à du C, tout ce qui touche aux interfaces a bien du mal à atteindre la réactivité d'un code natif, compilé pour le CPU de la machine, comme c'est le cas sur l'iPhone. Précisons aussi qu'Android n'utilise pas le GPU pour accélérer l'affichage 2D, ce qui est une énorme erreur. Au final, même si sur les derniers CPU à 1GHz, on commence à trouver un niveau de fluidité acceptable, on est encore loin de la réactivité des iPhone.
Mais soyons clair, Java n'est pas un frein à l'innovation. Tout le challenge de Google se situera du côté des API, et surtout des widgets. Les possibilités graphiques de l'iPhone, notamment en 2D, mettent encore une grosse claque à Google. Ne parlons même pas d'absence de ligne de conduite sur les interfaces, considérer que tous les développeurs sont des ergonomes nés constituant sans doute une belle absurdité.
Les deux points forts de l'Android Market sont l'absence de censure directe et la mise à disposition immédiate de vos applications. Précisions que comme Apple, Google refuse, après coup, certaines applications, notamment les spywares, ou les programmes qui seraient peu regardantes sur l'utilisation des données personnelles.
A l'inverse, la boutique a les défauts de ses qualités : on n'a aucune garantie que le programme fonctionnera sur son téléphone (même si Android vous remboursera), et rien ne dit que ce qu'on télécharge n'est pas un gros spyware qui va vous voler vos données personnelles. L'absence de validation ouvre aussi la porte à de nombreux programmes de très basse qualité, en grande quantité, (ce qu'Apple tente de limiter). Pour le développeur, c'est toute la relation de confiance qu'il est difficile d'instaurer avec son client. L'éditeur est le seul garant de son programme, et Google ne place aucun garde fou entre les deux partis (comme l'âge minimum pour utiliser le programme, par exemple).
Lorsqu'on se lance dans le développement sous Android, et qu'on vient du monde iPhone, on comprend presque instantanément tout ce qui a pu être écrit au sujet de cet OS pour téléphone. Le SDK est le reflet parfait de ce que sont les téléphones : ouverts mais moins riches, utilisables mais moins réactifs, diversifiés mais trop fragmentés... Développer sur Android n'est pas mission impossible, mais le SDK fait encore figure de challenger face à Apple et ses outils qui ont plus de 20 ans. A ce propos, se dessine peu à peu le troisième homme de cette course à l'innovation, Redmond possédant des outils de développements également très à la pointe, sans compter le pool de développeurs très important que compte Microsoft.
Précisons que, comme toujours, il s'agit là de points de vue, toujours sujet à discussions. Ce petit article ne prétend pas faire plus que de vous faire partager notre ressenti sur notre expérience de développement avec Android :-)
Mac4Ever développant en interne toutes ses applications (iPhone, iPad et Android), voici quelques éléments que nous souhaitons vous faire partager afin d'expliquer peut-être ce différent niveau de qualité, mais aussi destinés aux développeurs qui voudraient franchir le pas.
Le problème des variétés d'écrans
Permettre aux constructeurs d'utiliser n'importe quel écran, avec des densités de pixels différentes est une excellente idée... sur le papier. Dans les faits, il s'agit du problème numéro 1 lorsqu'on développe sur Android. Cela oblige les développeurs à avoir des textures de taille différente, sans jamais avoir la
bonne: résultat, dans la plupart des cas, les images apparaissent floues, car Android passe son temps à faire de la mise à l'échelle.
Mais le problème ne se situe pas seulement sur les images, il touche aussi l'interface elle-même : sur un téléphone, la place est limitée et chaque pixel a son importance. L'optimisation des contenus sur un écran de 3 pouces sera très différentes de celles d'une tablette, qui peut atteindre les 10 à 13" de diagonale !
La solution de ce petit jeu sans fin, c'est de tester les téléphones courants (Samsung, HTC, Google), ce qui représente une grosse douzaine de modèles clefs. A moins de s'appeler Facebook ou Google, peu d'entreprises peuvent se permettre de maintenir un tel parc de téléphones et d'adapter ses interfaces spécifiquement à certains modèles du marché.
Les versions d'Android, pas un si gros problème
On parle souvent de différences de versions d'Android, qui s'étalent en gros, de la 1.6 à la 2.3. Dans les faits, la plupart des téléphones récents (et utilisables) sont en version 2.x.
Par ailleurs, Google fournit à ses développeur un moyen de trier ses API en fonction de la version de l'OS, ce qu'Apple ne fait pas (ou plutôt, pas assez clairement) et ce qui évite d'utiliser les derniers frameworks alors qu'ils ne sont pas présents sur les anciennes versions.
Les outils de développement, très en retrait
Lorsque vous avez développé sur XCode/Interface Builder et que vous découvrez le SDK d'Android, vous constatez assez vite qu'on ne joue pas dans la même cour. Le
SDKn'est en fait qu'un bête plug-in pour Eclipse, avec quelques Add-Ons. Le programme d'IBM est disponible sur toutes les plateformes, ce qui évite d'acheter obligatoirement un Mac, par exemple. Par contre, son éternelle lenteur et manque de réactivité peut agacer les habitués des IDE plus réactifs et efficaces, comme VisualStudio ou XCode.
Quand vient le moment de créer votre interface, et que Google ne propose pour cela que de façonner des XML, on se demande dans quel siècle on se trouve ! Oubliez Interface Builder, on ne rattrape pas 20 ans de développement en 6 mois. Pire, le
Simulateur, généralement utilisé pour travailler plus vite, met plus de deux minutes à se lancer ! Et une fois actif, il est tout aussi lent qu'un téléphone à 100Mhz. Un comble !
JAVA or not JAVA ?
Très connu des développeurs, le choix de Java permet d'éviter l'apprentissage d'un nouveau langage. Par ailleurs, l'absence de gestion de la mémoire ainsi que les nombreuses fonctions haut niveau très appréciées des programmeurs, permettent de développer le coeur de l'application bien plus rapidement que sur iOS.
A l'inverse, qui dit Java, dit JVM, dit ByteCode, bref, si pour les calculs linéaires, les performances sont désormais similaires à du C, tout ce qui touche aux interfaces a bien du mal à atteindre la réactivité d'un code natif, compilé pour le CPU de la machine, comme c'est le cas sur l'iPhone. Précisons aussi qu'Android n'utilise pas le GPU pour accélérer l'affichage 2D, ce qui est une énorme erreur. Au final, même si sur les derniers CPU à 1GHz, on commence à trouver un niveau de fluidité acceptable, on est encore loin de la réactivité des iPhone.
Mais soyons clair, Java n'est pas un frein à l'innovation. Tout le challenge de Google se situera du côté des API, et surtout des widgets. Les possibilités graphiques de l'iPhone, notamment en 2D, mettent encore une grosse claque à Google. Ne parlons même pas d'absence de ligne de conduite sur les interfaces, considérer que tous les développeurs sont des ergonomes nés constituant sans doute une belle absurdité.
Android Market : un peu de pour, un peu de contre
Les deux points forts de l'Android Market sont l'absence de censure directe et la mise à disposition immédiate de vos applications. Précisions que comme Apple, Google refuse, après coup, certaines applications, notamment les spywares, ou les programmes qui seraient peu regardantes sur l'utilisation des données personnelles.
A l'inverse, la boutique a les défauts de ses qualités : on n'a aucune garantie que le programme fonctionnera sur son téléphone (même si Android vous remboursera), et rien ne dit que ce qu'on télécharge n'est pas un gros spyware qui va vous voler vos données personnelles. L'absence de validation ouvre aussi la porte à de nombreux programmes de très basse qualité, en grande quantité, (ce qu'Apple tente de limiter). Pour le développeur, c'est toute la relation de confiance qu'il est difficile d'instaurer avec son client. L'éditeur est le seul garant de son programme, et Google ne place aucun garde fou entre les deux partis (comme l'âge minimum pour utiliser le programme, par exemple).
Conclusion
Lorsqu'on se lance dans le développement sous Android, et qu'on vient du monde iPhone, on comprend presque instantanément tout ce qui a pu être écrit au sujet de cet OS pour téléphone. Le SDK est le reflet parfait de ce que sont les téléphones : ouverts mais moins riches, utilisables mais moins réactifs, diversifiés mais trop fragmentés... Développer sur Android n'est pas mission impossible, mais le SDK fait encore figure de challenger face à Apple et ses outils qui ont plus de 20 ans. A ce propos, se dessine peu à peu le troisième homme de cette course à l'innovation, Redmond possédant des outils de développements également très à la pointe, sans compter le pool de développeurs très important que compte Microsoft.
Précisons que, comme toujours, il s'agit là de points de vue, toujours sujet à discussions. Ce petit article ne prétend pas faire plus que de vous faire partager notre ressenti sur notre expérience de développement avec Android :-)