[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 05:48:17 EDT 2013 

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

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

>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130315/e82fdda4/attachment-0001.html

More information about the aerogear-dev mailing list