Hello, awesome! On Thu, Jun 13, 2013 at 8:37 PM, Summers Pittman <supittma(a)redhat.com <mailto:supittma@redhat.com>> wrote: Good News everyone! We have code which registers Android devices to receive messages from pushee. It is still very VERY limited, but code which will display a notification when the app receives a message looks like this: https://gist.github.com/secondsun/242063868b09db030331 the Callback (on r.register()), is success invoked, when PushEE returns HTTP Status 20x (for successful REGISTRATION of the device (aka "MobileVariantInstance"), right?

Similar, the 'failure' is invoked when PushEE returns any error code (e.g. no connection, or 404 or what ever), right ?

BTW. is the PushConfig "magically" receiving the regId, from the Intent's onRegistered()?

One of the reservations I've heard is whether or not the PushConfig object should only have the data sent to pushee in it and put other configuration elsewhere or if it should be the generic push configuration object and let AG pick out what it needs to send to pushee. I am fine, if the ctor accepts the RegistrationId, if it is clear (e.g. in document, or where else), that it used the intent, like here: http://developer.android.com/reference/com/google/android/gcm/GCMBaseInte.... <http://developer.android.com/reference/com/google/android/gcm/GCMBaseInte...>.) and _not_ being submitted to the UnifiedPush, when storing the "metadata". (could be confusing, e.g. when looking at the HTTP /device/register endpoint description - but I may be wrong)

By unifying into a single config object we make the code simpler/more approachable. However if we slice it up a bit more finely we can decouple pushee support from GCM if we want to have an AOSP flavor of push messaging in the future. Not sure... (iOS SDK in mind): Perhaps it's good to keep "PushConfig" for the PushEE-Metadata. That allows us to keep the SenderID for a (later) Convenience Intent? Not sure... mostly thinking out loud wdyt? PS and by pushee I mean aerogear-unified-push-server. _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org <mailto: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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Thu, Jun 13, 2013 at 9:19 PM, Summers Pittman <supittma(a)redhat.com&gt;wrote: > On 06/13/2013 03:11 PM, Matthias Wessendorf wrote: > > Hello, > > awesome! > > > On Thu, Jun 13, 2013 at 8:37 PM, Summers Pittman <supittma(a)redhat.com&gt;wrote: > >> Good News everyone! We have code which registers Android devices to >> receive messages from pushee. >> It is still very VERY limited, but code which will display a >> notification when the app receives a message looks like this: >> >> https://gist.github.com/secondsun/242063868b09db030331 > > > the Callback (on r.register()), is success invoked, when PushEE returns > HTTP Status 20x (for successful REGISTRATION of the device (aka > "MobileVariantInstance"), right? > > Correct > > Similar, the 'failure' is invoked when PushEE returns any error code > (e.g. no connection, or 404 or what ever), right ? > > Correct > > good > > > BTW. is the PushConfig "magically" receiving the regId, from the > Intent's onRegistered()? > > Ha ha on Registered, that is so 3 weeks ago. Google trashed that API and > provided us with a new shiny one! > :-P > > The reg ID is looked up as follows: > > 1. Is there a registrationID already loaded/cached? > Yes: > Is the registration invalid (has the app been unregistered or > uninstalled or updated) > Yes: Fetch a New Id > No: Use the current Id > No: Fetch a New id > 2. Put the ID in the programs shared preferences file. > > This is done during the asycnhronous Registrar.register method. > Ah, ok - sounds good! Now, looking at: https://gist.github.com/secondsun/242063868b09db030331#file-application-j... Not sure, but would it make sense to make the setDeviceToken(), internal? Since it does not make much sense for the developer to call it anyways, since the Registrar.register() does that job. > Google posted a bucket of sample code for how to do this. > Something to read for me, tomorrow :) > > > > >> >> >> One of the reservations I've heard is whether or not the PushConfig >> object should only have the data sent to pushee in it and put other >> configuration elsewhere or if it should be the generic push >> configuration object and let AG pick out what it needs to send to pushee. >> > > I am fine, if the ctor accepts the RegistrationId, if it is clear (e.g. > in document, or where else), that it used the intent, like here: > > http://developer.android.com/reference/com/google/android/gcm/GCMBaseInte.... > .) > > and _not_ being submitted to the UnifiedPush, when storing the > "metadata". > > (could be confusing, e.g. when looking at the HTTP /device/register > endpoint description - but I may be wrong) > > The idea would be to hide as much of this from the user as possible (def > all of the registration w/ pushee stuff). > yeah, reasonable > As a note, GCMBaseIntentService is deprecated. > yup, just saw that All of the Google messaging is now done via consuming a broadcast intent. > just saw your code. So, the AGPushMessageReceiver than basically puts the received message into the "status bar", for the user - right ? Right now it puts the entire JSON string in there, right ? Any way to "look" for a certain key ?

> > > > > >> >> By unifying into a single config object we make the code simpler/more >> approachable. However if we slice it up a bit more finely we can >> decouple pushee support from GCM if we want to have an AOSP flavor of >> push messaging in the future. >> > > Not sure... (iOS SDK in mind): Perhaps it's good to keep "PushConfig" > for the PushEE-Metadata. > That allows us to keep the SenderID for a (later) Convenience Intent? Not > sure... mostly thinking out loud > > > >> >> wdyt? >> >> PS and by pushee I mean aerogear-unified-push-server. >> _______________________________________________ >> 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 > > > _______________________________________________ > aerogear-dev mailing listaerogear-dev@lists.jboss.orghttps://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

