[aerogear-dev] Android PushConfig

Matthias Wessendorf matzew at apache.org
Mon Jun 24 09:15:40 EDT 2013


On Thu, Jun 13, 2013 at 9:34 PM, Matthias Wessendorf <matzew at apache.org>wrote:

>
>
>
> 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 ?
>


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



-- 
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/20130624/bf546bc0/attachment-0001.html 


More information about the aerogear-dev mailing list