On 11/02/2010 10:24 PM, Stephen Pendleton wrote: > > -----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.
1. http://developer.android.com/reference/android/os/PowerManager.html - I can't find the wake lock for GSM, might be due to the different hardware chip with it's own radio firmware. 2. How do you get *less* pushes/pulls if stanzas cause push notifies. I don't get that one, either. 3. Semi-frequently is still better than for-nearly-every-stanza. You are asking to keep the connection short lived? I don't expect the stanza/reconnect ratio to improve due to that. And there is no stanza reduction due to the system. I don't get how your suggestion is going to improve the situation as you still wake the network and cpu at the same rate. > 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! Yep, answers, and numbers please :-) I'll have to add more statistics for that. That's 100% clear. Regards, Rene Treffer > > _______________________________________________ > JDev mailing list > Forum: http://www.jabberforum.org/forumdisplay.php?f=20 > Info: http://mail.jabber.org/mailman/listinfo/jdev > Unsubscribe: [email protected] > _______________________________________________ > _______________________________________________ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [email protected] _______________________________________________
