[jdev] XMPP on Android, Round #2

[Rene Treffer]

On 11/02/2010 10:24 PM, Stephen Pendleton wrote:
>
> -----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.

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: JDev-unsubscribe at jabber.org
> _______________________________________________
>