Re: Bravo

Si, clairement méthode Coué:
Je ne connais que quelques points d'android haut niveau, et le peu que je connaisse dans ce que tu racontes est faux:

Le modèle d'Android, c'est:
"ton process est à côté d'autres, mais si t'as besoin de RAM c'est pas grave, je peux faire du ménage !"
En gros comme Apple, en plus flexible ...

En plus dr ca, ils ont ajoute un systeme de recuperation des vues inutilisees qui permet de reellement droper 30 a 40% de la ram utilisee pour rien (mesuree avec mes petites mimines a moi).

Sous android, la conception même du système fait que ça marche comme ça: le GC supprime les activités en arrière plan si y a besoin de RAM.

Ce qui explique pourquoi android a besoin d'autant de ram la ou un ipod avec 256Mo s'en sort admirablement (meme un 3g avec 128Mo s'en sort bien en fait, ce qui bloque, c'est le cpu).

Absolument pas. Je sais pas si c'est Java qui l'explique, ou le fait que les développeurs sont
justes mauvais, mais c'est clairement pas le problème.

Tant qu'on parle des animations, parlons de l'api. ICS introduit tout jute une api qui ressemble de loin a ce qu'apple a introduit dans iOS 3 (pardon, iphone os 3), qui est pratique pour des ptits truc mais devient tres vite un enfer pour des trucs un tant soit peu complexe.

Ça serait bien de préciser de quoi tu parles ... Le reste de ton commentaire est précis, sauf ce morceau, c'est étrange. Enfin apparemment tu parles de GUI, que je ne connais pas du tout, donc bon.

Tout le monde gueulait sur apple sur le multi tache, le jour ou google w introduit le multitache, tous ces gens se sont rendus compte pourquoi apple ne le faisait pas: c'est pas faisable sur un pauvre telephone sans ruiner les perfs/la batterie.

Là par contre, je n'ai aucun doute, c'est uniquement de la faute des développeurs (d'applis externes principalement, mais pas que) qui font n'importe quoi, à foutre des wakelocks ou des alarmes à tour de bras, alors que ça ne sert à rien. Après, c'est probablement lié à un manque de dissuasion un peu partout dans la doc.

On peut parler du systeme push. Oui, celui d'iOS est contraignant, mais il marche foutrement bien, et surtout, il ya une seule connexion push ouverte pour tout le telephone. Sur android, tu veux faire pareil, ben... Tu peux pas vraiment, ya pas de push. Du coup tout le monde implemente son propre push (une connexion par appli) ou fait du polling (bye bye la batterie, bonjour facture att).

Même si on l'a attendu TRÈS longtemps, il y a bien un système de push dans Android: C2DM. Sauf que là encore, les devs préfèrent en général utiliser leur propre solution, ce qui explose effectivement la batterie, et ceux qui utilisent C2DM ne savent pas l'utiliser correctement, mais c'est une autre histoire.

Apres, on peut aussi parler de l'utilisation de Java qui doit bien etre le pire langage de la creation pour faire de l'UI. Pas de closure... Pas de closures!

Là j'ai pas de vraie réponse (encore de la GUI, pff...), mais vu d'ici je vois pas trop l'interêt des closures, on dirait des fonctions lambda en plus contraignant. (et sinon suffit de programmer en Scala ! ahum.)

Et apple vient d'envoyer le probleme aux abimes avec ARC de toutes facons. Pas de gc, pas de gestion manuelle de memoire.

ARC est un GC, qui, s'il est aussi simpliste que son nom l'indique, (Automatic Reference Counting pour ceux qui ont la flemme de chercher) peut mener à des problèmes pire qu'un GC Java (un GC Java on peut le borner en temps, ARC pas), mais avec l'avantage de pouvoir prédire quand est-ce que la mémoire sera libérée. Enfin bref, cf la page ramasse-miettes de wikipedia.

PS: Pour le navigateur web lent, c'est par contre bien vrai, mais il parait qu'ils ont enfin un fix... on finirait presque à y croire