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 11:27 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt;wrote: > > > 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&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, >>> >> >> 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 ;) > 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" >> >> >>> >>>> <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&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 >>> >> >> >> >> -- >> 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