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

Lucas Holmquist lholmqui at redhat.com
Fri Mar 15 08:41:10 EDT 2013 

looking good,   need to digest it a bit ;)
On Mar 15, 2013, at 5: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).
> 
> 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
> 
> 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
> 
> 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 _______________________________________________
> 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/6103d961/attachment-0001.html

More information about the aerogear-dev mailing list