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

Thu Apr 18 11:11:32 EDT 2013

Forget that.......

For very device requires the following data:

   - token
   - os
   - type
   - version (of the OS)

But... sometimes folks may want to store more (e.g. geo location data,
username etc)...

Business related data should be stored in the "business database", but to
bridge between these worlds, the following (optional) attribute is needed:

   - identifier

That's all - everything else is app specific and should NOT be stored in
the database that stores the tokens.

I guess you would also never store the salary in there (if the push server
would back a mobile HR app :))

On Wed, Apr 17, 2013 at 12:24 PM, Matthias Wessendorf <matzew at apache.org>wrote:

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

-- 
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/20130418/e78e6304/attachment.html 