Push et appli

[Fluckysan]

Bonjour,

Je vais créer une application qui utilise les notification par Push et j'aimerais savoir si vous connaissez des solutions

J'ai trouvé Xtify

Qu'en pensez-vous et avez-vous d'autres pistes ?

Merci

[Profete162]

Ca semble intéressant, je vais suivre ce topic de près...

Désolé pour ce message qui n'apporte pas de nouvelles infos, mais tu as eu une bonne idée de créer ce fil!

[Alocaly]

Xtify...

Ils ont spammé mon blog de facons un peu trop limite ( "je suis d'accord avec ton avec ton article... Tu connais Xtify")

https://www.blogger.com/comment.g?blogID=7565989862281145057&postID=6774525494072230011&pli=1

Enfin...

C'est peut-etre bien quand meme :)

[FreakDev]

sur le principe ça semble pas mal...

problème, qui n'en ai pas forcément un... enfin c'est une question de point de vue :

d'après ce que j'ai compris, ça ouvre une connexion XMPP, c'est pas pire que la connexion google talks... enfin ça aide pas la batterie, mais bon... je vois de toute façon pas trop comment C possible autrement... c'est le revers de la médaille

[naholyr]

J'aurais un peu peur de la quantité de données qui transitent dans ces situations... Et c'est du vrai push (connexions persistante entre le client et le serveur) ou c'est leur service qui va faire un check toutes les X secondes et te bouffe ta batterie ?

[Fluckysan]

Justement je ne sais pas :)

D'après leur doc : http://developer.xtify.com/integration-steps

Il y a un service ainsi qu'un provider, ça a l'air d'être du vrai push

Je prenais Xtify parce que c'est le premier que j'ai trouvé mais si vous en avez d'autre, je suis preneur

[naholyr]

Ben en fait jusqu'à présent à chaque fois que je me suis posé la question du push, je me suis rendu compte que je n'en avais pas besoin. Peut-être que toi non plus ? ^^ Quel est ton cahier des charges ?

[Fluckysan]

Hum nop mon appli ne peut pas fonctionner sans Push (c'est le coeur) :p

Et il est intéressant de trouver une solution pour !

[dekans]

XMPP permet de faire du push il me semble.

Et c'est libre ça.

[Pierre87]

cool, ça va etre utile pour mon appli !

[Alocaly]

Hum... question bete de novice, mais c'est quoi la différence entre du push et des connexions toutes les X secondes ?

Hum... j'imagine que ca veut dire qu'on essaye de garder une connexion alive entre les deux points ?

Mais comment on fait quand on passe sous un tunnel, qu'on récupère du Wifi, ou que sais-je encore ?

...

Autre question : XMPP c'est basé sur du TCP, ou c'est un protocol completement à part ?

Emmanuel / Alocaly

[Fluckysan]

Dans le push c'est le serveur qui contacte le mobile lorsqu'il a une nouvelle notification pour lui

La connexion toute les x secondes, c'est le mobile qui check s'il y a du nouveau

Je pense qu'il y a un service qui tourne sur le mobile pour le push (c'est du moins la façon de faire de Xtify)

Je ne connais assez XMPP pour répondre à ta 2ème question :)

[Profete162]

Pour moi, je pense que c'est l'avenir de trouver une solution uniformisée...

Mes connaissances en informatique / programmation ne sont pas assez élevées pour savoir si il est possible d'imaginer un maxi serveur qui gere toutes les connexions/notifications en une seule fois.

Pour l'instant, mon mobile crée 10.000 connexions vers la météo, les mails, les messages, le RSS, les applis et ca bouffe de la batterie.

J'imagine u serveur gérant cela et renvoyant les infos seulement quand il y a besoin, ca serait la révolution des smartphones!

Peut-etre suis-je rêveur aussi.

[neoakira]

hum, très interressant si XMPP permet de faire du push :)

quelqu'un a un exemple simple ?

enfin j'espere qu'une connexion reste pas ouverte indéfiniment entre le serveur et le client...

[naholyr]

enfin j'espere qu'une connexion reste pas ouverte indéfiniment entre le serveur et le client...

Si, c'est le principe même du push en même temps...

[neoakira]

donc il y a moyen que ça bouffe rapidement la batterie...

[Pierre87]

il faudrait qu'un téléphone soit toujours en mode "listen"

et accessible depuis l'extérieur via une adresse IP fixe (ipv6 lol ?)

pas de connexion établie en permanence,

mais la possibilité d'avoir un message en temps réel

[naholyr]

La notion d'ip fixe pour un téléphone me semble totalement science-fictionnelle pour l'instant :P

Par contre il y a une chose qui marche en push sur tous les téléphones, sans besoin de connexion supplémentaires : les appels téléphoniques et les SMS. Le vrai push se baserait sur le protocole SMS, mais là il faudrait déployer des moyens qu'on n'a pas.

[Alocaly]

Dans le push c'est le serveur qui contacte le mobile lorsqu'il a une nouvelle notification pour lui

La connexion toute les x secondes, c'est le mobile qui check s'il y a du nouveau

Ok, donc il faut une socket ouverte, et le mobile qui écoute en permanence dessus pour savoir si quelqu'un l'appelle.

Du coup, je ne comprends pas trop pourquoi ca bouffe moins la batterie qu'une connexion toutes les X minutes ( surtout si X est grand - voire parametrable par l'utilisateur ou en fonction d'autres parametres - !! )

@naholyr :

C'est marrant ce que tu dis sur les SMS, quand j'avais posé ma question l'autre jour, j'étais finalement tombé sur ce lien :

http://www.slideshare.net/StefanAlund/an-early-look-at-droidpush-api-a-push-api-for-android

Que j'avais hésité à poster ici.

Puis je ne l'avais pas fait en me disant : ben non, ce sont des SMS, ca ne doit pas interesser grand monde :)

Emmanuel / Alocaly

[Fluckysan]

@Profete : c'est ce que fait un peu Apple :)

Apple propose son serveur Push et le gère ===> tu inscris ton appli comme utilisatrice du Push et tu informes leur serveur que tu as du nouveau pour ton appli

Du coup toutes les appli Apple qui utilise du Push passe par cette même voie ===> il y a uniformisation donc économie de batterie

L'idée d'un serveur géant qui uniformiserait tous le Push est une très bonne idée :)

@Alocaly : La première partie de ton slide explique l'économie de batterie entre le poll et le push

Apparemment dans le poll le mobile doit envoyer / recevoir pas mal de données à chaque check, dans le push il est en relation constante mais ce n'est pas lui qui travaille mais le serveur qui lui dit s'il y a du nouveau, du coup il y a moins d'échange de données (c'est cet échange qui bouffe la batterie)

Une connexions toutes les X minutes bouffera peut-être moins de batterie si c'est un grand intervalle mais tu n'auras plus le côté instantanné (et il faut voir à partir de combien de temps c'est plus rentable)

[Alocaly]

"L'android Cloud To Device Messenging"

Qui vient de sortir du chapeau de google, c'est pas ce qu'on voulait ici ?

Un moyen pour une appli d'envoyer des infos sur le tél ?

J'ai pas encore tout compris comment ca marhcait, mais ca a l'air bien !!!

Emmanuel / Alocaly

[Pierre87]

Yep

[Fluckysan]

Ca y ressemble fortement, ce qui m'inquiète c'est la liaison avec l'identification compte Google et l'API qui pourrait être privé :s

De plus, l'Android Cloud to Device Remote ne sera disponible qu'à partir de 2.2 :o

It requires devices running Android 2.2 or higher that also have the Market application installed. However, you are not limited to deploying your applications through Market.

It uses an existing connection for Google services. This requires users to set up their Google account on their mobile devices.

Mais c'est bien du push :

An application on an Android device doesn’t need to be running to receive messages. The system will wake up the application via Intent broadcast when the the message arrives, as long as the application is set up with the proper broadcast receiver and permissions.

En gros :

• Votre serveur envoie une notification aux serveurs Google C2DM indiquant qu'il a des nouvelles données pour un device (chaque device est associé à un ID)
  
• Le serveur envoie les données en push au device (ou les garde en mémoire si le device n'est pas actif jusqu'à ce qu'il le soit)
  
• Le device reçoit la notification push via un receiver (voir la doc) et réveille l'appli visée via un intent
  

Je vous conseille de lire la doc, ça explique bp de chose : http://code.google.com/intl/fr-FR/android/c2dm/

C'est un bon système, il semble que le service qui s'occupera d'écouter les notifications sera installé dans l'application market (Google précise bien qu'il faut que le market soit installé sur le device)

Le gros désavantage c'est que le mobile doit être configuré avec un compte Google et que le market soit installé :/

[naholyr]

Le gros désavantage c'est que le mobile doit être configuré avec un compte Google et que le market soit installé :/

En même temps, pour faire du push via les serveurs Google, il me semble normal que le pré-requis soit d'avoir les API Google et un compte actif sur le téléphone :)

De toute façon, aujourd'hui aucun smartphone Android n'a la version "nue" d'Android, à part les tablettes mais ça finira par changer.

[Fluckysan]

C'est exact mais c'est pour chipoter :)

Apple le fait déjà pour le push, il faut passer par leur serveur

C'est quand même dommage qu'il faille avoir Android 2.2, ça limite bp ! Quand on sait que 34% (je crois que c'est à peu près ça) des utilisateurs d'Android sont encore en 1.5, le C2DM sera une solution pour plus tard :o