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
2 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/
10 years, 1 month
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
10 years, 4 months
Modularizing the Android Library
by Summers Pittman
Earlier in development (pre passos) making the Android SDK into modules
was not a concern (in fact it was an anti-concern).
Now, however, we have a much more complete project and it is time to
have that discussion.
Right now we have two BIG questions:
1) Do we want to break out interfaces and implementation?
If we do this then we could reuse a lot of code to make a aerogear-java
as well.
2) How granular do we want our modules?
IE If we break out push into aerogear-android-push would that include
GCM, SimplePush, MQTT, etc in one package or would it look like
aerogear-android-push-core, aerogear-android-push-mqtt etc.
Thoughts?
--
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.
10 years, 4 months
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
10 years, 4 months
Building UnifiedPush Server from sources
by A577127
Hello,
I need to try some stuff with the UnifiedPush server (eg redirecting HTTP
POST requests to my own test server instead of GCM's server). However I'm
not really familiar with JBoss.
I've downloaded the sources from git here
<https://github.com/aerogear/aerogear-unifiedpush-server> and I need to do
a few things but didn't find out how to :
- Import the project to Eclipse (classic Eclipse Import doesn't show
anything)
- Build a .war deployable file (I looked for an Ant target on Github but
didn't find any)
- Edit web interface (I saw that .js file was minified ; can I get a
non-minified somewhere ?)
I know my questions are quite evasive, if I ask for too much don't hesitate
to just give me links to tutorials, I will take time to read them and try to
solve these problems myself.
Thanks,
--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Building-UnifiedPush-Server-fro...
Sent from the aerogear-dev mailing list archive at Nabble.com.
10 years, 7 months
UPS UX updates
by Hylke Bons
Hello,
https://github.com/hbons/aerogear-design/tree/master/ups-new-ux
The above link contains mockups with an updated look and feel.
I've tried to consolodate the info that we had on different pages on
fewer pages, as a common critique was that the Application Details and
Variant Details pages looked alike too much, so I've merged them.
On one page I've added a sidebar that reflects future features (it's
just for show).
Other notable things are the orange info blocks where we want app
developers to take action on information (the device registration and
sending notifications in this case). I've deliberately made these stand
out a bit more as we want people to act on the information. Please note
that one row in the variants table shows up expanded in the mockups for
illustration purposes. The rows will all be collapsed on first view, so
it won't look as cluttered as you might think at first seeing the mockup.
Let me know what you think and where we should go from here.
Thanks,
Hylke
10 years, 8 months
UnifiedPush Server: Hello World- and Quickstart Examples
by Matthias Wessendorf
Hello there,
we recently had talks about creating some simplified quickstarts and
hello-word demos, related to the UnifiedPush Server and JBoss AS developers:
* Hello World (No Server Code - just client receiving push, no fancy
(complex) UI on the client, nor integrated into a Cookbook or something
that has "dependencies")
** Cordova
** Android
For iOS that is already there:
https://github.com/aerogear/aerogear-push-ios-demo
Yes, just usage of the "Push Registration SDKs", is the goal here: keep it
simple, since native push can be a complicated use-case all on its own and
so it will be good to make sure we cover the basics here.
Beyond the Hello-World, we wanted some different quickstarts. The "server"
components that come to mind would be:
*Secured CRUD + Push Integration (Java Sender)
** JAX-RS + PicketLink
** SpringMVC/Spring Security
** JAX-RS + Apache Camel
These need to function on both JBoss AS 7.X and EAP.
Josh, from the JDF team, has already said he wants to help on the server
projects (especially the JAX-RS/PL and Spring ones). yay!
Note: Josh already has a simple backend started that is used in JDF
quickstarts that would be good to re-use to make it easier for developers
to transition from one to other.
The goal would be the SERVER acts same to outside (identical REST
endpoints, difference is only an impl. detail (e.g. JavaEE vs. Spring vs.
Camel))
For these different servers, there would be mobile apps needed:
* Android
* Cordova
* iOS
The idea would be to keep them simple and straightforward as well, e.g. for
iOS that means plain usage of NSURLConnection / NSURLSession. But for the
"push registration" of the client,
the iOS-push SDK would be used (same/similar would apply to Cordova or
Android). Similar to the above 'Hello World', the quickstarts are going to
be focused only on Push functionality, so for these we would leave out
pipes and such until later versions.
I will be creating Epics and subtasks in JIRA for this.
For the location of all these projects, I had this "uber repo" location in
mind:
* https://github.com/aerogear/aerogear-push-helloworld
* https://github.com/aerogear/aerogear-push-quickstarts
Greetings,
Matthias
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
10 years, 8 months
security updates
by Erik Jan de Wit
Hi,
Bruno has created some PR’s to update our cordova plugins to no longer support 3.0.0 but update it to 3.4.0, because of a number of security issues that have been solved. Now of course we should encourage that people use the latest version, but this PR enforces it. Also Gorkem that invested quite some time to support different versions. So what should we pick enforce or encourage?
Cheers,
Erik Jan
10 years, 8 months
