Re: [aerogear-dev] Android PushConfig

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