Les notifications Push, une fausse bonne idée ?

Nicolas Furno |

Les notifications Push sont la réponse officielle d'Apple à l'absence revendiquée de multitâche sur les iPhone et iPod touch. Longtemps attendue, cette fonctionnalité devrait enfin arriver avec la sortie d'iPhone OS 3 au cours de l'été. Néanmoins, est-ce vraiment la meilleure solution ? Et si le Push était une vraie fausse bonne idée ?



Comme l'explique Dan Moren de Macworld, le Push — envoi de messages ou sons à propos d'un événement interne à une application même si celle-ci n'est pas ouverte — n'a pas du tout changé entre sa présentation initiale en juin 2008 et sa réintroduction, la semaine dernière. Comme si Apple avait oublié la fonction et l'avait redécouverte, ou de manière plus probable, comme si Apple avait voulu la garder au chaud pour iPhone OS 3.

En janvier dernier, nous nous demandions si l'entreprise de Cupertino n'avait pas tout simplement abandonné l'idée qui n'a pas, il est vrai, que des avantages. Très utile dans le cas des messageries instantanées, le Push n'est néanmoins pas la panacée et ne résout rien pour les applications audio (radio Internet) par exemple. Pis, un tel système peut devenir vite contre-productif et très agaçant pour l'utilisateur : imaginez que vous suivez de nombreuses personnes sur Twitter, l'annonce de l'arrivée d'un SMS sera perdue au milieu de dizaines de messages Twitter. Autant dire que tout l'intérêt du système s'annulerait immédiatement et les utilisateurs auraient tôt fait de le désactiver, d'autant que tapoter douze fois un bouton n'a rien de passionnant.

Bien sûr, il y aura des moyens de contrôler ce flot d'informations potentiellement gênant, mais il semble que ce sont les développeurs qui devront choisir quelles options seront accessibles aux utilisateurs. De ce fait, il y aura toujours le risque de tomber sur un programme gênant. Par ailleurs, si Apple a assuré lors de la conférence que le système était capable de supporter l'envoi d'informations aux millions d'utilisateurs dans le monde, cela reste à prouver. Twitter est ainsi un très gros consommateur de données, surtout pendant certains événements (comme les Keynotes d'Apple, d'ailleurs...) .

Tout cela amène Dan Moren à penser que le Push est un pis-aller, en attendant que le matériel soit capable de gérer le multitâche sans vider la batterie en une demi-journée. Peut-être qu'Apple a espéré sortir un nouveau téléphone à la hauteur pour le mois de juin, et ayant échoué ait ressorti le Push de ses cartons, en attendant mieux. Après tout, on se souvient que Steve Jobs avait présenté le développement d'applications web comme la meilleure solution pour l'iPhone. Depuis, Apple a changé d'avis et après plus de 800 millions de téléchargements, on peut se dire que l'entreprise à la pomme a été bien inspirée.

Espérons, en tout cas, qu'Apple réfléchisse vraiment aux problèmes évoqués précédemment et y apporte de vraies solutions d'ici la sortie de la mise à jour.

