[aerogear-dev] [AG Push] BASIC (and INITAL) use cases of the Unified Push Server

Wed Mar 13 03:31:43 EDT 2013

Great info here Matthias, I'd like to test these scenarios with PicketLink. And thinking aloud here what about scenarios like: 

- Admin can disable push notifications to devices (simple as is at first glance initially) 

-- 
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile

On Tuesday, March 12, 2013 at 7:50 AM, Matthias Wessendorf wrote:

> Hi,
> 
> after two weeks of prototyping and evaluating, I started the design phase of the AG Unified Push Server.
> 
> I created a GIST [1] that defines the INITIAL (not final) first DRAFT of the supported use cases. Yes, they are very minimal :), but once we have something running, we can add more features. Please review and comment here... 
> 
> (COPY AND PAST FROM GIST):
> 
> AG Unified Push - Use Cases
> 
> Right now there are the following roles:
> 
> Developer: Some one that setup up the backend for different mobile applications, to enable push (e.g. iOS certs or Google API keys(more later)
> User: Install an AG-App on his phone
> Admin needed? yes, once we have a management user interface. NOT part of the first iteration....
> 
> Use Cases
> 
> Below are the BASIC use-cases, that the AG Unified Push needs to initially support.
> 
> Enroll AeroGear-Push-User (based on identified roles)
> Remove AeroGear-Push-User
> Developer can register mobile App (for different Push Networks, e.g. Apple, Android)
> Developer can unregister mobile App (for different Push Networks, e.g. Apple, Android)
> User registers his phone with the backend (Device Token + APP-ID are send to the backend)
> User unregisters his phone with the backend (e.g. app got deinstalled, user deleted etc)
> User receives Push Messages (handled by the native OS, once accepted to receive messages)
> Send push messages, done by a user or a developer
> 
> Enroll
> 
> Register different user types (based on desired role) with the AG-Unified-Push server. The Developer role always requires a username/password. The User is not always required on the server. Some mobile apps don't know the concept of a logged in user (e.g. Sport Broadcast apps), but others do require a User before using the mobile app (e.g. Twitter)
> 
> Remove registered User
> 
> It should be possible to remove Users (app users). That can me their account is erased or their device tokes are removed....
> 
> Add mobile app
> 
> A registered Developer can register multiple Apps with the AeroGear Push Server. Each app has a (generated) AeroGear-Application-Key, besides that, the logical concept of a APP, on the server, requires access to the Push Networks (Google or Apple). Therefore such a registered APP needs a certificate and passphrase (iOS) or a Google API key (Android)
> 
> Remove mobile app
> 
> A registered Developer should be able to remove the apps from the server.
> 
> Device Registration
> 
> Once a User installs and launches the mobile app, the embedding OS generates a Device-Token (or Registration ID on Android). The mobile Application needs to send this Token/ID and the AeroGear-Application-Key to the AeroGear Server, so that the server can register this phone/app with the particular app, to be able to receive push messages.
> 
> 
> Note: On iOS the user as to agree to receive push messages
> 
> Remove registered Device
> 
> If an app gets uninstalled, the phone is no longer able to receive push messages. Therefore inactive Device-Tokens/Registration-IDs should be removed, on the server. However... there is no harm if invalid keys are used, on the server, when trying to send push messages...
> 
> Receives Push Messages
> 
> Every installed app, is able to receive Push Messages through the APIs, offered by the platforms (iOS, Android). Initially there will be NO client SDK.
> 
> 
> Note: On iOS the user as to agree to receive push messages
> 
> Send push messages
> Broadcast
> 
> The Unified Push server acts as a broker to deliver messages (via Native Push) to several devices. Authorized Users (based on their roles) can send push messages to a specific application. For instance a Developer that ONLY owns "AeroGear-App1" is only able to broadcast messages to that particular app. He is NOT able to send a message to "AeroGear-App2"...
> 
> Filtered messaging
> 
> Sending message to a specific user.... We need a DSL to filter users etc.... This will be done later...
> 
> In-APP messaging
> 
> Later, there will be an option to have the app also submit push messages, to broadcast to other users of the app (or to a specific user). This will be done later...
> 
> API access
> 
> Initial focus is that the above functionality is ONLY accessable via RESTful/HTTP APIs!
> 
> 
> Later we will have a few more SDKs:
> 
> Client APIs (for Android, iOS)
> Server APIs (send a push message out of your JavaEE app, without submitting (manually) the HTTP calls)
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Cheers!
> Matthias
> 
> [1] https://gist.github.com/matzew/7475652fa3b0cbb11c1c
> -- 
> 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 (mailto:aerogear-dev at lists.jboss.org)
> https://lists.jboss.org/mailman/listinfo/aerogear-dev