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

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(a)lists.jboss.org (mailto:aerogear-dev@lists.jboss.org) https://lists.jboss.org/mailman/listinfo/aerogear-dev