Avis sur les applications Android

[ddu]

Je ne suis pas développeur, mais j'aimerais comprendre ... Suite à cet article intéressant ici dont voici un extrait:

Pourquoi une stratégie multiplate-forme est-elle difficile à mettre en place ?

C'est surtout Android qui pose problème, non pas dans le développement initial mais dans le déploiement qui s'apparente à un cauchemar. Il est impossible de raisonner en termes d'OS car les terminaux sous Android sont techniquement très différents (taille de l'écran etc...).

Les adaptations pour chaque terminal prennent donc beaucoup trop de temps. On conseille donc de se focaliser sur certains terminaux.

Mais ce surcoût douche les ambitions. Si 80% de nos clients veulent être présents seulement sur iPhone ou iPad, les 20% restants abandonnent leurs ambitions Android lorsqu'on leurs montre le devis. Développer et déployer sous Android coûte en moyenne 1,5 fois plus que sur Apple.

A part la taille de l'écran, en fait j'imagine la résolution sinon je ne vois pas le rapport, y a t'il d'autres spécificités techniques, non prises en compte directement par les APIs Android et dont il faut tenir compte lors d'un dvp d'une appli Android ?

[Sylvain G]

A part la taille de l'écran, en fait j'imagine la résolution sinon je ne vois pas le rapport, y a t'il d'autres spécificités techniques, non prises en compte directement par les APIs Android et dont il faut tenir compte lors d'un dvp d'une appli Android ?

J'ai aussi lu cet interview et la personne manque de franchise. Les téléphones n'ont pas la même configuration mais ce n'est pas un problème, c'est l'OS qui s'en occupe. Ton logiciel fait appel à des fonctions JAVA, le reste ne te concerne pas.

Le problème se présente si tu utilise des fonctions avancés qui ne sont présente que sur une version d'android (ex: la 2.2), ou si tu utilise un matériel précis (ex: caméra frontal, CPU ou RAM minimum).

[Pierre87]

c'est vraiment tout con...

pour ce qui est des écrans : il ne font pas la même taille ni la même résolution ni la même densité

il suffit de faire :

- un design adaptatif (ça devrait être aussi le cas pour une "bonne" appli iPhone), ne pas considérer que l'écran fait toujours 320x480

- compter en dip et non en px (simple comme bonjour)

il y a ensuite le problème des versions Android

et bien tu retrouves le même problème sur iOS!

il faut "viser" une version minimum du SDK, en fonction de ce qu'on veut obtenir.

et si on a vraiment besoin de certaines fonctionnalités, il "suffit" de n'y faire appel que si elles sont disponibles!

[Kricek]

il y a ensuite le problème des versions Android

et bien tu retrouves le même problème sur iOS!

il faut "viser" une version minimum du SDK, en fonction de ce qu'on veut obtenir.

et si on a vraiment besoin de certaines fonctionnalités, il "suffit" de n'y faire appel que si elles sont disponibles!

Salut Pierre!

Une partie de ta réponse m'intéresse par rapport à ma question deux topics plus loin... ICI...

Un ptit coup de main n'est pas de refus... lol

[Pierre87]

@Kricek, j'ai répondu aussi :P

[Alocaly]

Bonjour,

Voici mon (humble) avis sur la question :

Effectivement, la diversité 'Android' en général se paye au niveau du développement.

De mon expérience avec mon p'tit jeu de lettres ( Word Prospector, Chasseur de Mots ), et les nouvelles idées que j'ai eu voici ce que je dirais :

* D'abord, et c'est une évidence- mais autant la rappeler -, face à a la fragmentation, tu peux essayer de te limiter à certains types d'appareil Android. Tu peux accepter de ne pas être compatible avec certains types d'appareils, et l'assumer pleinement. Tu peux abandonner des configs exotiques, pour te consacrer à 90% des appareils du marché. Exemple : mon application se veut compatible avec l'Archos IT5, qui n'a pas de bouton physique 'Back', ce qui est pénible en plein écran. Je pense que le nombre d'utilisateurs d'Archos IT5 est ridicule, donc que ce n'est pas bien grave ( mais comme j'en ai eu un pas cher grace à l'offre d'Archos, j'essaye de garder la compatibilité )

