[aerogear-dev] Using IDM for storing device informations (was: Re: Push Server: Database: Storing data for an application installation (per device))

Thu Apr 18 04:48:38 EDT 2013

I think... one problem with using an (simple) Agent is, that the login name
is really required (otherwise I get NPE)

Note that the "client identifier" is only optional (see cases where user is
not required)

https://github.com/matzew/IDM-tests/blob/master/src/main/java/org/aerogear/connectivity/api/MobileInstallationAgent.java#L35

On Thu, Apr 18, 2013 at 8:37 AM, Matthias Wessendorf <matzew at apache.org>wrote:

> Hi, as mentioned in AEROGEAR-1101<https://issues.jboss.org/browse/AEROGEAR-1101> we
> are looking into using the IDM for storing the "data model";
>
> I created some hacky/ugly project to start playing with IDM for my "device
> installations"
>
> https://github.com/matzew/IDM-tests
>
>
> I am having a custom "agent" there,.... however I see the point (by Shane
> on PL's IRC channel) that perhaps the Agent is not right, since the device
> CAN (see my other email) have a reference to a user (in that case the
> device would be just an "add-on" / "extension" of the user).
>
> Also, besides the device data, we should/need to store the "application
> abstraction" model (see other email) in the IDM as well Like:
>
> One PushApp (HR mobile) has two mobile apps (HR-iOS, HR-Android) each of
> the mobile apps has "installed" apps (bruno uses iOS version, on his iPad;
> I use android on my other Tablet)
>
> Greetings,
> Matthias
>
>
>
> 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/2eb21717/attachment-0001.html 