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

Wed Mar 13 09:43:18 EDT 2013

FYI - the APIs are here:

https://github.com/matzew/ag-unified-push-api

NEXT: impl for testing + REST API endpoints

On Wed, Mar 13, 2013 at 2:28 PM, Matthias Wessendorf <matzew at apache.org>wrote:

> 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
>

-- 
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/0ec87e5c/attachment-0001.html 