The use case the docs present is as follows: It is so the client can know it has missed data and needs to do a full resync.On 07/23/2013 10:31 AM, Matthias Wessendorf wrote:
On Tue, Jul 23, 2013 at 4:19 PM, Summers Pittman <supittma@redhat.com> wrote:
Not exactly. These are handlers for status messages from GCM. onDeleteMessage is sent to the client when a notification has been removed from the server. This can be because they notifications are being batched for instance.On 07/23/2013 05:17 AM, Matthias Wessendorf wrote:
Hello,
I have a few question on the 'push' branch:
1) going over the MessageHandler interface ([1]), am I right that the "onError()" and "onDeleteMessage()" methods are only relevant for the "device to cloud" case ?
See the GcmBroadcastReceiver sample code for details: https://developer.android.com/google/gcm/gs.html
And the javadocs:https://developer.android.com/reference/com/google/android/gms/gcm/GoogleCloudMessaging.html#MESSAGE_TYPE_DELETED
I have seen the doc and read them, while adding JavaDoc to our interface :-)
I think I was just wondering why would a client get a notification, that a msg has been deleted, that he hasn't been receiving.
I think our code should be able to support / route all three message types that GCM may send.
I think it would make more sense, if I get such a notification, when I (the client) was actually sending the message :)
As far as the error message handler goes, the docs aren't explicit, but I think I misread it and you are correct. It is a callback for when an error on the server happens receiving a message from the client.
I was wondering if we really need onError than... :-)
+1 to a rename.
2) I know it's early work, but I was wondering if we should (later) rename the 'AGPushMessageReceiver' class ([2]).
I like this one.Not sure on a better name, but the AG prefix seems a little odd :) Perhaps:* PushMessageReceiver* AeroGearPushMessageReceiver* GCMMessageReceiver (since this is really "only" GCM based push messaging)* AeroGearGCMMessageReceiver
cool - will create a (future) JIRA for that
If folks agree on a later rename, I'd create a JIRA to track this ;-)
Greetings,Matthias
_______________________________________________ aerogear-dev mailing list aerogear-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev@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
_______________________________________________ aerogear-dev mailing list aerogear-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev