@aerogears twitter feed
by Douglas Campos
So Jay just asked me why the @aerogears twitter account havent had a
single update in 73 days - well, that's because I failed miserably about
it :(
How do we want to make use of this channel? I don't think being spammy
is wise, but we need more tweets there for sure :P
Do y'all have suggestions wrt general guidelines on what to post, beyond
the releases we make?
kthxbai
--
qmx
10 years, 11 months
[ag-controller] Deprecating AeroGear-Controller
by Daniel Bevenius
Originally, AeroGear Controller was an MVC only implementation, where
requests could be forwarded to different types of views. Later we added
support for RESTful endpoints which was very basic to start with, but more
and more feature requests have come which is the reason for creating this
email.
We did not set out to implement the RESTful support our selves, instead the
goal was to use RestEasy but as we required to be able to programmatically
add endpoints which was not an option at the time (but support for this
does now exist in RestEasy).
AeroGear controller's REST support started out very simple but as time
passed more request for things that are taken for granted in a JAX-RS
implementation were being asked for. We were moving toward something
equivalent to a JAX-RS implementation with regards to what we supported.
Adding more of these features added to the complexity of the Controller as
we needed to figure out good ways to provide the features requested, and
this also brings up the question if we should be doing this. The controller
is not specific to mobil, as any backend can be used with the client SDKs.
Also, there are plenty of options to implement RESTful backends, in Java
using RestEasy for example, or in a different language.
And after some discussions it has been decided that we should focus are
efforts in other places when it comes to our server side offerings, for
example the Unified Push Server and SimplePush Server etc.
So how do we make it visible that we have deprecated AeroGear-Controller?
A clear notice in the README.md is a good start. Should we mark every class
as deprecated as well?
These are just suggestions and if you have other ideas please let us know.
/Dan
10 years, 11 months
Versioning
by Kris Borchers
So we haven't talked about this for a while so I thought I would stir the fire again. Does anyone have any objection to JS managing our versions as such:
I would like to move what is currently in master to a 1-0-stable branch
Then I would like to update master's build version to 1.1.0-pre
All work is done on the master branch then if the change is applicable to 1.0.0, it can be cherry-picked into the 1-0-stable branch
Then, going forward:
Any patch releases for 1.0.x would come from the 1-0-stable branch
When 1.1.0 is released, the new version would be tagged from master, then branched into a 1-1-stable branch, then the 1-0-stable branch would be deleted
Master would then be updated to 1.2.0-pre
The biggest reason for this is it allows continued work on new features to be merged into their release version from their development branch when ready, rather than waiting until right before a release to put it all together. If we don't do that, and merge something like Notifier into master when it's "ready", we can no longer release maintenance versions for the current stable release because those new features would be included.
Thoughts?
10 years, 11 months
Unified Message format (was: Re: AeroGear Push Message Format)
by Matthias Wessendorf
based on the "unification issues" (see old thread), Dan, Kris and I met
here is what we have come up with:
Draft for the AeroGear Push Message Format
The Unified Push Server allows two different ways to send message to the
native Push API, of the supported devices:
- broadcast
- to all MobileVariants and their MobileVariant Instances (devices)
- to one specific MobileVariant and its MobileVariant Instances
(devices)
- selective Send
<https://gist.github.com/matzew/d6f1b88b85e2f6c18031#broadcast>Broadcast
curl -v -H "Accept: application/json" -H "Content-type: application/json"
-H "ag-push-application: {PushApplicationID}
-H "ag-mobile-variant: {MobileVariantID}
-X POST
-d '{"key":"value", "alert":"HELLO!", "sound":"default", "badge":7,
"simple-push":"version=123"}'
http://localhost:8080/ag-push/rest/sender/broadcast
If the ag-push-application header is used, a message is send to a
PushApplication and *ALL*MobileVariantInstances will receive the message.
If the ag-mobile-variant header is used, a message is send to a particular
MobileVariant and *ALL* of its MobileVariantInstances will receive the
message.
<https://gist.github.com/matzew/d6f1b88b85e2f6c18031#message-format>Message
Format
The message format is very simple: A generic JSON map is used to send
messages to Android and iOS devices. The applications on the devices will
receive the JSON map and are responsible for performing a lookup to read
values of the given keys.
<https://gist.github.com/matzew/d6f1b88b85e2f6c18031#simplepush-special-keys>SimplePush
special keys
Every AeroGear-SimplePush application can subscribe to a broadcast channel.
If, on the abovebroadcast Endpoint, you are providing the simple-push key,
the version (that's what SimplePush is really about), is extracted and send
to ALL "connected" broadcast channels, of the given SimplePush variant(s). *
NOTE:* On all other platforms, the simple-push key will be simply :-)
ignored. Also, for SimplePush, all *OTHER* keys are ignored (since that
does not make sense for SP).
<https://gist.github.com/matzew/d6f1b88b85e2f6c18031#ios-special-keys>iOS
special keys
If the JSON map contains on of the following reserved keywords, Apple
specific hooks will be invoked on the device:
- alert (triggers a dialog, displaying the value - no iOS API needs to
be invoked by the app developer)
- sound (plays a given sound - no iOS API needs to be invoked by the app
developer)
- badge (sets the value of the badge icon - no iOS API needs to be
invoked by the app developer)
<https://gist.github.com/matzew/d6f1b88b85e2f6c18031#android-special-keys>Android
special keys
None! The JSON map is submitted as it is, directly to the device. There are
no Android specific keywords.
<https://gist.github.com/matzew/d6f1b88b85e2f6c18031#selective-send>Selective
Send
A message is send to a restricted number of MobileVariantInstances, based
on a given criteria. The following example shows the correspondent HTTP
interface:
curl -v -H "Accept: application/json" -H "Content-type: application/json"
-X POST
-d '{
"alias" : ["user(a)account.com", "jay(a)redhat.org", ....],
"deviceType" : ["iPad", "AndroidTablet"],
"message": {"key":"value", "key2":"other value", "alert":"HELLO!",
"simple-push": { "SomeCategory":"version=123",
"anotherCategory":"version=456"}
}
}'
http://localhost:8080/ag-push/rest/sender/selected/{PushApplicationID}
<https://gist.github.com/matzew/d6f1b88b85e2f6c18031#message-format-1>Message
Format
Besides the actual payload the API accepts a few *classifiers* to select a
subset of registered devices.
<https://gist.github.com/matzew/d6f1b88b85e2f6c18031#query-component>Query
component
Currently the Server will support the following query criterias:
- alias: A list of email address (or usernames) to send messages to
*ALL* devices
of the users. Thealias needs to be stored, when the device is
registering itself with the server. See here for
details<https://github.com/matzew/ag-client-push-sdk/blob/master/push-sdk/AGClien...>
- deviceType: A list of raw devices types that should receive the
message (e.g. Coupon only for iPad and AndroidTablets). The deviceType needs
to be stored, when the device is registering itself with the server. See
here for details<https://github.com/matzew/ag-client-push-sdk/blob/master/push-sdk/AGClien...>
. *NOTE:* For SimplePush, the deviceType is *ONLY* web. No specifics on
the actual device are used due to general limitations on "user agent
sniffing".
<https://gist.github.com/matzew/d6f1b88b85e2f6c18031#message-payload>Message
Payload
The message format is very simple: A generic JSON map is used to send
messages to Android and iOS devices. The applications on the devices will
receive the JSON map and are responsible for performing a lookup to read
values of the given keys. Like above, iOS specific keywords are honored.
<https://gist.github.com/matzew/d6f1b88b85e2f6c18031#simplepush>SimplePush
For SimplePush an extra simple-push object is provided. Only for SimplePush
Variants this key is used (similar to the broadcast case). However *HERE* we
use an object, to send (selective) different versions to different channels.
'Thoughts ??
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
10 years, 11 months
