iphone? HTC? - Page 96

Ils ne sont pas les seuls, certes, mais ils sont les seuls à être partout...

Nil (./2841) :
même si j'avoue que ce serait bien que tout soit vraiment normalisé, comme ça on pourrait en effet utiliser n'importe quelle appli depuis n'importe quel navigateur

Oui, c'est bien la condition indispensable pour qu'un écosystème standard se développe, pour le moment il y a trop de fonctionnalités des smartphone qui ne sont pas utilisables facilement (voire pas utilisables du tout) depuis une appli web. Malheureusement comme le dit Flanker, aucun intérêt pour un constructeur à être le premier à sauter le pas, puisqu'il perdrait son exclusivité. Il n'y a que de la part d'une plate-forme qui n'a aucune autre chance de se développer (comme Windows Phone) que ça pourrait venir

Zerosquare (./2842) :
Pas mal d'applis mobiles sont déjà critiquées pour consommer de la batterie et des ressources système, ce serait sûrement encore pire si elles reposaient sur du non-natif (suffit de voir comme certains sites arrivent à ramer et bouffer de la RAM, même sur un PC)

Je sais que c'est un argument qui te tient à coeur, mais je ne suis vraiment pas d'accord pour ce type d'applications. Il s'agit très souvent de GUI qui ne font strictement rien tant que l'utilisateur ne clique pas sur un bouton ou n'ouvre pas une fenêtre, je ne pense pas que la techno derrière fasse une quelconque différence de consommation ou d'utilisation CPU, à partir du moment où les couches bas niveau font 99.9% du boulot et sont fournies par le système dans les deux cas. Sans compter que les applis "natives" Android sont souvent en Java, donc c'est pas tellement plus natif que du JavaScript de toutes façons.

Nil (./2846) :

flanker (./2845) :
Quant aux applis HTML/JS... bah Apple a essayé et a abandonné. Palm a essayé et a abandonné. BlackBerry a essayé et a abandonné. Mozilla a essayé et a abandonné. Et à chaque fois, je vois "c'est fois-ci, c'est la bonne". En pratique, elles sont mal intégrées au système, plus dures à développer (si on veut faire les choses proprement, avec cache, websocket, localstorage, etc.) et moins réactives.

Ce sera peut-être au W3C de proposer de vraies extensions au HTML et/ou au JS ? Avec un vrai environnement de développement d'applications riches...

Mouais… franchement pas convaincu. Ça fait des années qu'on nous promet ça.
Au final, je trouve que faire un client lourd est de plus en plus simple, alors que faire du dév. web est de plus en plus complexe, et rajouter des extensions va surtout rajouter de la complexité.
C'est sûr, c'est facile de faire un petit site web en PHP. Maintenant, faire quelque chose avec des websockets, du localstorage, qui reste en cache même hors-connexion, qui soit super fluide, qui soit correctement intégré au système, qui s'adapte à tous les écrans, … est tout autre chose.

De plus, j'ai beaucoup de mal à croire qu'on puisse avoir les avantages du client lourd avec du client léger, sans avoir les inconvénients qui vont avec. Pour reprendre Office, j'ai du mal à croire qu'un client léger puisse réellement faire la même chose qu'Office sans avoir la même quantité de code à télécharger.

De toute façon, ce n'est pas compliqué : il y a plein d'outils qui permettent d'utiliser le même code pour cibler à la fois Android et iOS. S'ils n'utilisent pas HTML + JS, c'est qu'il y a des raisons ^^

Zeph (./2852) :
Je sais que c'est un argument qui te tient à coeur, mais je ne suis vraiment pas d'accord pour ce type d'applications. Il s'agit très souvent de GUI qui ne font strictement rien tant que l'utilisateur ne clique pas sur un bouton ou n'ouvre pas une fenêtre, je ne pense pas que la techno derrière fasse une quelconque différence de consommation ou d'utilisation CPU, à partir du moment où les couches bas niveau font 99.9% du boulot et sont fournies par le système dans les deux cas. Sans compter que les applis "natives" Android sont souvent en Java, donc c'est pas tellement plus natif que du JavaScript de toutes façons.

