Re: [aerogear-dev] AeroGear Unified Push - Abstraction layer for "push enabled apps" (was: Re: [AG Push] BASIC (and INITAL) use cases of the Unified Push Server)

Great Job, see my comments inline. On Fri, Mar 15, 2013 at 10:07 AM, Matthias Wessendorf <matzew(a)apache.org&gt;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,

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

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.

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

> <https://gist.github.com/matzew/73d478a42c093e21a6b9#so-far-so-good---but-... > 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 > <https://gist.github.com/matzew/73d478a42c093e21a6b9#some-scenarios>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 ;)

> 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(a)apache.org&gt;wrote: > >> here is, including device registration: >> >> >> https://github.com/matzew/ag-unified-push-api/blob/master/src/test/java/o... >> >> 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/o... >> >> 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(a)apache.org&gt;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(a)apache.org&gt; wrote: >>> >>>> My UNIT test looks (currently) like: >>>> >>>> https://gist.github.com/matzew/3d7f9915afd8f6705da5 >>>> >>>> >>>> >>>> -M >>>> >>>> >>>> >>>> >>>> On Wed, Mar 13, 2013 at 11:03 PM, Matthias Wessendorf < >>>> matzew(a)apache.org&gt; wrote: >>>> >>>>> >>>>> >>>>> On Wed, Mar 13, 2013 at 10:06 PM, tech4j(a)gmail.com <tech4j(a)gmail.com&gt;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: >>>>> >>>>> https://github.com/matzew/ag-unified-push-api/blob/master/src/main/java/o... >>>>> >>>>> >>>>>> >>>>>> * 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. >>>>>> >>>>> >>>>> In apple land these are invalid tokens (see >>>>> https://github.com/notnoop/java-apns/blob/master/src/main/java/com/notnoo... >>>>> ) >>>>> 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(a)qmx.me&gt; wrote: >>>>>> >>>>>>> >>>>>>> On 13/03/2013, at 10:28, Matthias Wessendorf <matzew(a)apache.org&gt; >>>>>>> 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(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> blog: http://in.relation.to/Bloggers/Jay >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>> >>> >>> >>> -- >>> 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(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