Au prix d'un développement par plate-forme (a moins que tu me dises que l'API iPhone est portée sur windows, Mac et autres?)
Et tu penses que c'est mieux que de tester 48 navigateurs?
Dans une certaine mesure, oui.
C'est sur que pour faire linuxfr ou fesse de bouc, ca vaut pas le coup, faire un site mobile qui tient la route sera bien plus efficace. Si c'est pour chier une HTMLView dans une appli iPhone, c'est un gachis de temps et de resources.
Si tu veux faire une interface riche mobile, t'as le choix entre:
- Developer pour ios et android, avec des api dedies, profiter des specificites des plateformes (notifications push ou geolocalisation par exemple) et une phase de test bien plus simple (la QA va pas devoir s'emmerder avec les inepties d'ie),
- Faire un development unifie, avec des kilos de javascript, qui se limite au denominateur commun au deux plateformes, developement qui va etre douloureux a cause de la nature meme de javascript et des interpreteurs differents, sans meme parler de la phase de test.
Et accessoirement, ca va tourner achement moins vite, j'avais parle de l'appli NY TImes l'autre jour, on m'a repondu avec une version javascript de l'appli.
Bon.
Deja, il manque qq features a cette appli, ca manque de polish dans pas mal d'endroits et surtout, ca tourne vachement, vachement moins vite.
Leur appli ne fait rien de particulier quand on tourne la tablette, mais si c'etait le cas, j'aimerais bien voir la gueule du code d'une SplitView en Javascript.
Ah, et l'appli se banane sur iphone/ipod.
Au final, ca va durer aussi longtemps, mais la solution native aura un developement moins chaotique et ouvre des portes vers d'autres possibilites qui feront plaisir aux business owners.
Le natif vient avec son lot de problemes aussi, notamment les boulets qui mettent pas a jour leur appli, te forcant a versionner des API web et les maintenir. Apres t'as aussi les boulets qui mettent a jour, et la faut gerer la migration des donnees stockees localement (j'ai donne sur iphone, j'ai une petit idee de comment resoudre le probleme proprement et efficacement, ca a rien de simple).
C'est clairement pas aussi tranche que ce que tu le pretends, les deux ont leurs avantages, les deux ont leur inconvenients, penser qu'il faut systematiquement prendre l'un ou l'autre, c'est une grosse erreur, ca depend enormement de ce que tu veux faire.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Nul
Posté par pasScott pasForstall . En réponse au journal Souvenez vous de cette pub : 1984. Évalué à 0.
Et tu penses que c'est mieux que de tester 48 navigateurs?
Dans une certaine mesure, oui.
C'est sur que pour faire linuxfr ou fesse de bouc, ca vaut pas le coup, faire un site mobile qui tient la route sera bien plus efficace. Si c'est pour chier une HTMLView dans une appli iPhone, c'est un gachis de temps et de resources.
Si tu veux faire une interface riche mobile, t'as le choix entre:
- Developer pour ios et android, avec des api dedies, profiter des specificites des plateformes (notifications push ou geolocalisation par exemple) et une phase de test bien plus simple (la QA va pas devoir s'emmerder avec les inepties d'ie),
- Faire un development unifie, avec des kilos de javascript, qui se limite au denominateur commun au deux plateformes, developement qui va etre douloureux a cause de la nature meme de javascript et des interpreteurs differents, sans meme parler de la phase de test.
Et accessoirement, ca va tourner achement moins vite, j'avais parle de l'appli NY TImes l'autre jour, on m'a repondu avec une version javascript de l'appli.
Bon.
Deja, il manque qq features a cette appli, ca manque de polish dans pas mal d'endroits et surtout, ca tourne vachement, vachement moins vite.
Leur appli ne fait rien de particulier quand on tourne la tablette, mais si c'etait le cas, j'aimerais bien voir la gueule du code d'une SplitView en Javascript.
Ah, et l'appli se banane sur iphone/ipod.
Au final, ca va durer aussi longtemps, mais la solution native aura un developement moins chaotique et ouvre des portes vers d'autres possibilites qui feront plaisir aux business owners.
Le natif vient avec son lot de problemes aussi, notamment les boulets qui mettent pas a jour leur appli, te forcant a versionner des API web et les maintenir. Apres t'as aussi les boulets qui mettent a jour, et la faut gerer la migration des donnees stockees localement (j'ai donne sur iphone, j'ai une petit idee de comment resoudre le probleme proprement et efficacement, ca a rien de simple).
C'est clairement pas aussi tranche que ce que tu le pretends, les deux ont leurs avantages, les deux ont leur inconvenients, penser qu'il faut systematiquement prendre l'un ou l'autre, c'est une grosse erreur, ca depend enormement de ce que tu veux faire.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.