On ne parle pas des mêmes applis, je pense. Pour une truc tout simple avec quelques boutons, je suis d'accord avec toi que ça ne va pas probablement pas faire de différence notable (et c'est assez ridicule de vouloir à tout prix imposer une appli pour quelque chose qu'un site web ferait aussi bien, sans avoir besoin d'installer quoi que ce soit).

Par contre si tu prends par exemple une application de navigation GPS, qui est quand même pas totalement triviale et qui peut tourner "activement" pendant un certain temps, je pense pas que le web puisse faire jeu égal (en perfs, fluidité d'affichage et consommation batterie) avec du natif. Et vu que de plus en plus de gens font désormais sur smartphone/tablette ce qu'ils faisaient avant sur desktop, je pense que les applis iront en se complexifiant, justement.

Quant à Android :
- je ne sais pas si c'est encore vrai, mais à une époque il était justement reproché aux applis Android d'être moins réactives que leur équivalents sur iOS, à hardware grosso-modo équivalent
- tout n'est pas en Java, il y a le NDK je crois ?

(cross avec Flan, qui va un peu dans le même sens )

(pendant longtemps les iPhone ont été plus réactifs que les Android, même avec du matériel moins puissant, avec surtout nettement moins de RAM ; je ne sais pas si c'est encore le cas maintenant, j'espère que non quand on voit les perfs brutes des téléphones modernes)

flanker (./2853) :
Mouais… franchement pas convaincu. Ça fait des années qu'on nous promet ça.
Au final, je trouve que faire un client lourd est de plus en plus simple, alors que faire du dév. web est de plus en plus complexe, et rajouter des extensions va surtout rajouter de la complexité.
C'est sûr, c'est facile de faire un petit site web en PHP. Maintenant, faire quelque chose avec des websockets, du localstorage, qui reste en cache même hors-connexion, qui soit super fluide, qui soit correctement intégré au système, qui s'adapte à tous les écrans, … est tout autre chose.

De plus, j'ai beaucoup de mal à croire qu'on puisse avoir les avantages du client lourd avec du client léger, sans avoir les inconvénients qui vont avec. Pour reprendre Office, j'ai du mal à croire qu'un client léger puisse réellement faire la même chose qu'Office sans avoir la même quantité de code à télécharger.
De toute façon, ce n'est pas compliqué : il y a plein d'outils qui permettent d'utiliser le même code pour cibler à la fois Android et iOS. S'ils n'utilisent pas HTML + JS, c'est qu'il y a des raisons ^^

Je suis totalement d'accord avec toi, c'est pour ça que je pense que la solution ne peut venir que d'une proposition du W3C qui aille plus loin que HTML/JS, mais un véritable framework destiné à faire du lourd dans du léger, et pas une surcouche qui rendrait encore plus complexe le développement en JS (ou alors il faudrait vraiment retravailler la partie JS pour avoir de vraies applications JS dans un format normalisé).

Par contre, j'ai l'impression que tu as dévié pour la seconde partie : on parle d'applications sur smartphones, à la base, donc le téléchargement ne se fait pas à la volée mais tout est en local. Et on pourrait même imaginer que, dans le cas de ces applications, on ait des scripts tokenisés ou semi-compilés afin d'accélérer leur exécution.

Zerosquare (./2854) :
Par contre si tu prends par exemple une application de navigation GPS, qui est quand même pas totalement triviale et qui peut tourner "activement" pendant un certain temps, je pense pas que le web puisse faire jeu égal (en perfs, fluidité d'affichage et consommation batterie) avec du natif. Et vu que de plus en plus de gens font désormais sur smartphone/tablette ce qu'ils faisaient avant sur desktop, je pense que les applis iront en se complexifiant, justement.

Tout dépends ce que tu fais. Si tu veux une application performante, tu ne peux en effet pas envisager ton application comme une application Web classique. Mais maintenant, le Web offre ou ne va pas tarder a offrir des solutions plus orientées performances (Canvas, WebGL, ...).
Avec WebAssembly, même si on restera légèrement en dessous on devrait être pas trop loin des performances natives (en tout cas plus performant que Java).

En fait, je ne comprends vraiment plus ce que tu proposes :

• un framework client lourd avec du HTML/JS mais qui ne fait pas pas de HTTP/WS ?
• un framework client léger qui serait différent du HTTP/WS et imposé par le W3C ?
• un framework client léger, différent du HTTP/WS mais où tout est prétéléchargé en local ?

Si tout est téléchargé comme une appli normale et qu'il n'y a pas de serveur HTTP/WS dans la boucle, ça revient à inventer un nouveau framework de dév. de client lourd multiplate-forme (encore un !), j'ai du mal à en voir l'intérêt par rapport à Qt (que tu peux déjà utiliser avec plein de langages de scripts).
Si tout est téléchargé en local, comme une appli normale et qu'il y a un serveur HTTP/WS en local… bah c'est encore pire

Quant à faire un nouveau protocole de client léger, qui serait différent du HTTP/WS et plus puissant… mouais, je n'en vois pas l'intérêt par rapport à une appli déjà téléchargée.

Zero: a vrai dire vu comment certains codent comme des porcs, j'aurais tendance a penser que si le navigatueur web est pas trop mal foutut, il pourrais consommer moins qu'une app native avec des perfs équivalentes, et pour le coup une application de type GPS routier, je pense pas qu'une version HTML soit si compliqué que ca a faire, et a vrai dire il y aurais deux gros avantages a faire comme ca :

- Le calcul d'itinéraire est fait par le serveur et non l'appareil, donc ca consomme moins et probablement plus rapide et précis pour des tres long trajets, car les serveurs n'ont pas les contraintes mémoire/temps/CPU qu'un appareil mobile
- Les cartes sont toujours a jours car téléchargé a la demande (a la google map)


Bien sur le gros désavantage la est qu'offline tu es dans la merde, mais l'app pourrais être fait de manière intelligente et télécharger tous les blocs de cartes correspondants a la zone qui va etre parcourue, ainsi qu'un certains nombre d'itinéraire alternatifs, quitte a faire calculer un peu en local si vraiment besoin, mais dans ce cas les distances serait relativement courtes et serait que pour des itinéraires d'évitement.

Godzil (./2859) :
il pourrais consommer moins qu'une app native avec des perfs équivalentes

Je ne vois pas comment c'est possible : une couche d'abstraction supplémentaire a au mieux un coût négligeable, mais elle ne peut pas avoir un coût négatif. Et les optimisations dont tu parles peuvent être implémentées exactement de la même façon par une appli native. Par ailleurs, plus tu déportes les calculs, plus tu as de requêtes réseau (ce qui n'est pas forcément bon pour l'autonomie).

Zerosquare (./2860) :
plus tu as de requêtes réseau (ce qui n'est pas forcément bon pour l'autonomie).

Ni pour la réactivité !

Zerosquare (./2860) :
Je ne vois pas comment c'est possible : une couche d'abstraction supplémentaire a au mieux un coût négligeable, mais elle ne peut pas avoir un coût négatif. Et les optimisations dont tu parles peuvent être implémentées exactement de la même façon par une appli native. Par ailleurs, plus tu déportes les calculs, plus tu as de requêtes réseau (ce qui n'est pas forcément bon pour l'autonomie).

Si tu fais le calcul de tout le trajet en une seule fois, le nombre de requêtes réseau va rester limité (1 requête, jusqu'à ce que tu t'éloignes de ce trajet). Ce que voulait dire Godzil concernant l'implémentation, à mon avis, c'est que faire une app GPS va te demander d'implémenter toi-même (et donc potentiellement mal) un certain nombre de mécanismes qui sont disponibles de base quand tu fais une appli web. Un exemple idiot : un développeur ne pourra pas faire un thread qui tourne en boucle en background tout en vidant ta batterie, parce que faire du JS t'interdira ça. Tu vas être obligé de tout coder en évènementiel, avec une consommation probablement moindre (tu aurais pu le faire dans une app bien sûr, mais comme c'est plus simple d'écrire while (true) { ... } j'ai peut qu'en pratique certains apps se contentent de ça).

Sinon pour le NDK je n'ai aucun chiffre, mais à mon avis son utilisation est bien moins fréquente que celle du SDK.

Zeph (./2862) :
Un exemple idiot : un développeur ne pourra pas faire un thread qui tourne en boucle en background tout en vidant ta batterie, parce que faire du JS t'interdira ça.

Maintenant c'est possible avec les Worker Threads. Et même sans ça, on sait depuis bien longtemps faire du JavaScript tout pourri qui consomme inutilement.
Pour être honnête, il faut comparer a qualité de code égale.

Zeph (./2862) :
Ce que voulait dire Godzil concernant l'implémentation, à mon avis, c'est que faire une app GPS va te demander d'implémenter toi-même (et donc potentiellement mal) un certain nombre de mécanismes qui sont disponibles de base quand tu fais une appli web.

Houlà, tu es beaucoup plus optimiste que moi sur la facilité à faire du code pourri, indépendamment de la qualité de ce qui est mis à disposition

Il suffit de voir les sites web : ça a beau tourner dans un browser, beaucoup ont du code JS absolument ignoble qui bouffe de la RAM et de la batterie. Ou de lire TheDailyWTF, où tu as plein d'exemples de réimplémentations médiocres de features qui existent déjà (en bien mieux) dans les langages/frameworks utilisés, parce que le dév a été trop fainéant pour réfléchir et prendre le temps de se documenter sur ses outils.

Pour revenir en arrière, à l'arrivée des outils RAD, des frameworks, des langages de plus haut niveau, etc., certains ont pensé aussi que ça allait donner un résultat de meilleure qualité, en permettant aux développeurs de s'appuyer sur des bases bien foutues au lieu de devoir réinventer des roues carrées. À chaque fois ça n'a pas été le cas : un mauvais développeur reste mauvais, quel que soit les outils qu'il utilise. Ça a même eu des effets pervers : les mauvais peuvent de plus en plus facilement faire illusion en bricolant des trucs qui marchent mal, et concurrencer ainsi ceux qui travaillent sérieusement.

(C'est un débat qui dépasse le cadre de l'info d'ailleurs, on trouve des analogies dans d'autres domaines, dès que les outils pros sont devenus plus simples à utiliser et sont arrivés dans les mains des "amateurs").

(, par exemple dans le bâtiment en ce qui me concerne. Un mec qui fait de la merde bien camouflée et qui va vite sera mieux vu qu'un gars sérieux, qui fait du durable et solide)

Flanker > Un framework qui étende le HTML/JS, imposé par le W3C (avec, par exemple, la gestion d'abstractions matérielles de façon plus générique - accès à l'USB, par exemple, mais aussi permettant de faire des requêtes d'allocation mémoire anticipées, ou de préserver des informations en mémoire de façon simplifiée entre deux chargements de pages sans avoir à les sérialiser...
Le tout devant être considéré comme un standard du Web pour que les navigateurs le gèrent directement sans plug-in, afin de ne pas retomber dans les travers des applets Java.
Et je fais une distinction non pas technique mais fonctionnelle entre
- une appli web destinée à être chargée à la volée (donc soit légère, soit avec de la bande passante)
- une appli web "lourde" installée localement (et mie à jour comme une appli lourde), destinée à être utilisée dans un moteur web (donc "universelle" quelle que soit la plateforme) et qui fait des requêes web pour récupérer les données qui vont l'alimenter... par exemple, une suite bureautique est totalement imaginable en HTML/JS, mais ça n'a aucun sens de retélécharger l'application à chaque fois. Par contre, le fait qu'elle soit en HTML/JS la rend portable sur toutes les pltaeformes. Ce qu'aurait dû permettre le développement d'applications en Java, sauf qu'en pratique ça n'est pas aussi évident aujourd'hui (pour de vraies bonnes raisons, mais aussi de faux problèmes).

Zero: je pensais surtout au fait que pour certains trucs du code de VM tourne mieux et plus vite que tu code compile parce que certaines optimisations peuvent être fait à l'exécution et pas à la compilation. Les cas sont rare mais cest dans le domaine du possible, et je préfère une appli web *BIEN* codé à une appli native faire avec les pieds.

Godzil (./2867) :
Zero: je pensais surtout au fait que pour certains trucs du code de VM tourne mieux et plus vite que tu code compile parce que certaines optimisations peuvent être fait à l'exécution et pas à la compilation.

Exact. Mais je ne sais pas si c'est significatif dans le cadre d'une appli mobile. Et dans l'absolu, rien n'interdit de faire du profiling sur une application native et d'optimiser les hot spots.

Godzil (./2867) :
je préfère une appli web *BIEN* codé à une appli native faire avec les pieds.

On est d'accord ^^

Nil (./2866) :
Flanker > Un framework qui étende le HTML/JS, imposé par le W3C (avec, par exemple, la gestion d'abstractions matérielles de façon plus générique - accès à l'USB, par exemple, mais aussi permettant de faire des requêtes d'allocation mémoire anticipées, ou de préserver des informations en mémoire de façon simplifiée entre deux chargements de pages sans avoir à les sérialiser...

Ca existe déjà plus ou moins via les WebAPI que Mozilla a soumis au W3C. Mais ça ne pourra pas être standardisé tant que FirefoxOS restera le seul à les implémenter.

Zeph > bof, non : suffit de faire un truc du genre ci-dessous pour pourrir ton navigateur ^^
function toto () { blabla; setTime(1000, toto);}
setTimeout(1000, toto);

Godzil (./2867) :
je préfère une appli web *BIEN* codé à une appli native faire avec les pieds.

Certes, mais je préfère une appli native bien codée à une appli web faite avec les pieds et je pense qu'il est plus facile de bien coder en natif, maintenant.

Nil (./2866) :
Flanker > Un framework qui étende le HTML/JS, imposé par le W3C (avec, par exemple, la gestion d'abstractions matérielles de façon plus générique - accès à l'USB, par exemple, mais aussi permettant de faire des requêtes d'allocation mémoire anticipées, ou de préserver des informations en mémoire de façon simplifiée entre deux chargements de pages sans avoir à les sérialiser...
Le tout devant être considéré comme un standard du Web pour que les navigateurs le gèrent directement sans plug-in, afin de ne pas retomber dans les travers des applets Java.
Et je fais une distinction non pas technique mais fonctionnelle entre
- une appli web destinée à être chargée à la volée (donc soit légère, soit avec de la bande passante)- une appli web "lourde" installée localement (et mie à jour comme une appli lourde), destinée à être utilisée dans un moteur web (donc "universelle" quelle que soit la plateforme) et qui fait des requêes web pour récupérer les données qui vont l'alimenter... par exemple, une suite bureautique est totalement imaginable en HTML/JS, mais ça n'a aucun sens de retélécharger l'application à chaque fois. Par contre, le fait qu'elle soit en HTML/JS la rend portable sur toutes les pltaeformes. Ce qu'aurait dû permettre le développement d'applications en Java, sauf qu'en pratique ça n'est pas aussi évident aujourd'hui (pour de vraies bonnes raisons, mais aussi de faux problèmes).

En gros, un nouveau framework client lourd multiplate-forme sans recompilation, mais qui ne permet pas de choisir le langage de programmation et qui se met dans une fenêtre avec des menus inutiles pour l'application en question.
Ne serait-ce pas exactement l'idée de Java (mais en moins bien, vu que ça force la fenêtre dans laquelle c'est exécuté).

Flan: je ne suis pas entièrement d'accord, coder en natif n'est pas très compliqué, mais bien coder, surtout sur de l'embarqué c'est loin d'être a la porté de tous et il y a beaucoup de truc merdiques, beaucoup beaucoup.

Zero: l'autre avantage d'une VM, c'est qu'on peux plus facilement mettre des restriction sur l'occupation CPU/Memoire qu'avec du natif, si par exemple le code se met a prendre 100% du CPU émulé pedant plus de 5s, la VM peux ralentir l'execution du code pour economiser la batterie.

Enfin rien n'est simple et flan, oui bien sur je préfère du natif bien codé a du web mal codé (et aussi du natif bien codé a du web bien codé)

./2870 : même ce bout de code est bien moins violent pour ton CPU qu'une boucle infinie. Pour le rendre vraiment très inefficace il faudrait réduire l'intervalle et ça risquerait alors de devenir perceptible côté UI (l'application "ramerait"). Même chose avec les workers, ce ne sont pas des threads et eux aussi sont soumis aux mêmes contraintes évènementielles que le fil d'exécution principal.

Zeph (./2872) :
./2870 : même ce bout de code est bien moins violent pour ton CPU qu'une boucle infinie

Le problème n'est pas au niveau du CPU mais au niveau de la mémoire (qui va grimper peu à peu et faire ramer à cause du nombre d'objets qui traînent)

Pourquoi plus de cette façon qu'avec n'importe quelle autre approche ? (en supposant que le reste du code est équivalent)

Aucune idée, mais j'ai fait la bêtise et ça ramait monstrueusement sur le long terme (genre 10 minutes) avec un settimeout, alors que ça passe sans souci avec un settimer (qui est la façon propre de faire, ça tombe bien )

Personnellement, je trouve qu'il est plus dur de faire un code propre en web qu'en natif (même si ce n'est pas évident en natif).

A vue de nez, le settimeout ne doit pas liberer l'objet appelant tant que le timeout n'a pas eu lieu, le settimer tu doit repondre la main un fois la fonction et le callback enregistré, donc tu libere la fonction.

Tout ca est une supposition bien sur, mais je pense que l'effet de settimeout reviens a faire un appel recursif sans fin, settimer a juste ajouter une entrée dans la liste des callback et la fonction X est appelé apres un temps déterminé

Godzil (./2876) :
A vue de nez, le settimeout ne doit pas liberer l'objet appelant tant que le timeout n'a pas eu lieu, le settimer tu doit repondre la main un fois la fonction et le callback enregistré, donc tu libere la fonction.
Tout ca est une supposition bien sur, mais je pense que l'effet de settimeout reviens a faire un appel recursif sans fin, settimer a juste ajouter une entrée dans la liste des callback et la fonction X est appelé apres un temps déterminé

Oui, je pense aussi que c'est ça ; c'est une des raisons pour lesquelles je trouve qu'il est dur de faire du code propre en JS + HTML ^^

Oui enfin si ton principal problème en Javascript, c'est les fuites de mémoire, dis toi qu'en la plupart des langages natifs, tu vas pleurer.

Déjà oui, et puis même si Godzil a raison dans l'exemple de Flanker l'objet à libérer n'est qu'une closure, je ne pense vraiment pas que le souci venait de là

flanker (./2870) :
Ne serait-ce pas exactement l'idée de Java (mais en moins bien, vu que ça force la fenêtre dans laquelle c'est exécuté).

C'est en effet l'approche du Java, sauf que les Applets sont justement abandonnées parce qu'elles apportent plein de problèmes, que le Java compilé n'est pas exécutable partout, qu'il y a des API spécifiques à certaines plateformes, et qu'on réembarque dans des libs Java plein de trucs qui sont déjà présentes dans les navigateurs... et que je crois qu'Apple a interdit Java sur iOS, non ?