Skip to content

Instantly share code, notes, and snippets.

@matzew
Last active December 14, 2015 23:49
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save matzew/73d478a42c093e21a6b9 to your computer and use it in GitHub Desktop.
Save matzew/73d478a42c093e21a6b9 to your computer and use it in GitHub Desktop.

#AeroGear Unified Push - Abstraction layer for "push enabled apps"

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment