"installed" apps (somewhat) === connected web app client
Kris and I are working on a prototype for all of that; Kris may help with
the names :)
On Wed, Apr 17, 2013 at 2:29 PM, Lucas Holmquist <lholmqui(a)redhat.com>wrote:
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(a)apache.org>
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
- Installation ("Matthias uses iPhone HR", "Matthias uses Android
"Bruno uses iPad HR")
(More details here <https://gist.github.com/matzew/6012edf62d1915689a67
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
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...)
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
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
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)
- device has *NO* user (no need to have a user for the app)
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"* )
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;
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.
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... ;-)*
aerogear-dev mailing list
aerogear-dev mailing list