[aerogear-dev] Android PushConfig

Daniel Passos daniel at passos.me
Tue Jun 25 08:21:41 EDT 2013 

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/aerogear/android/unifiedpush/AGPushMessageReceiver.java
[2]
https://github.com/aerogear/aerogear-android/blob/push/src/org/jboss/aerogear/android/unifiedpush/MessageHandler.java


On Mon, Jun 24, 2013 at 10:15 AM, Matthias Wessendorf <matzew at apache.org>wrote:

>
>
>
> 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
>
> _______________________________________________
> 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/20130625/24d3cc4e/attachment-0001.html

More information about the aerogear-dev mailing list