10:59 a.m.
So with GCM and Android, Google may decide to update the devices token.
The device will receive a Intent saying that the token has changed and
it needs to eventually update the remote server's data before the token
expires.
Right now the application checks the device id on startup and
reregisters if there is a change. If the user doesn't interact with the
applicaiton for a long period of time and the device token changes he
will eventually stop receiving messages.
Ideally, I would think that handling this as soon as the intent comes in
would be great. However, how should failures to reregister be handled?
My easy answer is Log and retry with exponential backoff (and maybe send
a error message).
WDYT?
7:15 a.m.
I was thinking about it. That would be the responsibility of the library or
application?
Btw, any thoughts?
On Tue, Aug 27, 2013 at 12:59 PM, Summers Pittman <supittma(a)redhat.com>wrote:
So with GCM and Android, Google may decide to update the devices
token.
The device will receive a Intent saying that the token has changed and
it needs to eventually update the remote server's data before the token
expires.
Right now the application checks the device id on startup and
reregisters if there is a change. If the user doesn't interact with the
applicaiton for a long period of time and the device token changes he
will eventually stop receiving messages.
Ideally, I would think that handling this as soon as the intent comes in
would be great. However, how should failures to reregister be handled?
My easy answer is Log and retry with exponential backoff (and maybe send
a error message).
WDYT?
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
7:35 a.m.
On Tue, Sep 17, 2013 at 2:15 PM, Daniel Passos <daniel(a)passos.me> wrote:
I was thinking about it. That would be the responsibility of the
library or
application?
I think the lib should give an error msg, and do the log (+retry).
The app should be able, I think, to responsed to that error msg
Btw, any thoughts?
On Tue, Aug 27, 2013 at 12:59 PM, Summers Pittman <supittma(a)redhat.com>wrote:
> So with GCM and Android, Google may decide to update the devices token.
> The device will receive a Intent saying that the token has changed and
> it needs to eventually update the remote server's data before the token
> expires.
>
> Right now the application checks the device id on startup and
> reregisters if there is a change. If the user doesn't interact with the
> applicaiton for a long period of time and the device token changes he
> will eventually stop receiving messages.
>
> Ideally, I would think that handling this as soon as the intent comes in
> would be great. However, how should failures to reregister be handled?
> My easy answer is Log and retry with exponential backoff (and maybe send
> a error message).
>
> WDYT?
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
8:29 a.m.
On 09/17/2013 08:15 AM, Daniel Passos wrote:
I was thinking about it. That would be the responsibility of the
library or application?
Btw, any thoughts?
Well I marked it as won't fix because this factoid
doesn't appear in any
of Google's docs any more. I am going to assume since they don't
mention it anywhere anymore that it isn't necessary anymore.
On Tue, Aug 27, 2013 at 12:59 PM, Summers Pittman <supittma(a)redhat.com
<mailto:supittma@redhat.com>> wrote:
So with GCM and Android, Google may decide to update the devices
token.
The device will receive a Intent saying that the token has changed and
it needs to eventually update the remote server's data before the
token
expires.
Right now the application checks the device id on startup and
reregisters if there is a change. If the user doesn't interact
with the
applicaiton for a long period of time and the device token changes he
will eventually stop receiving messages.
Ideally, I would think that handling this as soon as the intent
comes in
would be great. However, how should failures to reregister be
handled?
My easy answer is Log and retry with exponential backoff (and
maybe send
a error message).
WDYT?
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
3870
days inactive
3892
days old
4 comments
4 participants
participants (4)
-
Bruno Oliveira -
Daniel Passos -
Matthias Wessendorf -
Summers Pittman