Ah, very nice!
On Tue, Jun 25, 2013 at 2:21 PM, Daniel Passos <daniel(a)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/aero...
[2]
https://github.com/aerogear/aerogear-android/blob/push/src/org/jboss/aero...
On Mon, Jun 24, 2013 at 10:15 AM, Matthias Wessendorf <matzew(a)apache.org>wrote:
>
>
>
> On Thu, Jun 13, 2013 at 9:34 PM, Matthias Wessendorf <matzew(a)apache.org>wrote:
>
>>
>>
>>
>> On Thu, Jun 13, 2013 at 9:19 PM, Summers Pittman
<supittma(a)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(a)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-j...
>>
>> 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/GCMBaseInte....
>>> .)
>>>
>>> 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(a)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@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev