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

Wed Apr 17 08:29:23 EDT 2013

Excellent write up.

have we defined the terminology yet. i know that is something we talked about, since we have different definitions for things.

and is this just for "installed" apps( not web apps )?

On Apr 17, 2013, at 4: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)
> 
> 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:
> 
> 
> 
> 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...)
> 
> 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, I would like to store the above "device" data, using the Picketlink IDM (Actually the entire data base (PushApplication, MobileApplication and Installation("device")).
> 
> 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)
> 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" )
> 
> 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;
> 
> 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.
> 
> 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
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130417/26369903/attachment-0001.html 