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

Sebastien Blanc scm.blanc at gmail.com
Fri Mar 15 06:27:17 EDT 2013 

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

>
>
> On Fri, Mar 15, 2013 at 10:48 AM, Sebastien Blanc <scm.blanc at gmail.com>wrote:
>
>> Great Job,
>> see my comments inline.
>>
>> On Fri, Mar 15, 2013 at 10:07 AM, Matthias Wessendorf <matzew at 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/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 ;)

>
>
> 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-why-this-abstraction->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
>>>  <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 at apache.org>wrote:
>>>
>>>> here is, including device registration:
>>>>
>>>>
>>>> https://github.com/matzew/ag-unified-push-api/blob/master/src/test/java/org/jboss/aerogear/push/UnifiedPushManagerTest.java#L41-L81
>>>>
>>>> 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/org/jboss/aerogear/push/application/ConnectedJavaScriptApplication.java
>>>>
>>>> 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 at apache.org
>>>> > 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 at apache.org> 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 at apache.org> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Mar 13, 2013 at 10:06 PM, tech4j at gmail.com <tech4j at 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:
>>>>>>>
>>>>>>> https://github.com/matzew/ag-unified-push-api/blob/master/src/main/java/org/jboss/aerogear/push/application/MobileApplication.java#L23
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> * 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/notnoop/apns/ApnsService.java#L161
>>>>>>> )
>>>>>>> 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 at qmx.me>wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 13/03/2013, at 10:28, Matthias Wessendorf <matzew at 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 at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> blog: http://in.relation.to/Bloggers/Jay
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> aerogear-dev mailing list
>>>>>>>> aerogear-dev at 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130315/a257dc89/attachment-0001.html

More information about the aerogear-dev mailing list