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

Wed Mar 13 06:15:29 EDT 2013

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 at abstractj.org> 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 at lists.jboss.org (mailto:aerogear-dev at lists.jboss.org)
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130313/efe02d11/attachment-0001.html 