[aerogear-dev] Android PushConfig

[Matthias Wessendorf]

On Thu, Jun 13, 2013 at 9:19 PM, Summers Pittman <supittma at redhat.com>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 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
>
>

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-java-L7

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/GCMBaseIntentService.html#GCMBaseIntentService(java.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).
>

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 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 listaerogear-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130613/b9686e8c/attachment-0001.html