AeroGear Crypto Java 0.1.2 released
by Bruno Oliveira
Good morning, just to let you know we released today the bits for digital signatures and some bug fixes.
Have a happy new year sweet hearts.
--
abstractj
1 year, 11 months
Chrome Push Messages
by Lucas Holmquist
Hello,
now that the 1.0.0-final is pretty much out for the UnifiedPush Server, i’m starting to look at the new API that Chrome apps use for sending push notifications.
the TL;DR of it is, it’s basically the same as Android now.( no more refresh tokens and access tokens and such )
So the question is, do we need to have a deprecation period on what is currently there?
The v1 of the chrome pushMessaging api has become legacy and it is recommended to use the new stuff. https://developer.chrome.com/apps/cloudMessagingV1
While i have looked to deeply, it’s possible we can use the same “Variant” structure for Chrome Apps, Since they will be using the same Network
wdyt?
-Luke
9 years, 2 months
text/html Requests instead of application/json
by Marc Pires
Hi guys, i'm having a little trouble with an app i'm developing. Doing a
post request against an API, I receive from the server that my request is
going as text/html instead application/json, text/javascript or text/json
that the API expects.
As I never had this problem before, i research the docs but did not found
the reference yet, so how can i define my request to go as application/json
instead text/html
--
Desenvolvedor IOS, Rails, RIA
http://www.linkedin.com/in/marcpires
http://about.me/marcelo_pires
9 years, 5 months
message format change proposal
by Erik Jan de Wit
Hi,
With the upcoming windows support and simple push change (making simple push more like 'normal') the number of ‘special’ keys in our message is increasing. Right now we are mixing our ‘special’ keys with those the user can add, but we keep simple push out of it:
{
"variants" : ["c3f0a94f-48de-4b77-a08e-68114460857e", "444939cd-ae63-4ce1-96a4-de74b77e3737" ....],
"alias" : ["user(a)account.com", "someone(a)aerogear.org", ....],
"categories" : ["someCategory", "otherCategory"],
"deviceType" : ["iPad", "AndroidTablet"],
"ttl" : 3600,
"message": {
"alert":"HELLO!",
"sound":"default",
"badge":7,
"content-available" : true,
"action-category" : "some_category",
"someKey":"some value",
"anotherCustomKey":"some other value"
},
"simple-push": "version=123”
}
As simple push is going to be more like ‘normal’ push why not move the simple-push into the message as well. As for the windows support there are a lot more types of messages you can send. The most normal form is called ‘toast’, but there are other ones for when you app is pinned to the home screen. Then one can send message that contain pictures. To support all of this we need something like this: https://gist.github.com/edewit/305d76c31960aa6254a9
Adding all these ‘special’ keys will make it easier to get into a conflict with the users own data, so I propose we put the user data into a separate data object, like so:
{
"variants" : ["c3f0a94f-48de-4b77-a08e-68114460857e", "444939cd-ae63-4ce1-96a4-de74b77e3737" ....],
"alias" : ["user(a)account.com", "someone(a)aerogear.org", ....],
"categories" : ["someCategory", "otherCategory"],
"deviceType" : ["iPad", "AndroidTablet"],
"ttl" : 3600,
"message": {
"alert":"HELLO!",
"sound":"default",
"badge":7,
"content-available" : true,
"action-category" : "some_category",
"simple-push": "version=123",
"data" : {
"someKey":"some value",
"anotherCustomKey":"some other value"
}
}
}
WDYT?
Cheers,
Erik Jan
9 years, 6 months
[UPS] Proposal to change the Push Message Format
by Sebastien Blanc
Hi,
I was looking at our current Push Message Format[1] and I was wonderimg if
you should not add some more structure to it, decoupling config, criterias
and the message itself :
{
"config" : {
"ttl" : 3600,
"content-available" : true,
"simple-push": "version=123"
},
"criteria" : {
"alias" : ["user(a)account.com", "someone(a)aerogear.org", ....],
"categories" : ["someCategory", "otherCategory"],
"deviceType" : ["iPad", "AndroidTablet"],
"variants" : ["c3f0a94f-48de-4b77-a08e-68114460857e",
"444939cd-ae63-4ce1-96a4-de74b77e3737"]
}
,
"message": {
"alert":"HELLO!",
"sound":"default",
"badge":7,
"someKey":"some value",
"anotherCustomKey":"some other value"
},
}
wdyt ?
Sebi
[1]http://aerogear.org/docs/specs/aerogear-push-messages/
9 years, 6 months
REST-based API Versioning
by Matthias Wessendorf
Hello,
for the 1.1.x (master) we are potentially doing some changes on the
Sender-API (see [1]).
However, for backwards compatibility we need to think about API versioning.
For REST APIs there are (IMO) two options:
* accept header
* URIs
On our Face2Face meeting we briefly talked about this and I think the
"accept header" solution was the one that had most fans. I think QMX added
that it is better for migration. One thing we were not clear on (I think):
What are HATEOS defined semantics?
Besides the what (headers vs. URI), I think we should think about possible
implementations, to switch different versions.
Not sure, but wouldn't it be possible to inject an annotated SenderService
into the RESTful endpoint, based on header values ?
We could have a default impl (version 1.0.0) and an alternate one, that is
injected if the accept header indicate API version 1.1
Any thoughts ?
-Matthias
[1] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008881.html
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
9 years, 7 months
Branches on UnifiedPush GH repo
by Matthias Wessendorf
Hi,
now that we have released the 1.0.0.Final, there are two 'important'
branches:
* master (current version is 1.1.0-SNAPSHOT)
* 1.0.x (current version is 1.0.1-SNAPSHOT)
This email is to clarify what goes in where, or tries to :-)
I think it's quite simple. Every fix that goes into the "1.0.x branch"
needs to go into the "master branch" as well.
Once a PR has been merged to 1.0.x branch, it's the responsibility of the
PR filer to rebase against (latest) master as well, to make sure the merge
to master works without any trouble!
While 1.0.x is really meant for bug fixes and improvements only, the new
development is going on in master (for 1.1.0-SNAPSHOT, and later) and
therefore fixes that are scheduled for 1.1.x only, should not go into the
the 1.0.x branch.
The scheudling is done via JIRA and almost all commits/merges should have
JIRA tickets attached.
Currently here are the 1.0.x related tickets:
https://issues.jboss.org/browse/AGPUSH/fixforversion/12325080/
https://issues.jboss.org/browse/AGPUSH/fixforversion/12325448
As you can see, they all have the 1.1.x version label as well. This is
important and ensures (critical) bug fixes to 1.0.x are also arriving on
the master branch!
The JIRAs that are scheduled for 1.1.0 are listed here:
https://issues.jboss.org/browse/AGPUSH/fixforversion/12323762/
Of course, due to the backport requirement, some of these tickets contain
1.0.x labels on their Fix-Versions as well - but some are exclusively
scheduled for 1.1.0, and therefore only go to master branch.
Any thoughts ?
-Matthias
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
9 years, 8 months
