[aerogear-dev] Android PushConfig

Summers Pittman supittma at redhat.com
Thu Jun 13 15:19:26 EDT 2013


On 06/13/2013 03:11 PM, Matthias Wessendorf wrote:
> Hello,
>
> awesome!
>
>
> On Thu, Jun 13, 2013 at 8:37 PM, Summers Pittman <supittma at redhat.com 
> <mailto:supittma at 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?
Correct
> Similar, the 'failure' is invoked when PushEE returns any error code 
> (e.g. no connection, or 404 or what ever), right ?
Correct
>
>
> 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!

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. Google 
posted a bucket of sample code for how to do this.

>
>
>
>     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/GCMBaseIntentService.html#GCMBaseIntentService(java.lang.String.. 
> <http://developer.android.com/reference/com/google/android/gcm/GCMBaseIntentService.html#GCMBaseIntentService%28java.lang.String..>.)
>
> 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).  As a note, 
GCMBaseIntentService is deprecated.  All of the Google messaging is now 
done via consuming a broadcast intent.
>
>
>
>     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 at lists.jboss.org <mailto:aerogear-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130613/d282c478/attachment.html 


More information about the aerogear-dev mailing list