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

Matthias Wessendorf matzew at apache.org
Fri Mar 15 05:07:33 EDT 2013 

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

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


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

More information about the aerogear-dev mailing list