[aerogear-dev] Android PushConfig

Tue Jun 25 08:30:31 EDT 2013

Ah,  very nice!

On Tue, Jun 25, 2013 at 2:21 PM, Daniel Passos <daniel at passos.me> wrote:

> 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
>>
>
>
> _______________________________________________
> 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/20130625/0deb64ff/attachment-0001.html 