That has changed, now AGPushMessageReceiver receives the message and forwards[1] it to the registered MessageHandler[2] and the developer does what you want with this message [1] https://github.com/aerogear/aerogear-android/blob/push/src/org/jboss/aero... [2] https://github.com/aerogear/aerogear-android/blob/push/src/org/jboss/aero... On Mon, Jun 24, 2013 at 10:15 AM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: > > > > On Thu, Jun 13, 2013 at 9:34 PM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: > >> >> >> >> On Thu, Jun 13, 2013 at 9:19 PM, Summers Pittman <supittma(a)redhat.com&gt;wrote: >> >>> On 06/13/2013 03:11 PM, Matthias Wessendorf wrote: >>> >>> Hello, >>> >>> awesome! >>> >>> >>> On Thu, Jun 13, 2013 at 8:37 PM, Summers Pittman <supittma(a)redhat.com&gt;wrote: >>> >>>> Good News everyone! We have code which registers Android devices to >>>> receive messages from pushee. >>>> It is still very VERY limited, but code which will display a >>>> notification when the app receives a message looks like this: >>>> >>>> https://gist.github.com/secondsun/242063868b09db030331 >>> >>> >>> the Callback (on r.register()), is success invoked, when PushEE >>> returns HTTP Status 20x (for successful REGISTRATION of the device (aka >>> "MobileVariantInstance"), right? >>> >>> Correct >>> >>> Similar, the 'failure' is invoked when PushEE returns any error >>> code (e.g. no connection, or 404 or what ever), right ? >>> >>> Correct >>> >>> >> >> good >> >> >> >>> >>> >>> BTW. is the PushConfig "magically" receiving the regId, from the >>> Intent's onRegistered()? >>> >>> Ha ha on Registered, that is so 3 weeks ago. Google trashed that API >>> and provided us with a new shiny one! >>> >> >> :-P >> >> >>> >>> The reg ID is looked up as follows: >>> >>> 1. Is there a registrationID already loaded/cached? >>> Yes: >>> Is the registration invalid (has the app been unregistered >>> or uninstalled or updated) >>> Yes: Fetch a New Id >>> No: Use the current Id >>> No: Fetch a New id >>> 2. Put the ID in the programs shared preferences file. >>> >>> This is done during the asycnhronous Registrar.register method. >>> >> >> Ah, ok - sounds good! >> >> Now, looking at: >> >> https://gist.github.com/secondsun/242063868b09db030331#file-application-j... >> >> Not sure, but would it make sense to make the setDeviceToken(), >> internal? Since it does not make much sense for the developer >> to call it anyways, since the Registrar.register() does that job. >> >> >> >>> Google posted a bucket of sample code for how to do this. >>> >> >> Something to read for me, tomorrow :) >> >> >>> >>> >>> >>> >>>> >>>> >>>> One of the reservations I've heard is whether or not the PushConfig >>>> object should only have the data sent to pushee in it and put other >>>> configuration elsewhere or if it should be the generic push >>>> configuration object and let AG pick out what it needs to send to >>>> pushee. >>>> >>> >>> I am fine, if the ctor accepts the RegistrationId, if it is clear >>> (e.g. in document, or where else), that it used the intent, like here: >>> >>> http://developer.android.com/reference/com/google/android/gcm/GCMBaseInte.... >>> .) >>> >>> and _not_ being submitted to the UnifiedPush, when storing the >>> "metadata". >>> >>> (could be confusing, e.g. when looking at the HTTP /device/register >>> endpoint description - but I may be wrong) >>> >>> The idea would be to hide as much of this from the user as possible >>> (def all of the registration w/ pushee stuff). >>> >> >> yeah, reasonable >> >> >>> As a note, GCMBaseIntentService is deprecated. >>> >> >> yup, just saw that >> >> All of the Google messaging is now done via consuming a broadcast >>> intent. >>> >> >> just saw your code. >> >> >> So, the AGPushMessageReceiver than basically puts the received message >> into the "status bar", for the user - right ? >> >> Right now it puts the entire JSON string in there, right ? Any way to >> "look" for a certain key ? >> > > > I guess that's possible, right ? > > > -Matthias > > > > >> >> >> >>> >>> >>> >>> >>> >>>> >>>> By unifying into a single config object we make the code simpler/more >>>> approachable. However if we slice it up a bit more finely we can >>>> decouple pushee support from GCM if we want to have an AOSP flavor of >>>> push messaging in the future. >>>> >>> >>> Not sure... (iOS SDK in mind): Perhaps it's good to keep "PushConfig" >>> for the PushEE-Metadata. >>> That allows us to keep the SenderID for a (later) Convenience Intent? >>> Not sure... mostly thinking out loud >>> >>> >>> >>>> >>>> wdyt? >>>> >>>> PS and by pushee I mean aerogear-unified-push-server. >>>> _______________________________________________ >>>> 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 >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing listaerogear-dev@lists.jboss.orghttps://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 >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > 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