-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Rene Treffer Sent: Tuesday, November 02, 2010 4:09 PM To: [email protected] Subject: Re: [jdev] XMPP on Android, Round #2
On 11/01/2010 10:14 PM, Stephen Pendleton wrote: > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Yann Leboulanger > Sent: Monday, November 01, 2010 4:27 PM > To: [email protected] > Subject: Re: [jdev] XMPP on Android, Round #2 > >> Couldn't Stream managment help for that? >> http://xmpp.org/extensions/xep-0198.html > Yes, that would also be used in the cloud push scheme to resume the stream. The cloud push scheme allows it to work without having to establish a secondary XMPP polling connection. My feeling is that the approaches are practically the same but using Google's push would use the existing Android connection to the cloud service. Either way support for the asmack service to be notified of a wake-up-and-resume-session event would be needed. >But this would mean I'm doing a feature negotiation run to fetch the >queued stanzas, as XEP-0198 reserves throttling for servers: >So, if I get you right, I should kill the XMPP TCP connection to wait >for events on another idle TCP connection and then restart the XMPP connection. Basically exchanging an idle secondary connection for a full negotiation every now and then? >Could you please explain how this could save battery? Am I missing >something? There are a few issues here. The first is that the idle XMPP connection is not idle if you have XMPP contacts. You are typically receiving many events that you don't (or may not) care about while the XMPP client is in the background such as presence, pubsub events, etc. Another issue is on mobile devices you may lose connection to the XMPP server semi-frequently as the devices moves about which will require full XMPP stream reconnection. Most importantly I am assuming you are implementing a partial "wake lock" on the Android device which prevents the device from sleeping and killing your active TCP connection. So the approach would be to remove the wake lock and allow the device to sleep until the next poll/push time which would be used to determine if an interesting stanza (message, etc) is available on the server. If the poll/push results indicate that a XMPP connection is required you would use stream management features to reconnect the stream. Let me know if I can help! _______________________________________________ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [email protected] _______________________________________________
