Combien de Ram disponible?

[waterproof93]

Certains d'entre vous trouverons surement ce sujet inutile neanmoins j aimerais me faire une idee de combien de ram maximum disponible les utilisateurs du defy ont, et c'est aussi parceque j ai un ami avec un charm qui tourne autour des 280-300mb disponible alors que moi j ai que 220mb max donc je me demandais si c'etais normal. Je tourne en 2.1 rom de base.

[ScratMan]

Oui c'est normal. La RAM dispo ne veut rien dire, puisque l'OS gère ça en live, quand il en a besoin, il en libère tout seul.

[Psychotiks]

Tu as raison et tort, ton sujet est inutiles pour certains et utiles pour d'autres, mais au moins tu sauras que la ram varie d'un utilisateur à un autre et que surtout, ton système va la gérer lui même, donc les task killers c'est CACA. :D

[Burn2]

Sauf si tu sais quelles applications tu utilises ou pas. En fait ce qui est caca, c'est clairement de ne pas pouvoir fermer définitivement une application...

Parce ok pour tout ce qui est courant ça peut être utile, pour ce qui est non courant, c'est débile que ça reste en ram jusqu'à ce que l'os ait besoin de ram et qu'il passe du temps à ce moment là pour libérer la ram, qu'il pouvait déjà libérer avant!

Linux gère déjà le cache, c'est à dire garder en cache les données utilisées et ça nativement.

Là le gros problème en plus de l'inconvénient donné avant (libérer plus tard un programme que tu sais que tu ne vas pas utiliser avant demain par exemple), c'est que du point de vue de la programmation il faut gérer tout tas de cas impensable. Car à tous moment ton application peut être tuée pour libérer de la mémoire pour autre chose même si ça tourne encore. (c'est le cas des services en arrière plan par exemple, sauf si tu utilises une fonction qui va bien pour dire à l'os attention ce service tourne en continue, sauf que dans ce cas tu fais chier l'utilisateur avec une icône).

Bref personnellement je trouve ça pas vraiment top. :/ Que ça le fasse en cas d'urgence je veux bien, mais pas en comportement par défaut. :(

Du coup le task killer permet de tuer à l'avance une tache que tu sais que tu ne vas pas relancer, comme si tu quittais l'application en gros. Et dans ce cas là non ce n'est pas caca. :) C'est du préventif, tu libères à l'avance pour ne pas ramer au moment ou il le fera sachant que tu ne relanceras pas ladite application.

[waterproof93]

Oui c'est vrai qu'Android libère de la ram tout seul quand il en a besoin mais le temps qu'il en est besoin, c'est lent.

C'est bien beau aussi de dire qu'android gère son multitâche nativement et que les tasks killer ça sert a rien mais, moi je ne réussi pas a faire tourner assez d’applications a mon gout sans que le téléphone lag.

Et pour le point de vue de programmation, l’idéal serait tout simplement que les devs utilise reelement la difference entre la touche retour et la touche maison! Ce que je veux dire par la c'est que lorsqu'on appuierai sur home, l'appli se mettrai a tourner en arrière plan et s'afficherai dans les 6 ou 8 dernières applications utilisées (je sais que c'est fait justement pour que ce soit les dernières qui s'affiche mais changer ça ne ferait pas de mal), et lorsqu'on appuierai plus de 2 sec sur la touche retour, l'applications se fermera (kill) (2 sec pour ne pas avoir de conflit avec le retour a une page antérieur) .

Ça nous laisserai ainsi le choix entre les applications qui resterai en tache de fond.

Autre défaut: les applications, qui se redémarre toute seul... Et la je trouve aucune autre solution que de blâmer l'auteur.

Par contre, j'aimerais bien comprendre comment s'y prenne WebOS et iOS pour gérer leurs multitâche qui parait impeccable a vue d'oeil, bien que j'ai écoute dire que c'etais du "faux' multitâche, je ne vois pas en quoi? Si quelqu'un connais le fonctionnement... Et puis quitte a ce que ça marche bien ça ne m'aurait pas trop déranger.

(je suis pas Pro-iOS, mais je pense que le seul fait de l’être nous prouve qu'on a encore a envier de cette OS et que pour l'instant Android n'est pas au point.)

[hjkhjklhjkhkjl]

Il me semble qu'avec iOS, les applications se mettent en pause lors du multitache (à confirmer)...

Sur Android on a la possibilité de coupler plusieurs applications en même temps sans qu'elles ne se mettent en pause (tout de même plus pratique dans certains cas).

[ScratMan]

Sur iOS il n'y a pas de mutlitache car les applications sont soit fermées soit gelées. C'est à dire qu'elles ne peuvent plus rien faire du tout en toile de fond. Pour être active elle doit être en premier plan.

[Le_Poilu]

Autre défaut: les applications, qui se redémarre toute seul... Et la je trouve aucune autre solution que de blâmer l'auteur.

Ca à mon sens c'est le plus gros défaut de la gestion du multi-tache d'android.

Bien trop de développeurs prennent leurs aises à ce niveau et configurent leurs appli pour qu'elles se rechargent d'elles-mêmes (Ca concerne aussi Google, Maps ayant tendance à se relancer sans qu'on lui demande!). La moindre des choses serait de laisser le choix à l'utilisateur en lui demandant s'il veut se comportement ou non. Il y aurait ici un grand nettoyage à faire! (à défaut il faut utiliser des appli comme autostart, mais ça ne résoud pas tout).

Le Pire ce sont celles qui se lancent au démarrage du système, là non plus sans laisser le choix à l'utilisateur. Un exemple flagrant: The Weather Channel: Aussitot installée, aussitôt elle se lance automatiquement au démarrage. Sauf que moi je ne passe pas ma journée à regarder la météo, je m'en sers une fois de temps en temps et je n'ai pas du tout envie que le machin soit constamment chargé pour rien.

Après tout on critique bien ce genre de comportement quand cela se passe sur un Windows (appli qui se lancent toutes seules, installées par les constructeurs, etc), pourquoi sur un smartphone (plus limité en ressources, par définition) on devrait accepter ça.

La gestion de la RAM par le système, c'est une chose, et pour ça Android s'en sort très bien (Comme windows dans son domaine), là n'est pas la question. Mais aussi bon soit le système, il ne peut rien faire contre des appli mal codées et/ou des comportements non souhaités par l'utilisateur. C'est contre ça qu'il faut aller. Et malheureusement c'est pour ça qu'on ne peut pas (encore) se passer de taskiller.

[Burn2]

Oui c'est vrai qu'Android libère de la ram tout seul quand il en a besoin mais le temps qu'il en est besoin, c'est lent.

C'est bien beau aussi de dire qu'android gère son multitâche nativement et que les tasks killer ça sert a rien mais, moi je ne réussi pas a faire tourner assez d’applications a mon gout sans que le téléphone lag.

Et pour le point de vue de programmation, l’idéal serait tout simplement que les devs utilise reelement la difference entre la touche retour et la touche maison! Ce que je veux dire par la c'est que lorsqu'on appuierai sur home, l'appli se mettrai a tourner en arrière plan et s'afficherai dans les 6 ou 8 dernières applications utilisées (je sais que c'est fait justement pour que ce soit les dernières qui s'affiche mais changer ça ne ferait pas de mal), et lorsqu'on appuierai plus de 2 sec sur la touche retour, l'applications se fermera (kill) (2 sec pour ne pas avoir de conflit avec le retour a une page antérieur) .

Ça nous laisserai ainsi le choix entre les applications qui resterai en tache de fond.

Autre défaut: les applications, qui se redémarre toute seul... Et la je trouve aucune autre solution que de blâmer l'auteur.

Par contre, j'aimerais bien comprendre comment s'y prenne WebOS et iOS pour gérer leurs multitâche qui parait impeccable a vue d'oeil, bien que j'ai écoute dire que c'etais du "faux' multitâche, je ne vois pas en quoi? Si quelqu'un connais le fonctionnement... Et puis quitte a ce que ça marche bien ça ne m'aurait pas trop déranger.

(je suis pas Pro-iOS, mais je pense que le seul fait de l’être nous prouve qu'on a encore a envier de cette OS et que pour l'instant Android n'est pas au point.)

Il n'y a pas moyen de fermer l'application. je fais déjà un "finish()" sur lors d'un appuies sur le home ou back au niveau de mon application, et ça ne change rien.

Il n'y a aucun moyen à ma connaissance de vraiment fermer l'application.

C'est ce point là qui est clairement nul.

[Le_Poilu]

Il n'y a aucun moyen à ma connaissance de vraiment fermer l'application.

Euh, faut pas exagérer,les applications peuvent bel et bien se fermer correctement si le développeur le prévoit.

Rien que parmis les appli que j'utilise la majorité se ferment correctement via une fonction adéquat (activée via le menu ou activée par le bouton retour).

C'est pas difficile de vérifier ça: les appli les plus lourdes tels que les jeux, ou les navigateurs GPS se ferment bien et te demandent confirmation. Ce n'est pas anodin ça...si elles ne se fermaient pas ça se sentirait à l'usage!

Le plus ch##t c'est pour une appli comme le navigateur web, pas d'option "fermer" dans le menu, et appuyer sur "retour" quand on a pas mal navigué ça oblige à tout se retaper. là un coup de "home" + taskill est bien plus rapide.

[Burn2]

Sauf que tes jeux sont en C++ et non pas en java android...

Du coup ce n'est pas du tout représentatif. Si tu connais une manière de fermer une application développé pour android sans ndk, et bien je suis preneur! parce que à part le finish() et bien il n'y a rien d'autre

Regarde en ram et via le task killer tu verras si ça ne tourne pas encore en fait.

Exemple: l'application le point, il te demande si tu es sûr de quitter, et bien une fois fermé regarde avec le task killer et?

[Le_Poilu]

Bah j'ai au moins un exemple:

Androcarbu

Développé par un membre Frandroid. Que ce soit via le bouton retour ou le bouton "Quitter" qu'il a mis dans son interface, cela ferme bel et bien l'application (elle n'apparait plus dans les listes de taches ouvertes, ni dans Advanced task manager, ni dans la liste d'appli dans les paramètres android).

S'il y arrive c'est que ça doit être possible non ?

En plus, si une applications tiers comme une taskiller peut tuer toutes les application (sauf forcément avoir les droit ROOT), la logique voudrait que ce soit accessible à toutes les appli et qu'elles puissent se tuer elle-mêmes non ?

Sinon il y a quelque chose que j'aurais du mal à comprendre.

[waterproof93]

Mais la encore, Google pourrait limiter les droits des devloppeurs dans leurs actions (redemarrage intempestive de l'application) ou encore d'avoir la possibilité d’utiliser le freeze (comme sur iOS) pour les jeux par exemple au lieu de consommer en arrière plan lorsqu'on rédige un petit sms.

Bref, il n'y a que les devloppeurs qui ont la possibilités de changer ça et d’améliorer considérablement l’expérience Android, car donner a un novice ce type de téléphone et il regrettera amèrement son ancien iphone, mais la encore la plupart des applications connues viennent d'iOS et le portage vers Android et généralement déplorable, c'est a ce demander si les devs savent comment utiliser Android avant de programmer dessus, biensur il existe quelques bonnes applications qui respecte très bien tout çà, et puis on ne peut pas tout reprocher au devloppeurs quand on voit que google lui même fait les même erreurs comme la si bien dit Le_Poilu.

En tout cas, même si c'est problèmes sont régler dans le futur (on espère toujours), nos Defy seront surement enterres d'ici la et c'est dommage pour si un bon téléphone, déjà qu'il a un bootloader bloque...

[Burn2]

Bah j'ai au moins un exemple:

Androcarbu

Développé par un membre Frandroid. Que ce soit via le bouton retour ou le bouton "Quitter" qu'il a mis dans son interface, cela ferme bel et bien l'application (elle n'apparait plus dans les listes de taches ouvertes, ni dans Advanced task manager, ni dans la liste d'appli dans les paramètres android).

S'il y arrive c'est que ça doit être possible non ?

En plus, si une applications tiers comme une taskiller peut tuer toutes les application (sauf forcément avoir les droit ROOT), la logique voudrait que ce soit accessible à toutes les appli et qu'elles puissent se tuer elle-mêmes non ?

Sinon il y a quelque chose que j'aurais du mal à comprendre.

Sauf que la logique avec google... Il serait logique de pouvoir désactiver/activer le gps de manière programmable, sauf que non google ne donne pas ce droit là.

Sur les docs de google je ne vois nulle part de solution pour fermer l'application, j'ai contacté l'auteur d'androcarbu pour savoir comment il a fait, mais sache que ce n'est jamais ce que préconise google. Qui ne parle jamais de fermer l'application...

D'ailleurs, depuis foyo et android 2.3 tu ne peux pas vraiment tuer une application, elle peut très bien se relancer toute seule, et devenir intuable, on remercie google sur ce coup là. :/

Non y a clairement un gros manque de ce côté là. :/

[Le_Poilu]

Sauf que la logique avec google... Il serait logique de pouvoir désactiver/activer le gps de manière programmable, sauf que non google ne donne pas ce droit là.

Bah oui, il y aurait encore pas mal de choses que Google pourrait "ouvrir" dans son système (comme l'activation/desactivation de la 3G aussi) ... mais bon, un jour peut-être on y arrivera!

[ScratMan]

Attention à ne pas tout mélanger, messieurs.

Par exemple pour Maps qui est lancé automatiquement, ce n'est pas parce que Google veut être omniprésent et vous espionne, mais parce que l'application Maps sert de service de base pour la gestion du GPS. Il faut distinguer "l'application" Maps avec son interface complète, et le "service" Maps qui fait l'interface entre le système et les applications. Ceci car les applications tierces ne peuvent pas avoir un accès direct au hardware, déjà pour des raisons de compatibilité, et aussi pour qu'elles ne puissent pas faire n'importe quoi.

C'est pour ça que lorsque l'on s'amuse à tuer certaines tâches qui tournent en fond, des fonctionnalités se mettent à déconner, malgré qu'à priori ça n'a aucun lien. Exemple avec GTalk et la synchronisation.

Pour les possibilités d'activer ou désactiver le GPS ou la 3G, c'est déjà possible dans le système de base, et les applications peuvent le faire également, en passant par les services système.

Pour les applications qui se relancent seules, ce n'est pas une faille, puisque c'est un comportement nécessaire au système (Windows fait la même chose avec ses services système). Et si une application est nécessaire, le système la relancera toujours. Ce qui est criticable, c'est quand un programmeur tiers fait passer son application pour une application système (à la façon d'un antivirus) alors qu'elle n'en a pas besoin.

Pour les applications qui continuent de tourner en fond, ou bien sont gelées ou fermées, c'est au choix du programmeur.

Pour résumer, le problème ne vient pas de Google, leur but étant de créer un système d'exploitation ouvert ils ont laissé les possibilités requises pour qu'il le reste, au contraire de Symbian ou iOS ; et ça marche, mais certains développeurs d'applications en abusent. C'est auprès d'eux qu'il faut se plaindre (et ne plus télécharger leurs applications), pas auprès de Google.