avatar elamapi | 
C'est clair que de toute façon ça paraît un peu un emplâtre sur une jambe de bois, et ce depuis le début.
avatar fromdisco | 
En voilà un vrai bon article :) C'est clair que si l'iPhone était capable de faire tourner 20 apps en même temps sans se ruiner son processeur et sa batterie, la question du push notification ne se poserait même pas. Mais c'est de l'aveu même d'Apple, répété dans la dernière keynote. Apple n'a jamais dit autre chose. Donc c'est bien, Dan Moren pense comme Apple, mais avait-il vraiment besoin de le penser ? Quoi de neuf Dan ? Rien.
avatar Tom | 
La présentation de ce push comme réponse à l'absence de multi-tâche me dérange beaucoup. Pour moi, ce n'est pas une réponse, c'est une fonctionnalité supplémentaire. Il y a en effet des applications qui s'accordent très bien avec cette fonctionnalité. Mais le multi-tâche est tout à fait différent ! Je comprends la limite technique, néanmoins, sans être multi, ils auraient au moins pu permettre 1 ou 2 tâches en fond, sélectionnable par l'utilisateur puisque certaines des applis Apple le font : iPod, Mail, phone etc. A l'utilisateur de gérer ensuite sa sur-consommation d'énergie etc. Mais ce n'est pas tant ce multi-tâche qui me dérange, mais le manque d'interopérabilité entre les applis qui me chagrine... Et là, la limite est surtout sécuritaire.
avatar iSc0tty | 
Moi je dis qu'on demande à apple de pouvoir porter un éléphant sur chaque épaule tout en faisant un marathon...
avatar brunitou | 
Pour moi à défaut de ne pas suivre mouton l'article, je pense que c'est une excellente idée pour les appareils mobiles et j'espère qu'elle se généralisera à une future tablet Mac. Je dis pas que l'implémentation d'Apple est la plus avancée mais elle répond à un problème réel de longévité de la batterie. On désire toujours plus durée de vie, je ne vois pas pourquoi Apple reviendrait en arrière si cela peut lui faire gagner les précieuses minutes qui la pousse devant ses concurrents. Si je me souviens bien dans la présentation, ils parlaient aussi d'ajouter juste une bulle avec par exemple le message en attente. Je pense que les programmeurs intelligents permettront de choisir la manière dont l'information "push" s'affiche à l'écran. De plus ça ne sert à rien d'être conservateur avec le SMS !!! C'est dépassé avec tous les messages qu'on peut laisser ou s'échanger sur les sites sociaux, avec les programmes de chat etc... le SMS est voué à disparaître et je ne vois donc pas pourquoi ne pas le mettre sur le même pied d'égalité. C'est comme le MMS, en Beglique, il n'est presque pas développé et tout le monde s'en passe par contre pas de l'email...
avatar JoTaPé | 
Je n'aime pas ce genre d'articles ou l'on confond tout.. Ce n'est pas le multitache qui fait fondre la batterie, mais les connections réseaux "permanantes" ! Le Wifi actif et en activitée prend beaucoup de batterie, la 3G en activitée consome beaucoup de batterie, écouter de la musique en jouant avec la calculatrice ne consomme pas beaucoup plus que juste en jouant avec la calculatrice, pourtant il y a une tache qui fait jouer la musique en tache de fond.. L'iPhone en fait tourner des taches en "tache de fond", bien plus d'une, les propos d'Apple ne sont peut-être pas clair, et interdir le multitache a peut-être été stupide (ie un moyen plus que radical, peut-être un peu trop) mais c'est pour empecher des applications d'avoir une connection permanente, que ça soit a l'insu de l'utilisateur ou non, qui force l'iPhone a être connecté tout le temps, et donc manger de la batterie au max. Je ne connais pas la politique exact de gestion de l'énergie sur l'iPhone, mais elle est faite pour que meme si le WiFi est actif mais qu'il y a une activitée nulle ou moyenne le Wifi ne soit actif que quand c'est vraiment utile... Bref, l'iPhone supporte TRES BIEN le multitache, et la technologie ne changera rien ou presque, une connection permanente mange de la batterie et ce n'est pas une evolution technologique qui le changera
avatar DrPiquouze | 
vous le faites exprès ? Dans l'article quand nicolas parle de multitache, il est plus qu'évident qu'il fait allusion au multi-application.
avatar Mayorkam | 
Nicolas, tu as oublié une donnée importante, c'est que maintenant l'accès au mail ou au net peut se faire directement à partir d'une application si le programme l'exige. C'est tout de même une bien meilleure implémentation du multitâche que, de son appli directement pouvoir lancer un mail ou prendre une photo ou aller sur le net plutôt que de devoir, MEME avec le système du Pre, naviguer d'une appli à l'autre en mode visuel. Quant au Push, son intérêt résidera dans la façon là aussi de l'implémenter, ce n'est pas une technologie au rabais. C'est me^me ce qui fait aujourd'hui la force de RIM dans les entreprises... Marrant ça...avant que le Push ne soit sur l'Iphone, c'étrait le bien, maintenant qu'il y est et en plus de faço transversale au système, et ce n'est qu'un pis aller. C'est peu dire qu'une alerte peut être bien plus efficace dans un cadre pro que le fait d'aller sur l'appli pour vérifier que quelque chose s'est passé. Et étrange aussi que l'on accuse Aple de privilégier trop souvent la forme sur le fond alors que là on vénère d'un coup d'un seul une fonctionalité (le multitâche à la Pre) qui risque fort de ne pas être si pratique que cela et qui n'set en rien une implémenation adaptée au format portable, le mieux étant encore de ne même pas sortir de son application pour lancer une autre tâche. Et ça, ce sera possible dans l'Iphone...
avatar Mayorkam | 
Et il faudra voir les perfs du Pre avec trouillon d'applis lancées en même temps... ça risque de ramer sévère...
avatar Mayorkam | 
Et si elle veut juste envoyer une notification à l'écran, elle doit se connecter à Internet, Bien sûr que non Bluheim, rien n'empêchera de pouvoir lancer des alertes, comme cela est déjà le cas qujourd'hui dans des programmes locaux comme tu dis. Le push ne concerne que les notifications lancées à distance, et où de toute façon il te FAUT une connexion réseau. En local, tu m'expliqueras comment tu comptes recevoir , exemple bien montré lors de la conf, des résultats sportifs en temps réel. ça va être drôle ça en local...et en multitâche, ça va être bien comique de naviguer sur la page de news sportives entre deux autres applis juste our avoir le résultat. Franchement... Je crois que tu n'as pas bien saisi de quoi il est question..
avatar Billytyper2 | 
@Godzil [i]"Je n'aime pas ce genre d'articles ou l'on confond tout.. Ce n'est pas le multitache qui fait fondre la batterie, mais les connections réseaux "permanantes" ![/i] Tu es sur de comprendre le fonctionnement des matériels ? les connexions réseaux font fondre la batterie plus que les applications actives (multitaches) ? Qu'est-ce qui consomme le plus dans ce type d'appareil ? c'est le processeur et pas le controleur réseau. Faire systématiquement fonctionner le processeur à pleine charge, consomme énormément de batterie. Bien plus que le controleur réseau.
avatar laurentP | 
Les push en soi est la solution pour les opérateurs mobile pour "préserver" la ressource radio qui est rare!!! Il est impossible actuellement de proposer pour les terminaux mobiles des connections ouvertes en permanence, pour tous les utilisateurs!! C'est ici que le push intervient, l'utilisateur ne recherche pas les "informations" sur internet, mais ces informations viennent à lui, lorsqu'elles sont disponibles! La philosophie est totalement différente des réseaux filaires comme on a tous, où la connexion est permanente. En effet, en filaire, on ne réserve pas de bande passante à l'utilisateur. En téléphonie c'est bien différent, dans la norme 3G, ou W-CDMA pour les intimes, ( Wideband Code Division Multiple Access), comme son nom l'indique c'est un acces large bande à division de code multiple, c'est à dire que temporellement, les données sont codées et émises dans un time-slot qui est alloué a chaque utilisateur connecté. Ces time-slot sont en nombre fixe par largeur de bande. Ce nombre de timeslots disponibles nous donne le nombre d'utilisateurs maximum connectés par bande. En WCDMA, on procède également à un étalement de spectre pour éviter les perturbations liées aux interférences. En résumé, il faut arrêter de raisonner comme des avaleurs d'internet mais plutot comme l'opérateur téléphonique qui nous vend l'accès. La réssource radio étant rare et limitée par antenne, il est normal qu'un fabriquant tel qu'apple qui met en place des mécanismes destinés a préserver cette ressource radio telle que le Push soient les bienvenus et accueillis à bras ouverts. Moins de connections 3G = plus de place pour la voix = QoS meilleur et disponibilité meilleure!! Donc pour l'instant en promouvant le Push, apple entend séduire au mieux les opérateurs, en proposant une gamme de produit "intelligente" Je dis donc haut et fort: VIVE LE PUSH!!!!
avatar Mayorkam | 
En tout cas on voit que le bashage de l'Iphone s'est déplacé du copier/coller vers le multitâche à la Pre... Je supposes que lors de la V4 on trouvera encore quelque chose. En revanche, question critique sur les concurrents, on regarde moins les détails...
avatar Billytyper2 | 
@Blueheim Tu ne t'en rend pas compte de ce que tu dis. Le principe du push c'est justement d'avoir un petit "daemon" qui tourne, qui reste à l'écoute de l'arrivée d'une notification des serveurs Apple. Il dispatch ensuite vers l'application concernée. Chaque appli est identifiable. Donc UN DAEMON pour toutes les applis... voilà comment on économise la consommation.
avatar Tiberius | 
Je suis entièrement d'accord avec Godzil : - L'iPhone OS supporte le multi-tâches, - Mais les développeurs tiers n'ont pas le droit de laisser tourner leur application en tâche de fond, - Ce sont surtout les connexions permanentes qui pompent la batterie. La multiplication des messageries instantanées et autres bidules à messages multiplierait les connexions permanentes à des serveurs distants, et donc le maintien de plusieurs connexions. La solution d'Apple n'est pas parfaite, mais elle permet de n'avoir qu'une seule connexion, et Apple a certainement optimisé son programme pour que ça économise la batterie. Concernant le multi-tâches entre applications : - Apple dit qu'avoir un gestionnaire de tâches visible par l'utilisateur (qui pourrait choisir quelle application fermer etc.) n'est pas bon. Ils avaient même montré un screen d'un gestionnaire de tâches tout moche sur un autre téléphone. - C'est une catastrophe pour les jeux et les applications temps-réel en général : dans l'idéal les développeurs ont besoin d'une machine dédiée. Ce n'est pas le cas sur iPhone, mais les performances sont toutefois globalement prévisibles : pas de garbage collector, toujours les même processus en tâche de fond. Les développeurs peuvent donc avoir une idée de la mémoire dont ils vont disposer, et du temps processeur dont ils disposent. - L'iPhone n'a pas assez de mémoire. Ses 128Mo de mémoire ne suffisent pas à généraliser le multi-tâches entre applications, car cela impliquerait de mettre en place un système de swap qui nuirait aux performances et à l'autonomie. Je pense qu'Apple va attendre un prochain iPhone (multi-coeur ?, plus de mémoire) pour autoriser le multi-tâches. Je suis certain qu'il sera de toute façon très réglementé. Leur solution du Push pour les messageries instantanées et les communications avec des serveurs distants est assez bonne. En effet, ça permet d'être prévenu au bon moment de l'arrivée des messages. Une solution Pull impliquerait que l'iPhone demande régulièrement (ou manuellement) s'il y a des nouveaux messages, ce qui multiplie les messages inutiles et ne permet pas la réception en temps réel des messages. Le principal problème pour les développeurs c'est l'absence totale de communications entre les applications (et leurs données) : impossible d'accéder directement aux musiques, aux photos, aux vidéo, etc. C'est vraiment ridicule. Par exemple pour les photos, on est obligé de passer par le Photo Picker d'Apple (un écran avec une mosaïque de photos. L'utilisateur en choisit une, et on peut l'avoir dans notre application). J'aimerais donc qu'Apple revoit sa copie sur la communication entre les applications, et sur la protection des données de chaque application. Créer une zone commune à toutes les applications serait déjà un bon début pour permettre le partage de données avec différents logiciels tiers.
avatar Billytyper2 | 
@pwetpwet De deux choses l'une, ton calendrier sur l'iphone contient déjà le planning des rendezvous. Il n'a donc pas besoin de connexion pour t'alerter. Mais s'il y a un nouveau rendezvous planifier sur le serveur. Tu es bien obligé de te connecter sur le net non ? Avec ou sans push. Donc ça revient au même. L'explication de Florent ci-dessus est limpide
avatar Tiberius | 
@ pwetpwet : La solution d'Apple n'est pas démesurée : Elle convient aux applications qui ont besoin d'être notifiées par un serveur distant. Si des développeurs sont assez bêtes pour utiliser ce système de notifications à d'autres fins, ce sera LEUR solution qui sera démesurée et ridicule. Apple propose un service qui va déjà apporter de nouvelles possibilités. Ca ne règle pas tout, mais c'est déjà pas mal. Les développeurs devront faire attention à ne pas utiliser les notifications Push d'Apple à mauvais escient.
avatar Titov | 
Je ne comprend pas le procès qui est fait à la notification dans cet article, notamment concernant l'exemple Twitter. Pour avoir vu (et revu) la dernière conférence, personne n'a dit qu'une notification faisait vibrer le téléphone comme un SMS, non ?
avatar Mayorkam | 
Désolé bluheim j'ai dit plein de bêtises. :( Tu as raison.
avatar Mayorkam | 
Salut c'est shenmue et je suis une pleureuse/
avatar laurentP | 
Bluheim tu dis qd meme un peu de conneries parcequ'on travaille de plus en plus sur des technologies de bureaux distants, en place dans des fermes de serveur. Je te passerai les détails de la technologie, et ce qui va avec mais sache qd meme, que l'avenir n'est pas dans le terminal. D'ailleurs, le terminal tend a devenir quelque chose de standard, meme si le marché propose de plus en plus de modèles différents. Le monde des telecoms, c'est pas un monde de guignols, c'est un monde de pognon! On a est pas passé a la 3G pour faire de la télé, mais pour augmenter le bitrate et les frequences d'échantillonage de la voix. Avec la 1G on etait a 13kbps... Maintenant quand t'ecoute un MP3, c'est grand minimum du 128 et encore... 192, 256 et 512 sont monnaie courante!! Maintenant faut vendre des services liés aux push, les opérateurs l'ont bien compris, ils attendent avec impatience la démocratisation de ce procédé!! je te laisse imaginer pour quoi!! Moins de BP utilisée, inscription à des services particuliers, taxés... Tu sais, on a de la chance en france d'avoir une accès 3G libre... Renseigne toi un peu sur la facon dont NTT DOCOMO (operateur Nippon, seule maitre a bord) gère les portails accessibles!!! La révolution mobile est en marche! Mais pas dans le sens que vous les présentez j'ai l'impression!!! L'avenir du mobile, c'est l'information qui vient a toi, pas toi qui va la chercher! C'est la, la valeur ajoutée!!! Si vous avez pas compris ca, alors vous etes déjà dépassés par les évènements!!!
avatar Billytyper2 | 
@Bluheim "Ha bon ? Alors comment il est censé s'y prendre, ce programme pour alerter l'utilisateur puisqu'il n'y a pas d'autre système de notification que le push de proposé aux développeurs ?" Tu es développeur, tu dois donc savoir ce que c'est qu'une "interruption logiciel". Il suffit donc d'initialiser le timer système pour déclencher une interruption à l'heure demandée. Voilà, du coup l'application n'est pas obligé dêtre active. Alors est-ce que Apple ouvre cette possibilité aux autres applications non Apple d'y accéder, c'est une autre histoire.
avatar laurentP | 
@XiliX & bluheim Plus exactement, la connection est permanante entre le client et le serveur, mais en sommeil. Pour éviter les timeout, le client envoie des "hearbeat" au serveur. Ainsi, si le client n'envoie plus de "hearbeat", il n'est plus receveur. tout betement...
avatar laurentP | 
Et bien c'est la ou le bureau virtuel entre en jeu!! Plus rien n'est stocké sur un termial, qui reste qu'un écran d'affichage!!! Tout simplement!!! Et ca, comme je te l'ai dit, on y vient!! enfin, on y est deja!! La synchronisation c'est bien beau, mais a ton avis, si MobileMe est sur le Web avec une interface chiadée, c'est justement pour que le terminal soit standard et utilisable par le plus grand nombre!! Ca réduit les couts en mémoire type flash, allège les terminaux, mais ne t'enlève rien de tes fonctionnalités!! Le terminal est limité et sert de tampon, c'est tout, il n'est pas destiné a stocker ta vie!!
avatar hpg62 | 
sans m'étendre longuement sur le sujet, je pense que cette analyse est mauvaise. d'ailleurs si vous regardiez un peu mieux les explications du push lors de la conf des dev de l'iphone 3, ca réponds a certaines de vos intérogations. ps : et s'il vous plait, arrétez de prendre les ingé apple pour des débiles mentaux
avatar laurentP | 
En maintenant une connection passive avec ton serveur qui est censé donner l'info. Pour info, je travaille actuellement sur les bureaux virtuels en fermes. Ca marche du tonnere c'est toujours au stade de dev, mais en gros, j'ai tout un linux avec un nokia E65, et toutes les applis qui vont avec. Pour souvenir, apple avait au début, décidé de délocaliser les applications sur des serveurs web applicatifs, c'etait pas si con, d'ailleurs, je suis prêt a parier que d'une facon ou d'une autre on va y revenir!!! L'avantage de ce genre de développement, c'est que la compatibilité est assurée avec tous les terminaux!! donc l'avenir est à l'application web!! Ca c'est sur l'avenir est également au bureau virtuel PS: pour ton histoire de calendrier, c'est un mauvais exemple. Tu pourrais inventer un protocole propriétaire, qui va contacter via le réseau téléphonique opérateur ton terminal mobile, via la forme de message de service, (pas confondre avec sms). C'est une solution d'ailleurs, cela ne m'étonnerait pas que le push se standardise dans ce sens, vu que l'opérateur peut envoyer en bloc une info à tous ces clients (comme le #123# chez orange pour le suivi conso) C'est peu utilisé en france, mais beaucoup plus dans des pays comme l'allemagne..
avatar laurentP | 
Autre réaction Si tu as une ressource qui est située sur le Web, tu as 2 méthodes pour la récupérer, PUSH ou PULL c'est un peu la meme chose que HTTP GET, et HTTP POST Bref tu m'as compris. Sinon une simple application client serveur avec un client sur le terminal et le serveur tournant en JBoss ou autre avec une appli web java bien chiadée. Ou bine avec du RMI ou CORBA pour travailler en objets distribués..; mais la bon courage!!
avatar sputnic | 
@ Blueheim Arrête de jouer les crétins. Tu comprends pas qu'il y a un système de notifiaction qui fonctionne comme un CRON que tu programmes. Un démon qui est au courant qu'il doit te prévenir à tel jour telle heure et qui déclenche le système de notification qui, soit modifie le compteur de l'icone de l'appli, soit te fait apparaître un message, soit te fait vibrer, mais en aucun cas n'a besoin d'ouvrir l'app. C'est exactement ce qui se passe sur ical sur ton Mac quand il déclenche une alarme. Ical n'a pas besoin d'être lancé pour que ton Mac déclenche ton alarme. Il en est de même pour tes SMS, tu reçois le SMS et le systême de notifications t'affiche le message sans que tu es besoin de lancer l'app SMS. Enfin c'est le principe des interruptions qui fonctionnent depuis la nuit des temps (cf les Interrupt (IRQ 4 notamment je crois, si ma mémoire est bonne) sous Dos à l'époque qui nous donnait du fil à retordre à cette époque bénie des dieux... quoique :)
avatar Billytyper2 | 
@xx-os Enfin, quelqu'un qui s'y connait. Mais sans aller jusqu'à utiliser les interruptions matérielles, comme les IRQs, il en existe pleins au niveau système. Cron est un exemple.
avatar laurentP | 
Le push est implémenté en couche haute, donc rien a voir avec les interruptions. Du moins si t'avais fait un petit peu de programmation objets partagés, tu saurais qu'un serveur peut a tout moment modifier un objet présent en mémoire, et lever un évènement de telle facon que le client se retrouve avec cet objet nouvellement mis à jour. C'est de la programmation évènementielle. Rien de plus rien de moins. Pas besoin d'avoir un programme qui tourne en tache de fond et qui va vérifier le contenu du web pour le rapatrier. Dans le cas du push, qui veut bien dire par son nom que c'est le serveur qui envoie un évènement au client. Le client en lui même je te l'accorde est en sommeil, mais connecté avec ce dit serveur et en attente d'évènements. Donc, rien a voir avec l'interruption matérielle dont du me parle dans le cas du push. Meme pas besoin de scheduler a la limite D'ailleurs grace a ce mécanisme de push, tu peux très rapidement en Java, faire une appli de partage de fichier, ou le serveur est capable seul de mettre a jour la liste de ses fichiers partages, sans requete du client!!
avatar sputnic | 
Oui enfin c'était un clin d'oeil :) je me souviens avoir bien galéré à l'époque pour qu'un événement extérieur (sur une rs232 notamment) soit pris en compte par un programme en boucle... @ Florent : ce que tu ne comprends pas c'est que blueheim parle d'une notification locale à l'utilisateur local... par un programlme local, avec des données locales... pas besoin de push, de pull, de push-pull avec un serveur externe :). Et BlueHeim ne comprends pas que dans ce cas y a pas besoin d'avoir un serveur tiers pour ça — ou plutôt joue les crétins histoire de noyer le système de push d'apple sous les trolls. J'aimerais pas voyager avec lui, passer par NY pour aller à Marseille (from Paris...)
avatar JoTaPé | 
XiliX: merci je sais tres bien comment marche le hard, quand je vois sur une de mes carte de dev, que le cpu a fond, sans le Wifi j'ai ~300mA, et avec le Wifi je dépasse les 800mA je sais pas, mais le Wifi consome un max et participe a plus de 50% du vidage de la batterie, étrange quand meme pour un truc qui "ne consome pas" (et accesoirement le CPU ne tourne jamais a 100% en permanence)
avatar laurentP | 
@Godzil Normal!! avec les chip 3G c'est a peu près le meme délire... C'est pour ca que sur l'iphone, tu peux programmer tes connections a intervalles réguliers, genre toutes les 30 minutes... De toute façon, il faut se dire un truc, un terminal mobile c'est pas fait pour marcher en mode connecté cf TCP. Le TCP participe grandement a réduire la vitesse de téléchargement du mobile. Je vais pas vous expliquer pourquoi, mais tout ca vient de la liaison radio... Et c'est aussi vrai pour le Wifi que pour la 3G, d'ailleurs en Wifi, le controle d'erreur se fait au niveau liaison, pour eviter que TCP foute trop sa merde. Conclusion 1; TCP c'est de la merde pour la mobilité Conclusion 2; la mobilité c'est pas fait pour etre connecté tout le temps Conclusion 3:PUSH + Scheduling de la connection= moins de données qui transitent en sens montant = moins de consommation
avatar Billytyper2 | 
@godzil On est d'accord... @xx-os Ne t'inquiètes j'ai bien compris. Je me souviens à l'époque où il n'y avait pas encore des IDE comme aujourd'hui pour gérer la souris sur une interface graphique (DOS biensur). Quand il faut gérer les interruptions générées pas la souris, calculer les x et y, gérer la bordure des fenêtres (controles) pour savoir ce qu'il faut interpreter lorsqu'on clique sur un objet... bref.. ( celui qui dit que je suis vieux... :p ) @florent Non effectivement ça n'a rien avoir avec le push. Je suis 100% d'accord avec toi à ce propos. C'était pour répondre à bluheim à propos du déclenchement de l'alerte dans un logiciel type iCal en local. On peut par exemple configurer une alarme qui doit se déclencher à 18h00 par exemple. Dans ce cas, on peut très bien initialiser une sorte d'interruption système, qui initialise le timer système afin de générer une notification (pas un push) à l'heure demandée.
avatar sputnic | 
@ XiliX "( celui qui dit que je suis vieux... :p )" idem for me :)) "...afin de générer une notification (pas un push) à l'heure demandée" Voilà, on est bien d'accord et c'est ce que Blueheim a du mal à comprendre — c'est pourtant ce qui se passe depuis toujours sur toutes nos machines (mac, iphone, pc etc.)

CONNEXION UTILISATEUR