[aerogear-dev] Push Server: Database: Storing data for an application installation (per device)

Wed Apr 17 06:24:53 EDT 2013

on a side note... since the data the device sends to the "push server" /
"registration database", may differ (from case to case)...

I think having a flexible (read: schemaless) database for the "model" would
be good...

On Wed, Apr 17, 2013 at 10:39 AM, Matthias Wessendorf <matzew at apache.org>wrote:

> Hi folks!
>
> As discussed a few times, we have the following "high-level" construct of
> data (required for push):
>
>    - PushApplication ("HR Mobile")
>    - MobileApplication ("HR for iPhone", "HR for iPad", "HR for Android")
>    - Installation ("Matthias uses iPhone HR", "Matthias uses Android HR",
>    "Bruno uses iPad HR")
>
> (More details here <https://gist.github.com/matzew/6012edf62d1915689a67>)
> <https://gist.github.com/matzew/04346e212e317d976532#data-per-installation-per-device>Data
> per installation per device
>
> Now, thinking about what to store for an actual device gives you lot's of
> choices. For instance, Helios/Orbiter stores a lot of information in the
> "device" database (e.g. (current) Location Data, Locale etc).
>
> Like you can see here:
>
> [image: Helios Web UI Screenshot]<https://raw.github.com/helios-framework/helios.io/assets/helios-screenshot.png>
>
> All the information is really app specific (e.g. not every app needs to
> know the current location...); (A side-note... our client SDK should be
> flexible to store what ever the application requires...)
>  <https://gist.github.com/matzew/04346e212e317d976532#mandatory-data>Mandatory
> Data
>
> Regardless of what data is desired or not, the following is the minimum
> that needs to be stored:
>
>    - Device Token (generated by the PushNetwork (e.g. APNs, GCM) - used
>    to identify the device with the actual Network, so that it can send a
>    message to that device)
>    - OS and Device Type (we need to store if this is an installation of
>    the iPad version, the iPhone version or the Android version (to use the
>    above HR example))
>    - OS Version (the version, never hurts)
>
> This is the minimum of data, required to store in our "device
> registration" database;
>
> As discussed in AEROGEAR-1101<https://issues.jboss.org/browse/AEROGEAR-1101>,
> I would like to store the above "device" data, using the Picketlink IDM
> (Actually the entire data base (PushApplication, MobileApplication and
> Installation("device")).
>  <https://gist.github.com/matzew/04346e212e317d976532#user-data->User
> Data ?
>
> Now... you might wonder if there isn't any user data required ..... Well,
> that is also up to the application and how works.
>
> Overall, I see the following two common application models, suppored by
> the *Push Server*:
>
>    - device has a user (a known user in an Application (e.g. Marketing)
>    Databases)
>    - device has *NO* user (no need to have a user for the app)
>
>  <https://gist.github.com/matzew/04346e212e317d976532#user-required>User
> required
>
> This would be an app, that requires an account, before it can be used on
> the device (e.g. something twitter). For applications like that, a user is
> required, otherwise hard to send a Push Notification to a specific user
> (e.g. "You have new tweets") ( *Also twitter works only with a user, on
> their "application backend/database"* )
> <https://gist.github.com/matzew/04346e212e317d976532#no-user-concept-on-the-backend>No
> User concept, on the backend
>
> That's a (very) simple app. Think *Sports App*. The app displays "sport
> news" (fetched via HTTP, when the app is opened). A installed application
> can also receive "broadcasts messages".
>
> *Scenario:* You download the app in the app store, install it, use it;
> When ever the backend thinks it needs to send Notifications (eg. "New score
> 3:1 at Germany - Brazil"), it simply uses the token and submits the message
> to the actual Push Network. For applications like this, the backend does
> not need a user;
> <https://gist.github.com/matzew/04346e212e317d976532#application-with-user-required>Application
> with User required
>
> Now, let's comeback to the apps, where a user is required, in the backend.
> Somehow the business backend (e.g. HR system) needs to identify a certain
> user (and their devices), so that it can "submit" Push Notification jobs.
>
> Bruno, Shane (from Picketlink) and I talked already to store something
> like a unique ID (e.g. user-id, login-name or user-name) in the "Device"
> Table (per device):
>
> TOKEN     |     user      |       DEVICE-TYPE    |    OS-VERSION
> _________________________________________________________________________
> 823ssar   |  abstractj    |         Android      |     Android4.x.y.blah
> 1234456   |  mwessend     |         iPad         |     iOS4.0.1
> ghh2712   |  mwessend     |         iPhone       |     iOS6.1.2
>
> Doing so, we can use that "unique ID" to *bridge* between the actual
> "application database" and the stored informations about the device(s),
> stored in the *push-server-database*; per user!
>
> *NOTE* Since the Push Server (and the "device database") is a standalone
> server (access via HTTP / Java Library), the real (business) backend (e.g.
> HR App), can than say:
>
> *Send message X to to following users* (a list of unique user IDs would
> be send to the push server, so that the Push Server submit these messages
> to the actual Push-Networks (ANPs/GCM)so that Apple and Google (for
> iOS/Android) can deliver the actual notification to the client/device.
>  <https://gist.github.com/matzew/04346e212e317d976532#client-sdk>Client
> SDK
>
> Again, As said above, we should (and will) offer hooks to have a
> convenient way to register the unique ID, together with the
> token,OS,version etc. *BUT* *that is not that important here... ;-)*
>
> *
> *
>
> *Thoughts?*
>
> *
> *
>
> *
> *
>
> --
> 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/20130417/69eca2db/attachment.html 