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)

On Fri, Mar 15, 2013 at 10:58 AM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: > > > On Fri, Mar 15, 2013 at 10:48 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt;wrote: > >> Great Job, >> see my comments inline. >> >> On Fri, Mar 15, 2013 at 10:07 AM, Matthias Wessendorf <matzew(a)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 ? > Take a look at my fork https://github.com/sebastienblanc/ag-unified-push-api/tree/registry ;) > > > >> 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 the >>> MobileApplicationInstance.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. >> > > > 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 ;)

> > 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" > > >> >>> <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 ;) >> > > > 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(a)apache.org >>> > 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 >> > > > > -- > 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