* Autre évidence, ca dépend énormément de ton application : de son niveau de finition, et de ses besoins en hardware.

* Pour les tailles d'écrans, effectivement, tu peux faire du code avec des placements en relatifs, qui devraient etre compatible avec tous les écrans. Apres, c'est un peu un voeux pieu : il faudra malgré tout tester au moins sur petits écrans, sur grands, et sur tablettes pour voir ce que ca donne, et corriger le cas échéant. Ensuite, si tu veux des designs super léchés, il vaut mieux penser directement à un design par résolution. Ca me rappelle l'HTML : c'est fait pour marcher sur toute les résolutions d'écrans, et s'adapter. Mais ca fait bien longtemps que cette idée a été abandonnée, et que les sites ne sont plus adaptés en 640x480 !!

Sinon, en vrac des choses qui font que ton application peut dépendre du device sur lequelle elle tourne :

* Le processeur, si tu utilises le NDK

* Pour une application 3D (jeu), la carte 3D. Par exemple, on annonce des jeux optimisés pour Tegra2. Il y a les perf à prendre en compte, les features de la carte 3D ( voire ses bugs !!! Recemment, je regardais un blog d'un gars qui developpe un moteur 3D, et son dernier dev ne marchait plus sur Hero spécifiquement... ), la compatibilité OpenGL 2.0 ou pas,...

* la présence ou non d'un clavier, et les implications ( par exemple, sur mon Dream Orange : tu ne peux pas entrer de texte sans passer en mode paysage )

* Quel OS viser ? ( Par exemple, sur la page de la Tablette Galaxy Tab, ils conseillent de viser au dessus de Android 1.6 car les grands écrans sont mieux pris en compte, mais mine de rien, 1.5 est encore assez répandu - d'ailleurs à cause de Samsung et leur Spica :)

* Est ce que le device gère le multi touch ? Si tu veux une gestion sympa du multi touch, alors, il faut que tu aies un moyen de contourner ca pour les téléphones qui n'en n'ont pas...

* Les caractéristiques matérielles : est-ce qu'il y a une boussole, une caméra frontale, un gyroscope, un écran 3D, ou je ne sais quoi...

...

voila une petite liste de ce qui peut te poser des soucis.

Une fois encore, je dirais que pour une appli simple, tu peux éviter la plupart des soucis MAIS il faut néanmoins tester sur 3 versions d'émulateurs ( normal, petit, grand ).

Apres, pour une appli un peu compliquée, ca peut devenir l'horreur, et effectivement, rajouter pas mal de temps de dev et de temps de test.

Par contre, il me semble que c'est un peu la rancon du succes : Android marche bien parce qu'il s'installe sur plein de devices différents. Il est maintenant à peu pres assuré de dépasser assez vite Apple en terme de part de marché, mais il y a une contrepartie à tout ca !

Emmanuel / Alocaly

[Sylvain G]

Pour conclure on peut dire que c'est les affres du développement, Apple se vente de l'éviter mais puisqu'il y a iPhone 3G, iPhone 3GS, iPhone 4, iPad et iPod Touch ... on en revient au même (pas caméra frontal sur le iPad).

Comme le dit Alocaly, il faut viser le maximum d'appareils possibles, ensuite il faut faire une bonne conception et penser dés le départ à cloisonner les appels à des fonctions spécifiques ou utiliser des fonctions intermédiaires. Par exemple: tu utilise à une fonction spécifique à un matériel (disons Specif), dans ta fonction principale (main) tu fais appel à une fonction intermédiaire (Inter) qui elle appellera la fonction spécifique. En schéma ça donne: main -> Inter -> Specif au lieu de main -> Specif

Du coup si tu change de matériel et que la fonction Specif change, tu ne modifie que Inter.

C'est une recommandation de Java, car si ton application doit tourner sur un serveur Tomcat ou sur la machine Java tu dois optimiser ton code.

Enfin rien de nouveau, quand je lis que le développement sous Android coûte environ 1,5 fois plus cher j'en déduis une mauvais conception !! (normalement dev + debug c'est 30% du temps)