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 1:15 PM, tech4j(a)gmail.com <tech4j(a)gmail.com&gt;wrote: > A few small comments, because I think this is looking pretty good. > > * At first glance I like the idea of having it be a registry instead of a > manager. In some ways that makes it more obvious this a logical construct. > > * Another use case: "Other services inside of JBoss could use the push > manager/registry, for example the admin console, Errai, drools, etc..." > ** I.e. not just for end user apps > I think that's what I tried to address with this statement: "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" ==> should not be tied to a specific backend; For instance a JSF managed bean you use the "Sender" as well - to push out messages to 'its' configured mobile apps (on the registration)

> > * The non-native push (JS, "connected" apps, etc...) imo would/should be > separate and part of AeroGear proper. I think having both functions in > this one shared service would make it too complex, and hard to cover other > groups use-cases. As I see it for AeroGear - we receive a > msg/event/trigger that we want to send to clients. The API allows > developers to say "send msg to x, y, z users/devices". AeroGear checks for > any apps that are "connected" and sends a non-native push msg to those > clients. AeroGear then determines who did not get a "connected" msg (that > may be tricky), and uses the API your defining to send those users native > push msg. > You mean breaking into two components? - native push - web based push and an overall API on top that 'aggregates'?

> > ** The API would have a way to set only "connected", only native, etc... > as well. > > * In the future and maybe as a POC that this can work with non-aerogear > clients we could see about getting push messages setup with Christos' JBoss > admin app with this. Not a priority, but an idea :-) > > > > > On Fri, Mar 15, 2013 at 6:56 AM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: > >> >> >> 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 >>>> > 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 >> > > > > -- > 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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev