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

Wed Mar 13 09:28:53 EDT 2013

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 at apache.org>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 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
>

-- 
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/31d39ce1/attachment.html 