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

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 ? 

 



 

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


_______________________________________________
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