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

--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf