Using IDM for storing device informations (was: Re: Push Server: Database: Storing data for an application installation (per device))
1:37 a.m.
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(a)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 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/h...
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>Man...
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-th...
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...
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
![Screenshot]<https://raw.github.com/helios-framework/helios.io/assets/h...](http://Screenshot]%3Chttps://raw.github.com/helios-framework/helios.io/assets/helios-screenshot.png%3E){kind=link}
3:48 a.m.
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/aerogea...
On Thu, Apr 18, 2013 at 8:37 AM, Matthias Wessendorf <matzew(a)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(a)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 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/h...
>
> 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>Man...
> 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-th...
> 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...
> 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
4288
days inactive
4288
days old
1 comments
1 participants
participants (1)
-
Matthias Wessendorf