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

Some more APIs, for some basic (initial) functionality: https://gist.github.com/matzew/c5fbc23bc97dfead46e1 User/Dev enrollment can be addressed by (hopefully) reusing the ag-security. On Wed, Mar 13, 2013 at 11:15 AM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: > 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 > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf