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

Hi, I have updated the gist to reflect Bruno's use-case. I also did a little differentiation on "push apps" and "mobile app" TL;DR: Push App: my backend that sends messages to several mobile apps, on a device (think: twitter backend) Mobile App: an iOS/android version of the mobile view (think: twitter-iOS) MobileInstance: a real installed version of the iOS version (think: Matthias has the twitter-iOS app installed) The BASIC domain model for the "application abstraction", is covered in here: https://gist.github.com/matzew/3e7e6218d6cea94f65ad -Matthias On Wed, Mar 13, 2013 at 8:31 AM, Bruno Oliveira <bruno(a)abstractj.org&gt;wrote: > 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(a)lists.jboss.org (mailto:aerogear-dev@lists.jboss.org) > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)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