here is, including device registration:

https://github.com/matzew/ag-unified-push-api/blob/master/src/test/java/org/jboss/aerogear/push/UnifiedPushManagerTest.java#L41-L81

All hammered in java... since this is a test - most of the code will be executed, when interacting with HTTP endpoints of the thing;

Yes, there is no JS application in the test - but we do have an abstraction interface for it:
https://github.com/matzew/ag-unified-push-api/blob/master/src/main/java/org/jboss/aerogear/push/application/ConnectedJavaScriptApplication.java

Connected? Since only "online" JS clients are receiving message - there no real "push to device" for the JS world...

-Matthias

On Thu, Mar 14, 2013 at 3:41 PM, Matthias Wessendorf <matzew@apache.org> wrote:
Pushed FIRST/TEST impl + actually test case.....

https://github.com/matzew/ag-unified-push-api

YEs.... I have 'xxx'd out the KEY and certs :) 


On Thu, Mar 14, 2013 at 11:04 AM, Matthias Wessendorf <matzew@apache.org> wrote:
My UNIT test looks (currently) like:




-M




On Wed, Mar 13, 2013 at 11:03 PM, Matthias Wessendorf <matzew@apache.org> wrote:


On Wed, Mar 13, 2013 at 10:06 PM, tech4j@gmail.com <tech4j@gmail.com> wrote:
I think this is look really good!

Here some thoughts, and/or possible additional use-cases

* How do we want to handle multiple devices for one user?

Instance of 'MobileApplicationInstance'; each device has (per app) a different token;
What the apps do themselves, with multiple installs is something different.

Twitter, for instance, sends the push-messages to EVERY device - but that's app specific sync
(yes, i wish there was something like IMAP, for twitter)

 

* How do we want to handle the other side of unified push (non-native)?
** Might just not be there yet, but want to make sure we're still thinking the same thing :-)
** Would there be an additional abstraction above this for that?

some sub type of 'MobileApplication' can/will cover that "mobile web" (JS client) side:
 

* I'm assuming there is no good way for apps to notify you when they are uninstalled?
** As a way of removing clutter in our tables.

So, on a scheduled base they can be remove;

Google has similar API (on their MulticastResult (returned by the sender))
 

* Push filtering - I would think IDM would be very good here. 
** Sending to roles, groups, etc...

have different users (==roles), but not spec'd out
 
** When we store the device and app info what sub-system are you thinking?
*** I know you were using mongo for some of the prototyping
*** Would be possible to abstract to the IDM?

yes, it should be possible (desirable) to use IDM - but does not really matter


Thanks for the feedback!!!

-Matthias

 

On Wed, Mar 13, 2013 at 12:58 PM, Douglas Campos <qmx@qmx.me> wrote:

On 13/03/2013, at 10:28, Matthias Wessendorf <matzew@apache.org> wrote:

> ome more APIs, for some basic (initial) functionality:
>
> https://gist.github.com/matzew/c5fbc23bc97dfead46e1

I like the current form, but I'm sure we'll get asked about more OO(ish) APIs, like device.send(Message) - is this on the plans?

> User/Dev enrollment can be addressed by (hopefully) reusing the ag-security.

+1

-- qmx


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
blog: http://in.relation.to/Bloggers/Jay

_______________________________________________
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



--
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