On 06/13/2013 03:11 PM, Matthias Wessendorf wrote:

Hello,

awesome!

On Thu, Jun 13, 2013 at 8:37 PM, Summers Pittman <supittma@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

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!

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. Google posted a bucket of sample code for how to do this.

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). As a note, GCMBaseIntentService is deprecated. All of the Google messaging is now done via consuming a broadcast intent.

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@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 list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev