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, 2 months
UPS using JMS update
by Lukáš Fryč
Hi guys,
so as outlined in previous thread [1], I have prototyped a JMS batching
approach for push message delivery.
We've discussed the approach with Matthias, Mirek Novak and Ondrej
Chaloupka (EAP QE & JMS/JTA experts, thank you guys!) and these documents
describes a concept that we have came with:
Diagram:
https://docs.google.com/a/fryc.eu/drawings/d/13IsJWPSJNYXtst-UVxQYmzH36C_...
Text Doc:
https://docs.google.com/document/d/1X65P_U9O62Z5JZhKi9ZvBuZU1OrL4pNHNddlz...
Implementation-wise, I've so far prototyped the messaging part (split
SenderService functionality to two subsequent queues with MDBs as shown on
diagram),
but that's just a start, since we must configure it appropriately for
efficiency (queue configuration and batch sizes) and verify that
configuration works as expected,
the prototype lives on a branch (unpolished, to be squashed later):
https://github.com/lfryc/aerogear-unifiedpush-server/tree/jms-batching
Off course, you can play with it already. :-)
Apart from the new requirement of using Java EE full profile (JMS), the
prototype leverages implementation-specific configurations and APIs:
- org.hibernate.Query for token streaming / batch fetching
- HornetQ configurations of queue size, blocking behavior and message
de-duplication
That pretty much binds us to WildFly/EAP - we can tweak it to run on any
compliant app server, but without specific configurations it won't work
properly.
Once configured and functionally tested (that can even wait for Beta2 I
guess),
we can cooperate with Mobile QE on testing (Stefan, Adam), their test suite
contains mocks of APNS/GCM against which we can load test.
Cheers!
~ Lukas
[1]
http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-UnifiedPush-new-re...
8 years, 9 months
OAuth2 with native Broswer in Android
by Summers Pittman
In Android I have a solution for using the native browser to perform an
OAuth2 sign in. There are some limititions however.
In general to use this you need an activity which has an intent filter to
consume the redirect URL. This works best if you use a custom URI scheme.
Google, Yahoo, and Facebook (as well as other I'm sure) only allow
redirects to http or https. This means that unless you are using a third
party to redirect a custom schema the browser my preempt your application
and consume the redirect. Other services such as KeyCloak and Spotify
allow custom schemas and these work perfectly with my solution.
If we document the limitations of the Intent and when using an Intent vs
using a WebView is appropriate, is a solution with these limitations
adequate? I think it is.
Thoughts?
Summers
PS: a link to my poc :
https://github.com/secondsun/aerogear-android-authz/tree/AGDROID-319/
PPS: You can use this on the KeyCloakHelper in Shoot and Share by adding
`setWithIntent(true)` to the configuration in that class.
9 years, 2 months
Sender REST endpoint returns text/plain
by Lukáš Fryč
Hey guys,
one issues Tadeas identified during testing sender endpoint via Java Sender
lib is connected to this quiet change in the REST response from REST Sender
endpoint (we added text/plain response specification):
https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs...
As we were always responding with "Job submitted", admin-ui client started
to complain about the response not being JSON. So obvious fix was change
that to text/plain, right?
Not really.. some clients like Java Sender lib already expects
application/json and JAX-RS then refuses these requests:
https://github.com/aerogear/aerogear-unifiedpush-java-client/blob/master/...
The question is, what should be the correct response?
There are many options, I would be perfectly fine with 204 No Content reply,
but JSON might be more appropriate for future extensions, we may want to
return e.g. PushMessageInformation#id or something else as part of the
response.
So, wouldn't be application/json more appropriate than text/plain? We may
send empty body now {}.
Is this something we want to address for Alpha? Or should we release fixed
Java Sender lib?
Cheers,
~ Lukas
9 years, 3 months
[GSoC] Hawkular Android Client
by Artur Dryomov
Hi everyone,
This year I will be working on the Hawkular Android client application as
part of the Google Summer of Code 2015 program.
The application itself will use Hawkular API and AeroGear SDK. In coming
days I’ll research these areas, especially documentation, and will try to
create some sort of architecture and basic design.
Thank you all for this opportunity!
Artur.
9 years, 3 months
