[jdev] XMPP on Android, Round #2

[Stephen Pendleton]

-----Original Message-----
From: jdev-bounces at jabber.org [mailto:jdev-bounces at jabber.org] On Behalf Of
Rene Treffer
Sent: Tuesday, November 02, 2010 4:09 PM
To: jdev at jabber.org
Subject: Re: [jdev] XMPP on Android, Round #2

On 11/01/2010 10:14 PM, Stephen Pendleton wrote:
>
> -----Original Message-----
> From: jdev-bounces at jabber.org [mailto:jdev-bounces at jabber.org] On Behalf
Of Yann Leboulanger
> Sent: Monday, November 01, 2010 4:27 PM
> To: jdev at jabber.org
> 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!