Sebi,

I don't like that the Unified Push manager is the central entry point for:
-query/finding
-sending
-registration

However, I like the concept (name) of registration - let me rename my ```UnifiedPushManager```. It will be called ```PushApplicationRegistry```;

I like the concept of the```ApplicationQuery```, but that's IMO a layer on top the pure send. At the end of the day, for the plain message delivery, it does not matter why a token/device has been chosen. It only matters that it was chosen, and it is about to receive a message.

The matching APIs - for now - are just pure model abstractions. However, having something like the `ApplicationQuery` in mind is not bad - thanks for the feedback


On Fri, Mar 15, 2013 at 11:56 AM, Matthias Wessendorf <matzew@apache.org> wrote:


On Fri, Mar 15, 2013 at 11:27 AM, Sebastien Blanc <scm.blanc@gmail.com> wrote:


On Fri, Mar 15, 2013 at 10:58 AM, Matthias Wessendorf <matzew@apache.org> wrote:


On Fri, Mar 15, 2013 at 10:48 AM, Sebastien Blanc <scm.blanc@gmail.com> wrote:
Great Job,
see my comments inline.

On Fri, Mar 15, 2013 at 10:07 AM, Matthias Wessendorf <matzew@apache.org> wrote:

As discussed on the earlier theard, we have some raw APIs... Below a little summary:

We have a UnifiedPushManager(.java) defined, which is basically a registry for "push enabled" apps (PushApplication.java). Such a PushApplication is a logical construct on the backend which is allowed/enabled to send notifications to mobile clients. One example could be the "Twitter Backend" (e.g. for push notification on direct messages).

As you said the manager is here more a registry than a manager in the current state, maybe we should have a PushApplicationRegistry interface which has as only responsibility to hold the register state,

Can you gist ?


 
the implementation of the registry will connect to the chosen persistence unit (JPA/Mongo/Oracle ...).

Not sure I really want to that - now :) I am (for first iteration) fine to have something running, instead of being that flexible and be able to go with any existing "data source" :-)

Well, for sure, for the first iteration we will provide a default implementation.  
 
This way we could have a concrete implementation of the UnifiedPushManager than can be used by different backend/customers (think DRY) , they just have to inject the needed PushApplicationRegistry implementation.    

Not sure what exactly you mean - perhaps a gist / pseudo code is helpful here too ?

Again, my fork should help you understanding https://github.com/sebastienblanc/ag-unified-push-api/tree/registry but basically, it is the same as your code except I apply the delegate pattern. 

 

Now each of the PushApplication can have a few mobile applications, that receive those push messages (e.g. the offical Twitter iOS client and the offical Twitter Android client). These "mobile apps" are represented - on the server - with the MobileApplication.java class. Usually there is only one iOS app and one Android... BUT imagine the case of a "paid/premium app" versus a free app (e.g. something like TwitterPro-iOS and Twitter-free-iOS... NOTE: there is NOTHING like that, I just made these two apps up, to explain the concept).

Of course there are several installations of the iOS(and Android...) app. Each installation is represented with theMobileApplicationInstance.java class. Each installation is registered by a "device registration service": The actual app on the device submits its token/regId (and some other infos) to a HTTP endpoint....

Now the UnifiedPushManager(.java) is the central API to register PushApps and their mobile views, including (device)registration of installations (-> MobileApplication and MobileApplicationInstance).

Any backend app, can now use the Sender API to actually send the message to these different devices/appications, from the UnifiedPushManager, assuming they have permission :-)

A simple example is here (java code for registration AND sending); Note it's a Unit test.......: https://github.com/matzew/ag-unified-push-api/blob/master/src/test/java/org/jboss/aerogear/push/UnifiedPushManagerTest.java#L41-L81


Maybe the Sender interface should be an attribute of the PushManager, the customer can set his Sender impl (pushManager.setSender(...) )  and the UnifiedManager act as a facade for the "sending" actions.  


Hrm - you really think folks will write their own "Senders"? I think... if they want to add support for "Windows Mobile", they just have to extend the abstract MobileApplicationImpl and implement it's send() to talk to the Windows Push infrastrucuture

Again, we will provide a default sender implementation. But I seee indedd issues, having a single senders for different platforms , hum, let me think about this ;) 


the Sender() is an aggregate of the different mobile Application's "send()" - it will enqueue the message for the different platforms 


thanks for the feedback - will check ur fork


-M


 


PERHAPS... just using interfaces was confusing  - there will be concrete classes (first impl is in the TEST project (see other thread)), but the interfaces are a highlevel view of the "domain model"
 

So far, so good - but why this abstraction ????

Goal: We want that any (JBoss/AeroGear powered) mobile application, that is backed by JBoss technology, is able to easily work with push messages. For a JBoss "backend application" it should be as simple as possible, to send messages to its different mobile clients

Some Scenarios

  • MyWarehouseInc-backend can send messages to different "customer" groups (e.g. discounts for only iOS (or only Android) users).
  • MyInsuranceCorp-backend can send important "info messages" to diffenrent variants of its mobile Applications (e.g. to the MyInsuranceCustomer-APP (regardless of the OS) AND to the app for their own agents (MyInsuranceAgent-APP))
  • MyPublishing-Company-backend sends updates to all of its apps (free and premium - regardless of the mobile OS). Advanced content is only push to the paying customers...
  • A company has different backends (small apps for different tasks) - and these different backends could be able to reach all of the company's mobile apps

So... the Sender somewhat acts as a broker (for accessable apps on the 'registry' UnifiedPushManager)...


Maybe we should define some kind of "Application" Collection, as smart/specific  Java Collection implementation to be able to create easily groups of apps etc .. just a rough idea that needs to be cleaned up ;)


Something like that would be neat, for more advanced queries / selection etc

We could have a (very) simple query language specific for Push Apps, like hibernate, we could query by example. In my fork you will see an extremely basic Query object ... 

Thanks for the feedback!
-M
 


BTW... none!!!!!!! of the API names are final - happy to hear better names!!!

Please provide feedback (here and on the other thread), for missing/wrong/good items.!


Greetings,
Matthias




On Thu, Mar 14, 2013 at 6:58 PM, Matthias Wessendorf <matzew@apache.org> wrote:
here is, including device registration:


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:

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


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



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

_______________________________________________
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



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf