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, 3 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/
8 years, 11 months
Differences between Firefox OS "native" Push lib and AeroGear's Push adapter
by Sebastien Blanc
Hi,
While playing today with my Firefox Device and its native Simple Push
support I noticed some differences between our implementation and the
native Push regarding the success callback after a register :
//Native FFOS Push
broadcastRequest = navigator.push.register();
broadcastRequest.onsuccess = function (event) {
broadcastEndpoint = broadcastRequest.result; // only contains the pushURL
}
//Aerogear Push Adapter
broadcastRequest = navigator.push.register();
broadcastRequest.onsuccess = function (event) {
broadcastEndpoint = broadcastRequest.result.pushEndpoint;
channelID = broadcastRequest.result.channelID;
version = broadcastRequest.result.version;
status = broadcastRequest.result.status
}
So, the AeroGear Push exposes much more in the callback that it should
suppose to do : just exposing the pushEndpoint.
The reason we do that I suppose, but Luke or Kris could confirm that, is
that we thought respecting the SPS protocol, which indeed returns a whole
object containing all the info. It is just that the Native Push Client API
filter that out in the callback response.
After discussing that on the #push channel with the Mozilla people they
confirmed me that we should only expoe the pushEndpoint.
If we keep it as is, this can be problematic when we want to use the same
code both for native and with the adapter when, for instance, registering
to the UPS :
broadcastRequest = navigator.push.register();
broadcastRequest.onsuccess = function (event) {
broadcastEndpoint = event.target.result;
var broadCastSettings = {
metadata: {
deviceToken: broadcastEndpoint.channelID,
simplePushEndpoint: broadcastEndpoint.pushEndpoint
}
}
UPClient.registerWithPushServer(broadCastSettings);
}
This won't work with the native push since "broadcastEndpoint.channelID"
will be undefined.
So I propose that we change the behaviour, to return only the pushEndpoint
in the callback, even if that means a bit of String manipulation when we
want to perform the registration to the UPS :
var broadCastSettings = {
metadata: {
deviceToken:
broadcastEndpoint.substr(broadcastEndpoint.lastIndexOf('/') + 1),
simplePushEndpoint: broadcastEndpoint
}
}
wdyt ?
Seb
ps : our SPS Server implementation stays correct and returns what should be
returned, it's really just the client part and how we expose the result
9 years, 1 month
Issues with Aerogear on Cordova
by Miguel Lemos
Hello,
I'm still struggling, for saying the least, with Aerogear documentation in
order to make a Cordova / Android app receive push notifications.
Amazingly one of the most unexpected issues has been with the correct
string to use on URLs to register or sending the notifications.
Examples given by documentation:
Openshift:
curl -u "{PushApplicationID}:{MasterSecret}"
-v -H "Accept: application/json" -H "Content-type: application/json"
-X POST
-d '{
"someKey":"someValue",
"alert":"HELLO!",
"sound":"default",
"badge":7,
"simple-push":"version=123"
}'
http://SERVER:PORT/CONTEXT/rest/sender/broadcast
Aerogear:
curl -3 -u "{pushApplicationID}:{masterSecret}"
-v -H "Accept: application/json" -H "Content-type: application/json"
-X POST -d '{"message": {"alert":"AeroGear UnifiedPush and Apache
Cordova 3.0.6", "badge":1}}'
https://SERVER:PORT/CONTEXT/rest/sender
How the above examples, apparently mean that, in my case, I must use
something like: https://aerogear-metalpush.rhcloud.com/rest/sender
maybe is very obvious for someone inside Aerogear lingo, but not at all for
me...
Anyway, after I managed to overcome this, the answer I get from the server
is this one (stripped from more irrelevant parts):
> POST /rest/sender HTTP/1.1
> Authorization: Basic
MDBhMjFjZTMtYTdkOS00YzhjLWI1ODMtOWYwMjEwYTYzNGU1Ojk0MTE4NmIzLWVjNmEtNGY0OC1iMjZiLTJkMDYxZWIyM2Q5Yg==
> User-Agent: curl/7.30.0
> Host: aerogear-metalpush.rhcloud.com
> Accept: application/json
> Content-type: application/json
> Content-Length: 50
>
} [data not shown]
* upload completely sent off: 50 out of 50 bytes
< HTTP/1.1 200 OK
< Date: Tue, 18 Feb 2014 20:58:18 GMT
* Server Apache-Coyote/1.1 is not blacklisted
< Server: Apache-Coyote/1.1
< Content-Type: application/json
< Content-Length: 13
< Vary: Accept-Encoding
<
{ [data not shown]
100 63 100 13 100 50 11 44 0:00:01 0:00:01 --:--:--
44Job submitted
* Connection #0 to host aerogear-metalpush.rhcloud.com left intact
As far as I can guess, this means that the request was accepted.
Nevertheless, I receive nothing on the client's side.
On my phone the successHandler function throws a success message, meaning
that the equipment has managed to register at the service.
And my code to receive the notifications is the same given in some examples:
function onNotification(e) {
alert(e.alert);
)
But nothing happens, tough. Thanks for giving me some clues to solve this.
Miguel
9 years, 2 months
aerogear.org revamp: team work
by Corinne Krych
Hello All,
With aerogear web site roadmap [1] proposal we can start working together toward a new website. We already have a common branch (named sass - maybe not the best name) [2] where we can work together. It’s important to rebase/keep this branch up to date.
Here is how we could work together efficiently:
- take JIRA for 0.1.0 release,
- branch from sass branch, do you work
- send PR againt sass.
- usual PR review
- then PR can be merged into sass.
If a ticket requires changes in page documentation like splitting a markdown page into several pages or move to asciidoc format etc… we should do this JIRA initial in master branch, send a PRL, get the PR merged and get the changes in sass branch. This way we can keep history and let the documentation evolves without fear for merging it into new site revamp branch.
Thought? #agreed?
++
Corinne
[1] http://aerogear.org/docs/planning/roadmaps/AeroGearWebSite/
[2 https://github.com/aerogear/aerogear.org/tree/sass
9 years, 5 months
cordova push plugin simplification
by Erik Jan de Wit
Hi,
As you may have experienced or seen the cordova push plugin is not always simple to get started with, there are still some things that are platform specific even though compared to the ‘original’ it has improved there is room for improvement. Here are some suggestions to make it even simpler:
Right now the API looks like this:
var pushConfig = {
// senderID is only used in the Android/GCM case
senderID: "<senderID e.g Google Project ID only for android>",
pushServerURL: "<pushServerURL e.g http(s)//host:port/context >",
variantID: "<variantID e.g. 1234456-234320>",
variantSecret: "<variantSecret e.g. 1234456-234320>",
alias: "<alias e.g. a username or an email address optional>"
}
//badge and sound are iOS specific, and ignored on Android
push.register(successHandler, errorHandler, {"badge": "true", "sound": "true",
"ecb": "onNotification", pushConfig: pushConfig});
Suggestion number one, is to remove the successHandler and use that as the callback for notifications:
push.register(onNotification, errorHandler, {"badge": "true", "sound": "true", pushConfig: pushConfig});
Now the Javascript can verify that the callback is a function because it’s no longer a string and the need for a separate successHandler is overrated as you will either get messages or your errorHandler gets invoked.
For iOS we have these badge and sound flags we could we get rid of those as well? When you don’t want a badge then just don’t send it in the message!? Then the pushConfig can be inlined making it look like this:
push.register(onNotification, errorHandler, {
// senderID is only used in the Android/GCM case
senderID: "<senderID e.g Google Project ID only for android>",
pushServerURL: "<pushServerURL e.g http(s)//host:port/context >",
variantID: "<variantID e.g. 1234456-234320>",
variantSecret: "<variantSecret e.g. 1234456-234320>",
alias: "<alias e.g. a username or an email address optional>"
});
Till now all these changes can be made on the plugin, but we could take it even further. Two things that are still platform dependent the senderId and the variantID/secret. Now senderId is ‘known’ by UPS so why do we need to specify it here? We could make senderId part of the response when registering a device on UPS then the client doesn’t need to specify it and all configuration is in one place.
That leaves variantID/secret and that is the boldest proposal. How about we make it possible to register for an application instead for a specific variant? Then based on the meta information (deviceType, operatingSystem and osVersion) we choose the right variant.
If we do all of the above there will be no platform specific code at all and the final script could look as simple as this:
push.register(function(event) {
alert(event.alert);
},
function(error) {
throw error;
}, {
pushServerURL: "<pushServerURL e.g http(s)//host:port/context >",
applicationID: "<applicationID e.g. 1234456-234320>",
secret: "<secret e.g. 1234456-234320>",
alias: "<alias e.g. a username or an email address optional>"
});
Push notifications in one statement for all devices :)
WDYT
Erik Jan
9 years, 6 months
AeroGear project structure and the website
by Hylke Bons
Hey everyone,
So we've been doing continuous improvements to the website. Corinne and
Erik have been making some awesome progress shaping up the new
documentation section (roadmap here:
http://aerogear.org/docs/planning/roadmaps/AeroGearWebSite/) according
to the mockups
(https://raw2.github.com/hbons/aerogear-design/master/website-restructure/...).
We've split stuff up into "Setup Howtos", "Examples", "API
Documentation" and "Guides". I don't think there was much controversy
here and there's been made some headway already in unifying some of the
documentation.
The most important change in the website mockups was that instead of
focusing on platform branding, the focus is on solving use cases that
"we happen to support on these platforms". So Core/Push/Security are the
main players over iOS/Android/JS, although these are still referenced
everywhere and presented in a graphic on top of the home page.
Before we can work on the project homepage sections and download areas
of the website we should have a discussion about how the AeroGear
project itself is structured. The project seems to have grown
organically and new modules have been added here and there. There are
some of these that make the structure of the project more complicated
that it needs to be (in my opinion) to present it in a simple way to
developers visiting the website.
I've done some research on the project structure and have written down
the findings, as well as points where there's room for improvement and
possible solutions, here: http://oksoclap.com/p/AeroGearModuleUntangling
TL;DR: The most important questions that we need to answer are these:
- "If I download a library on one platform, what must I download to use
the same features on an other platform?"
-"Is this a part I use on the client, or on the server side?"
-"What do we mean when talking about different AeroGear
subprojects/modules?"
One solution might be:
https://raw2.github.com/hbons/aerogear-design/master/website-restructure/...
I've made a lot of assumptions here, and it might not work, but I'd like
to hear your thoughts on it.
It would clarify a lot if we could harmonise the different downloads
across platforms, either by providing single download solutions or
splitting everything up and naming all the parts consistently. I'm
interested in what the technical issues might be, as I wasn't around
when most of these decisions were made, or I simply missed them.
Thoughts or other ideas? :)
Thanks,
Hylke
9 years, 6 months
Let's change the AeroGear Twitter account handle
by Hylke Bons
"@AeroGears" can cause confusion about what the project name really is.
Options to fix:
- Ask the owner of @AeroGear if he or she want to give up the handle
- Change the handle to "@AeroGearTeam" or "@AeroGearProject", or
something else
Thoughts?
Hylke
9 years, 6 months
