PushEE: JMS support
by Matthias Wessendorf
Hi,
for ticket "AEROGEAR-1222" ([1]) I looked a bit at JMS integration hooks.
The JIRA has an updated description, and two SIMPLE "UML diagrams".
Also, I created a branch that uses JMS for (GCM/APNs) based broadcast (more
to follow later this week).
Example:
The HTTP enpoint for the "broadcast sender", publishes a JMS messages and
immediately returns:
https://github.com/matzew/pushee/blob/Messaging/src/main/java/org/aerogea...
Yes, there is no guarantee at all, that the message really arrives the
device (see Apple/GCM doc for details)
Behind the sceneses, a "Consumer" is responsible to deliver the message to
the network:
https://github.com/matzew/pushee/blob/Messaging/src/main/java/org/aerogea...
The code above performs all the "heavy" work ("blocking" JPA lookups and
PushNEtwork Delivery)..
We now should use the "standalone-full.xml" configuration, since that
supports JMS. I double checked and the SimplePush/Netty Adapter are working
fine here too.... also, for JMS (for now), we need to declare some JMS
topics in the "standalone-full.xml" file
More during the week,
Matthias
[1] http://jira.jboss.org/browse/AEROGEAR-1222
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
11 years
[rfc] AeroGear 2.x RoadMap
by Douglas Campos
This is the *tentative* proposed[1] RoadMap for AeroGear 2.x
* AeroGear (~2wks) (Late May)
- point releases across the sub-projects
* AeroGear 1.1.0 (~6wks) (Mid July)
This is a lot for 4 weeks
Epics:
- CI across all projects
- Emailing, tweeting, some way to consume (aerogear-build list)?
- Project site with links, details, and if possible current build status
- Similar to what is showing in the repo
- Release Standards
- Specification standards
- Move aerogear.org / staging.aerogear.org out of jborgs
- Site design updates
- GitHub clean up
- Repo review, and README standards
- Getting starting experience
- Check docs, examples
* AeroGear 1.2.0 (~+6 wks) (Late August)
Epics:
- Unified push server
- Server, client, and basic admin UI
- Extra getting started guides, and polished example
- Polished OpenShift experience
* AeroGear 1.3.0 (~+6wks) (Mid October)
Epics:
- Security
- Define it clearly
- encrypted local storage
- Integration functionality
- Simple integration options (basic WS client work)
- Mostly server-side work
* \<holidays>
* AeroGear 1.4.0 (~+6wks) (Early December)(Late January)
Epics
- Offline/sync
* AeroGear 2.0.0 (~+6wks) (Late January)
\<insert your favorite beverage here>!
Your comments are more than welcome! nothing is set on stone (yet :P).
[1]:https://github.com/aerogear/aerogear.org/pull/60
--
qmx
11 years
Nested endpoints (cont.)
by Summers Pittman
So the old thread was getting a bit long windy.
Here are the current issues that are being discussed on nested endpoints
(and things which we need to discuss before we move ahead on putting
them in the Pipe spec)
1. Saving and removing look really weird.
pipe.remove(2,'/child/3', callback)
vs
pipe.remove(2, callback)
The first removes an element in the child collection with an id 3 of
parent with id 2. The second removes the parent with id 2. This really
isn't THAT weird but it is a bit ugly.
pipe.save(new Parent(), callback)
vs
pipe.save(new Child(), '2/child', callback)
The first saves a new parent object but the second saves a new child
under the parent with an id of 2.
2. The type of Pipe breaks with nested resources as they are.
In Android Pipe is parameterized with a type which correlates to the
resource it represents. This type is serialized into an instance of the
resource and the serialization mechanism does not change. For example
Pipe<Parent> pipe = new RestAdapter<Parent>(URL, Parent.class);
pipe.read(callback);
Passes a instance of List<Parent> to the callback. With nested
resources
pipe.read('/child/2', callback);
SHOULD pass a List<Child> to the callback. There are two ways to do
this and both feel quite hackey.
1) Use reflection to find the type of child and then use that class.
The obvious problem with this is that a service may not return
all of the children attached to a Parent if you ask for just the Parent
(or all of the Parents) but the Parent class on Android would have to
include it.
2) Pass a type to the read operation.
This is LESS hackey and possibly OK, except that we will have
to add more configuration to the GSONdeserialization. The side effect
of this means now we have to include serialization information about
child types in the configuration of the Parent Pipe. At this point the
user might as well just make a Child Pipe.
The same comments apply for save.
Thoughts?
Summers
11 years
Security Thoughts (was: Re: SPEC: AeroGear Unified Push Server)
by Matthias Wessendorf
Hi,
Bruno, Kris and I met, to talk a bit about the *security* related items
here.
<https://gist.github.com/matzew/cd8c8de1e2f00b837bb5#oauth2>OAuth2
Using OAuth2 for (initial) authentication of the following items:
- *Mobile Variant Instances:* The installation on a device (Mobile
Variant Instances) needs to authenticate itself in order to register its
data (e.g. deviceToken, alias etc, as discussed in the spec)
- *Applications:* Backend applications that are using the *HTTP endpoints
* to submit "Push Message requests" (e.g.send XZY to all
mobile-variant-instances of PushApplication X)
- *Developers:* OAuth2 is not enought. See below...
<https://gist.github.com/matzew/cd8c8de1e2f00b837bb5#mobile-variant-instan...>Mobile
Variant Instances based on Android / iOS
There are OAuth2 clients, that will be reused. e.g. *AFNetworking* has
support for it...
<https://gist.github.com/matzew/cd8c8de1e2f00b837bb5#java-application>(Java)
Application
Our Java lib will also use one of the existing client libs (e.g. Apache
Oltu) to authenticate itself against the *AeroGear Unified Push Server*.
<https://gist.github.com/matzew/cd8c8de1e2f00b837bb5#javascript>JavaScript
We will create something minimal for now, instead of making this part of
AeroGear.Auth.
<https://gist.github.com/matzew/cd8c8de1e2f00b837bb5#security-framework>Security
Framework
For Developers (with different roles/groups etc) simply OAuth is not
enough. We need a *Security Framework* for the*right management*, e.g. to
authorize that Developer X is really allowed to do step y.
The *AeroGear Unified Push Server* must be decoupled from any concrete
"Security Provider", so that it is plugable and not tied to *one* "Security
Framework". A common interface could be provided by AeroGear-Security.
The *AeroGear
Unified Push Server* is now only tied to this flexible dependency.
Different plugable implementations would/cloud be provided by
AeroGear-Security.
<https://gist.github.com/matzew/cd8c8de1e2f00b837bb5#management-of-develop...>Management
of *Developers* and Push Applications
The Secuirty Framework abstration (e.g. via AG-Security), would model the
concept of a Developer (and its groups/roles etc).
The actual model of the *AeroGear Unified Push Server* (e.g.Push
Applications,Mobile VariantsandMobile Variant Instances`) would be
independent from that "security layer".
However, since a Developer creates the model objects (e.g. a Mobile Variant for
a Push Application), there is a relationship between them. To some degree
(and also inspired by Picketlink), these are (logical) extensions of a
Developer. They *belong* to a Developer.
*TL;DR:* The "model objects" would be stored as "properties" / "attributes"
of such a "Developer", abstracted by the (future) offerings of the
AeroGear-Sec layer, instead of using a *concrete* "user class" of one,
specific Security Framework
<https://gist.github.com/matzew/cd8c8de1e2f00b837bb5#authentication-of-mob...>Authentication
of Mobile Variant Instance
For the first iteration, we are going to use OAuth here. *However*, that
may have a problem: When aMobile Variant Instance is performing
authentication againt the server, some Credentials (e.g.
"kris:IloveJavaScript") are being used. For *ALL* the installed
applications (e.g. via Play / Apple App-Store), or in EACH browser (
SimplePush)!!
That means the kris:IloveJavaScript couple will be used by 1.000.000
phones. And opens room for *reverse engineering interests*.
*Future:* we will evaluate "Digital signatures" or on the fly (self signed)
client SSL certifactes. This also will remove the requirement (see Spec) to
send a Mobile-Variant-ID to the *AeroGear Unified Push Server*....
*But for now, we start with OAuth...*
<https://gist.github.com/matzew/cd8c8de1e2f00b837bb5#javascriptsimplepush>
JavaScript/SimplePush
User Agent ID and Channel IDs being stored in localStorage...
We *could* investigate JS encryption... but for now the plan is
expire/renew those IDs after some amount of (specified?) time. Crypto.js
will come at a later iteration!
Thoughts? If not, content will be baked into the "spec"...
With ♥
Greetings
Bruno, Kris and Matthias
On Wed, May 8, 2013 at 6:54 AM, Matthias Wessendorf <matzew(a)apache.org>wrote:
>
>
>
> On Wed, May 8, 2013 at 5:24 AM, Deepali Khushraj <dkhushra(a)redhat.com>wrote:
>
>> Matthias,
>>
>> A couple of comments:
>>
>> * You mention disable notifications feature for "mobile variant
>> instances". I was wondering if you considered the same for "mobile
>> variants" and "push applications"? Could help admins disable misbehaving
>> apps, and developers manage older app versions.
>>
>
> yeah, removing(or perhaps disabling) mobile variants, or even the lager
> "push application" concept would be possible.
> I think I mentioned the "instances" to make clear I can easily remove a
> guy, which has been fired (but he didn't return the company phone).
>
>
>>
>> * API access: during "app registration", developer login seems like a
>> good idea.
>>
>
> Otherwise everyone could register new apps :)
>
>
>> I am not so sure about "sending" messages though, as this will likely be
>> initiated by a server-side component with no developer in the loop.
>>
>
> I feel that we should protect our "sending http endpoint". That does
> not necessarily mean a user:password combination.
>
> The "Send" is triggered by a server-side component (e.g. some backend app,
> written in some language/framework).
> We should make sure that only "valid" server-side components can send
> messages to a PushApplication/MobileVariant(s).
>
> Not covered in the spec (but the UI Mockups indicate it already)
> When these PushApplication/MobileVariant(s) are registered we will have a
> button to generate "access keys".
>
> curl -v -H "Accept: application/json" -H "Content-type: application/json"
> -H "ag-pa-access-key: 329804327981237984317927098247980432179843217813267834687213842"
> -X POST
> -d '{message: {"key":"blah", "alert":"HELLO!"}}'http://SERVER/sender/broadcast/PushApplicationID
>
>
> Not sure if that is really enough, but here the "server side comp." needs
> to know the ID of the logical "Push Application" constract, plus it
> "push-app-access-key";
>
> So... if someone knows these two, he could start spamming the users, hence
> I feel that on-top of these keys we may want to have the
> server-side-component somehow perform some sort of auth against our
> HTTP-SEND endpoint
>
>
>
>
>
>>
>> Thanks for the spec! The clear definitions made it very easy to read.
>>
>
> Thanks!
>
>
>>
>> D.
>>
>>
>> On May 6, 2013, at 3:33 AM, Matthias Wessendorf <matzew(a)apache.org>
>> wrote:
>>
>> Moved the current draft to the homepage, see
>> https://github.com/aerogear/aerogear.org/pull/57
>>
>> -M
>>
>>
>> On Tue, Apr 30, 2013 at 1:57 PM, Bruno Oliveira <bruno(a)abstractj.org>wrote:
>>
>>> Really helpful Matthias. Thanks!
>>>
>>>
>>> --
>>> "The measure of a man is what he does with power" - Plato
>>> -
>>> @abstractj
>>> -
>>> Volenti Nihil Difficile
>>>
>>>
>>>
>>> On Tuesday, April 30, 2013 at 8:54 AM, Matthias Wessendorf wrote:
>>>
>>> > On IRC, Bruno raised a valid concern: The earlier version had "use
>>> cases"
>>> >
>>> >
>>> > I updated the GIST (
>>> https://gist.github.com/matzew/b918eb45d3f17de09b8f) and added:
>>> > * more definitions
>>> > * usage scenarios
>>> > * use cases
>>> >
>>> >
>>> > -Matthias
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > On Mon, Apr 29, 2013 at 3:27 PM, Matthias Wessendorf <
>>> matzew(a)apache.org (mailto:matzew@apache.org)> wrote:
>>> > > Hi,
>>> > >
>>> > > I started a GIST to convert the different gists and readme's into a
>>> server-side spec
>>> > > (https://gist.github.com/matzew/b918eb45d3f17de09b8f)
>>> > >
>>> > >
>>> > > * Regarding the "mobile variant instance":
>>> > > We need to decide, what a SimplePush client may need on-top of the
>>> data, described below (and in the gist). (since they have clientIDs +
>>> channels)
>>> > >
>>> > > * Similar... we need to reflect the "" on a "selected" (and
>>> broadcast) send as well.
>>> > >
>>> > > * Sec: there is a different meeting, on the sec - content will be
>>> integrated (or linked from this spec)
>>> > >
>>> > >
>>> > > If this doc, looks good, I will submit it as a PR so that we get it
>>> on the homepage
>>> > >
>>> > >
>>> > > Next:
>>> > > CLIENT SPEC is coming later today (or tomorrow)
>>> > >
>>> > > Thoughts ?
>>> > > Matthias
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > AeroGear Unified Push Server (Draft 0.0.3)
>>> > >
>>> > > The AeroGear Unified Push Server is a server that allows sending
>>> native push messages to different mobile operation systems. The initial
>>> version of the server supports Apple's APNs (
>>> http://developer.apple.com/library/mac/#documentation/NetworkingInternet/...),
>>> Google Cloud Messaging (
>>> http://developer.android.com/google/gcm/index.html) and Mozilla's
>>> Simple Push (https://wiki.mozilla.org/WebAPI/SimplePush).
>>> > >
>>> > > Motivation / Purpose
>>> > >
>>> > > Goal: Any (JBoss/AeroGear powered) mobile application, that is
>>> backed by JBoss technology (e.g. admin console, Errai, drools, etc.), is
>>> able to easily work with mobile push messages. For a JBoss "backend
>>> application" it should be as simple as possible, to send messages to its
>>> different mobile clients.
>>> > >
>>> > > Definitions
>>> > >
>>> > > Before we get into details, it's important that we have a good
>>> lexicon.
>>> > >
>>> > > Push Application
>>> > >
>>> > > A logical construct that represents an overall mobile application
>>> (e.g. Mobile HR).
>>> > >
>>> > > Mobile Variant
>>> > >
>>> > > A mobile variant of the Push Application. There can be multiple
>>> variants for a Push Application (e.g. HR Android,HR iPad, HR iPhone free,
>>> HR iPhone premium or HR Mobile Web).
>>> > >
>>> > > Mobile Variant Instance
>>> > >
>>> > > Represents an actual installation on a mobile device (e.g. User1
>>> connected via MobileWeb or User2 runs HR iPhone premium on his phone)
>>> > >
>>> > > Overview
>>> > >
>>> > > The AeroGear Unified Push Server contains three different components:
>>> > >
>>> > > Registration: Registry for Push Applications, Mobile Variants and
>>> Mobile Variant Instances
>>> > > Storage: A database, storing the registered applications and
>>> instances
>>> > > Sender: Receives messages and sends them to different Mobile Variant
>>> Instances
>>> > >
>>> > >
>>> > > The graphic below gives a little overview:
>>> > >
>>> > > Functionality
>>> > > Registration
>>> > >
>>> > > Three different registration types are provided by the AeroGear
>>> Unified Push Server.
>>> > >
>>> > > Push Application Registration
>>> > >
>>> > > Adds a logical construct, that represents an overall mobile
>>> application (e.g. Mobile HR). The Push Application contains the following
>>> properties:
>>> > >
>>> > > Name
>>> > > Description
>>> > > A collection of Mobile Variants
>>> > >
>>> > >
>>> > > The server offers an HTTP interfaces to apply a Push Application
>>> registration:
>>> > >
>>> > > curl -v -H "Accept: application/json" -H "Content-type:
>>> application/json" -X POST -d '{"name" : "MyApp", "description" : "awesome
>>> app" }' http://SERVER/applications <http://server/applications>
>>> > >
>>> > > The response returns an ID for the Push Application.
>>> > >
>>> > > Mobile Variant Registration
>>> > >
>>> > > Adds a mobile variant for an existing Push Application. There can be
>>> multiple variants for a Push Application (e.g. HR Android, HR iPad, HR
>>> iPhone free, HR iPhone premium or HR Mobile Web).
>>> > >
>>> > >
>>> > > The server supports the following variant types:
>>> > >
>>> > > iOS
>>> > > Android
>>> > > SimplePush
>>> > >
>>> > > iOS Variant
>>> > >
>>> > > An iOS variant represents a logical construct for one iOS
>>> application (e.g. HR for iPhone or HR for iPad ). The iOS variant requires
>>> some APNs specific values:
>>> > >
>>> > > APNs Push Certificate file
>>> > > Passphrase
>>> > >
>>> > >
>>> > > The server offers an HTTP interfaces to register an iOS varian:
>>> > >
>>> > > curl -i -H "Accept: application/json" -H "Content-type:
>>> multipart/form-data" -F "certificate=(a)/Users/matzew/Desktop/MyCert.p12" -F
>>> "passphrase=TopSecret" -X POST http://SERVER/applications/{PUSH_ID}/iOS<http://server/applications/%7BPUSH_ID%7D/iOS>(
>>> http://SERVER/applications/%7BPUSH_ID%7D/iOS<http://server/applications/%7BPUSH_ID%7D/iOS>
>>> )
>>> > >
>>> > > NOTE: The above is a multipart/form-data, since it is required to
>>> upload the "Apple Push certificate"!
>>> > >
>>> > >
>>> > > The response returns an ID for the iOS variant.
>>> > >
>>> > > Android Variant
>>> > >
>>> > > An Android variant represents a logical construct for one Android
>>> application (e.g. HR for Android). The Android variant requires some Google
>>> specific values:
>>> > >
>>> > > Google API Key
>>> > >
>>> > >
>>> > > The server offers an HTTP interfaces to register an Android variant:
>>> > >
>>> > > curl -v -H "Accept: application/json" -H "Content-type:
>>> application/json" -X POST -d '{"googleKey" : "IDDASDASDSA"}'
>>> http://SERVER/applications/{PUSH_ID}/android<http://server/applications/%7BPUSH_ID%7D/android>(
>>> http://SERVER/applications/%7BPUSH_ID%7D/android<http://server/applications/%7BPUSH_ID%7D/android>
>>> )
>>> > >
>>> > > _The response returns an ID for the Android variant.
>>> > >
>>> > > SimplePush Variant
>>> > >
>>> > > An SimplePush variant represents a logical construct for one
>>> SimplePush application (e.g. HR mobile Web). The SimplePush variant
>>> requires some Simple Push Network specific values:
>>> > >
>>> > > URL of the PushNetwork server
>>> > >
>>> > >
>>> > > The server offers an HTTP interfaces to register an SimplePush
>>> variant:
>>> > >
>>> > > curl -v -H "Accept: application/json" -H "Content-type:
>>> application/json" -X POST -d '{"pushNetworkURL" : "
>>> http://localhost:7777/endpoint/"}'
>>> http://SERVER/applications/{PUSH_ID}/simplePush<http://server/applications/%7BPUSH_ID%7D/simplePush>(
>>> http://SERVER/applications/%7BPUSH_ID%7D/simplePush<http://server/applications/%7BPUSH_ID%7D/simplePush>
>>> )
>>> > >
>>> > > The response returns an ID for the SimplePush variant.
>>> > >
>>> > > Mobile Variant Instance Registration
>>> > >
>>> > > Adds an mobile variant instance to an existing mobile variant (e.g.
>>> User1 runs HR-iPad on his device). It is possible that one user can have
>>> multiple devices. A mobile variant instance contains the following
>>> properties:
>>> > >
>>> > > Required Data
>>> > > deviceToken
>>> > >
>>> > >
>>> > > The platform specific device token, that identifies the device with
>>> the used push network, in order to deliver messages
>>> > >
>>> > > operatingSystem
>>> > >
>>> > >
>>> > > It is required for the device to submit it's exact name of the
>>> underlying OS.
>>> > >
>>> > > osVersion
>>> > >
>>> > >
>>> > > It is required for the device to submit it's exact version of the
>>> underlying OS.
>>> > >
>>> > > Mobile Variation ID
>>> > >
>>> > >
>>> > > ID received when registering a Mobile Variant. This ID needs to be
>>> submitted as a request header (ag-mobile-variant). NOTE: It is possible
>>> that this ID goes away, in favor for a digital signature in a future release
>>> > >
>>> > > Optional Data
>>> > > deviceType
>>> > >
>>> > >
>>> > > It is recommended to store the (exact) device type (e.g. phone vs
>>> tablet).
>>> > >
>>> > > alias
>>> > >
>>> > >
>>> > > If the business application requires the conecpt of a user, the
>>> registration must submit an unique identifier (like a username), to
>>> identify the user. It is possible that one user has multiple devices.
>>> > >
>>> > > Business Data
>>> > >
>>> > > The above are technical information bits that are required to get a
>>> message to the device. This the app wants to send notification based on a
>>> criteria, the relevant data has to be stored in the business backend. This
>>> way the backend app is very flexible on the criterias (e.g. max salary,
>>> geolocation, number of children, etc). All this data is NOT directly
>>> related to the technical functionality of sending data. The usage of the
>>> AeroGear Pipe is highly recommended to store business data on the business
>>> backend.
>>> > >
>>> > >
>>> > > The server offers an HTTP interfaces to register an mobile variant
>>> instance:
>>> > >
>>> > > curl -v -H "Accept: application/json" -H "Content-type:
>>> application/json" -H "ag-push-app: {id}" -H "ag-mobile-app: {id}" -X POST
>>> -d '{ "alias" : "user(a)company.com (mailto:user@company.com)",
>>> "deviceToken" : "someTokenString", "deviceType" : "ANDROID",
>>> "mobileOperatingSystem" : "android", "osVersion" : "4.0.1" }'
>>> http://SERVER/registry/device <http://server/registry/device>
>>> > >
>>> > > NOTE: Platform specific Client SDKs will be provided to submit the
>>> require data to the AeroGear Unified Push Server.
>>> > >
>>> > > Storage
>>> > >
>>> > > A (configurable) database that stores all registered applications
>>> and instances.
>>> > >
>>> > > Sender
>>> > >
>>> > > HTTP interface that receives messages for a delivery to different
>>> Mobile Push Networks. A few different Sender Types are supported by the
>>> push server.
>>> > >
>>> > > Global Broadcast Sender
>>> > >
>>> > > Sends a push message to all mobile variants (and all of its mobile
>>> variant intances), of a given Push Application:
>>> > >
>>> > > curl -v -H "Accept: application/json" -H "Content-type:
>>> application/json" -X POST -d '{"key":"blah", "alert":"HELLO!"}'
>>> http://SERVER/sender/broadcast/{PushApplicationID}<http://server/sender/broadcast/%7BPushApplicationID%7D>(
>>> http://SERVER/sender/broadcast/%7BPushApplicationID%7D<http://server/sender/broadcast/%7BPushApplicationID%7D>
>>> )
>>> > >
>>> > > Sends a JSON map to the server. If platform specific key words (e.g.
>>> alert for APNs) are used, they are honored for the specific platform. This
>>> transformation is done by the AeroGear Unified Push Server.
>>> > >
>>> > > Variant specific Broadcast
>>> > >
>>> > > Sends a push message to only one mobile variants (and all of its
>>> mobile variant intances).:
>>> > >
>>> > > curl -v -H "Accept: application/json" -H "Content-type:
>>> application/json" -X POST -d '{"key":"blah", "alert":"HELLO!"}'
>>> http://SERVER/sender/broadcast/variant/{MobileVariantID}<http://server/sender/broadcast/variant/%7BMobileVariantID%7D>(
>>> http://SERVER/sender/broadcast/variant/%7BMobileVariantID%7D<http://server/sender/broadcast/variant/%7BMobileVariantID%7D>
>>> )
>>> > >
>>> > > Sends a JSON map to the server. If platform specific key words (e.g.
>>> alert for APNs) are used, they are honored for the specific platform. This
>>> transformation is done by the AeroGear Unified Push Server.
>>> > >
>>> > > Selected Sender
>>> > >
>>> > > Sends a push message to a selected list of identified users
>>> (regardless of their variant):
>>> > >
>>> > > curl -v -H "Accept: application/json" -H "Content-type:
>>> application/json" -X POST -d '{ alias: ["user(a)foo.com (mailto:
>>> user(a)foo.com)", "bar(a)moz.org (mailto:bar@moz.org)", ....], message:
>>> {"key":"blah", "alert":"HELLO!"} }' http://SERVER/sender/selected<http://server/sender/selected>
>>> > >
>>> > > The alias value is used to identied the desired users. The payload
>>> (messages) is a standard JSON map. If platform specific key words (e.g.
>>> alert for APNs) are used, they are honored for the specific platform. This
>>> transformation is done by the AeroGear Unified Push Server.
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Matthias Wessendorf
>>> >
>>> > blog: http://matthiaswessendorf.wordpress.com/
>>> > sessions: http://www.slideshare.net/mwessendorf
>>> > twitter: http://twitter.com/mwessendorf
>>> > _______________________________________________
>>> > aerogear-dev mailing list
>>> > aerogear-dev(a)lists.jboss.org (mailto:aerogear-dev@lists.jboss.org)
>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> 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
11 years
[simplepush] Netty Subsystem
by Daniel Bevenius
This thread will discuss our deployment strategy for the SimplePush Server
with AS7.x/WildFly.
A description of the goals of this subsystem and its usage can be found in
the readme:
https://github.com/danbev/netty-subsystem
As described in the readme, we want to have a way of running Netty based
servers, but have them managed by AS7.x/WildFly. What we mean is that
things like network interfaces, ports, thread factories, etc. should be
configurable and managed by the application server.
So, we are trying to find a user friendly way of doing this and at the same
time make sure we play nicely with the application server when it comes to
resources usage.
The current implementation far from ready, but we'd like to get feedback on
our approach sooner rather than later.
Let us know if you have any comments/suggestions!
/Dan
11 years
Android Cookbook Project
by Daniel Passos
Hey Guys,
When I was reviewing the site documentation, I had the idea of creating an
app to test the code samples used in the documentation.
For each document, I've created a separate Activity isolating that
functionality to be tested. This approach helped me to discover some
problems in our libraries and fix some bugs in our documentation.
Currently I'm using this application to test every new functionality we
create on the android lib.
I thought about making this application available to community kinda like a
cookbook.
Wdyt?
https://github.com/danielpassos/aerogear-android-guides
--
Daniel Passos
11 years
