iOS AeroGear 2.0.0 is on its way
by Corinne Krych
Hello Swift lovers,
AeroGear iOS 2.0.0 is coming soon… It’s ready for you to test and it's all in Swift.
But what does it mean for AerGear iOS users?
More than just a Swift version, 2.0.0 brings major changes:
- modularization: AeroGear-iOS repo is splitted in several smaller libs.
- deprecated Pipe: http calls use lean aerogear-ios-http directly built on top of NSURLSession offering a convenient API for accessing RESTful services. [1]
- enhance OAuth2 module with support for Google, Facebook, Keyclaok and a pluggable system to provide support for your own favourite provider. [2]
- backend demo for Keycloak OAuth2 integration. Check out Shoot'nShare demo, read this blog post for more details. [3]
- and Swift based: we've been working on it since Swift birth, last june, we went through updating code base to support latest Xcode6.1 version. Come and share the Swift adventure with us, give it a trial and send us feedback.
++
Corinne && Christos
[1] https://github.com/aerogear/aerogear-ios-http
[2] https://github.com/aerogear/aerogear-ios-oauth2
[3] http://corinnekrych.org/2014/10/aerogear-with-keycloak-oauth2-friends.html
10 years, 11 months
iOS AeroGear 1.6.1 is out!
by Corinne Krych
Hello iOS lovers,
We're glad to announce that AeroGear-iOS 1.6.1 is out.
This minor release is mainly about upgrading and supporting iOS8 with Xcode 6. See JIRA tickets [1]. This release is the last one in 1.x series, next release will be 2.0.0.
You can use either Xcode5 or the latest Xcode 6.1 to compile your code using AseroGear-iOS 1.6.1 libs. The Xcode template to generate your project can be used with Xcode 5.1 or with Xcode6.1.
Enjoy and let us know how you like it :)
++
Corinne && Christos
[1] https://issues.jboss.org/browse/AGIOS-281?jql=fixVersion%20%3D%201.6.1%20...
10 years, 11 months
OAuth2 demo app, let's use Shoot'nShare!
by Corinne Krych
Hello Guys,
Aerogear iOS 2.0 release main focus being on OAuth2, this relase, we worked on an OAuth2 demo. We actually reuse Shoot app and extend it with a backend to demo Keycloak too.
Main idea is that for OAuth2 we demo external providers: Google, Facebook (and Twitter should come next) and Keycloak. We’ve enhanced it with a web-app too. So that’s once the photo get uploaded you can view on desktop web-app. It’s nice to demo the 2 keyclaok adapters (wildfly and js adapter). See backend demo [1]
@summers, passos: It would be nice to have an Android similar demo, wdyt?
@lfryc @lholmquist should we use keyclaok.js only or is there a way to use ag.js? btw, your review is welcome on the js-angular part.
++
Corinne
[1] https://github.com/corinnekrych/aerogear-backend-cookbook/blob/master/Sho...
PS: do you like kittens?
10 years, 11 months
Sync on Android
by Summers Pittman
TL;DR; Watch this repo over the next few days :
https://github.com/secondsun/aerogear-sync-server/tree/xmpp-diff-sync
Currently I am researching integrating the sync client technology that
DanBev, LolQuist et al have been working on into Android all proper
like. Danbev wrote a POC demo a while ago* which uses the Java
websocket client. This seems to work "OK" but there is a lot of work
getting websockets working right on Android. However, Google has a two
way messaging protocol built into Google Play Services on top of GCM.
This is the technology I am trying to introduce to the sync systems in
this branch.
This branch includes a fork of the server library and a fork of the
client library which interact with GCM on the client and XMPP on the
server side. Right now it compiles and not much else. However, because
the server is decoupled from the connection handling, adding in the
correct hooks has been rather simple. There are going to be some issues
to hammer out once this gets past "compiling" and makes it into "demoable".
First, the server does not receive implicit connect/disconnect messages
from Google per device. Google does send Ack/Nack messages however so
with some bookkeeping connections/shadows/etc can be properly
maintained. There is a similar mechanism on the client side; however,
we may need to expand the sync protocol to include some kind of heartbeat.
Second, the sync server isn't multitenant. This means that until we
figure out how to merge, things listening to WebSockets don't hear
things listening to XMPP or see updates from one to the other.
Finally, Google Play Services is not FOSS by any stretch of the
imagination. However, having a single connection managed by the OS is
great for usability, speed of development, battery life, etc so I feel
like this is more getting mileage out of the chunk of my soul I tossed
in the black Googley shredder for UPS and less of a deal breaker.
As I've said right now, today, this code is work in progress. Soon it
will be proof of concept and we can discuss how to work around these
issues and merge the ideas back into mainline.
--
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.
PS: WebSocket's biggest problems are maintaining connections and
performing message redelivery in a sporatic connection scenario. This is
one of those things which is a lot of work to get right both on our end
as service providers and on the developer's end as consumers.
Additionally, Android L is going to include a lot more end user
configurability which will affect when/how messages are delivered. To
do WebSockets right we will have to respect those settings as well. It
is my assumption (we all know what that means) that Google Play Services
will correctly enforce data/power settings out of the box as well as
correctly maintain messaging connections and delivery.
10 years, 11 months
Using existing Keycloak installation with Aerogear
by ekolesnikov
Hi,
Apologies for writing straight into DEV forums - I was unable to locate
"aerogear-users" mailing list anywhere. Please feel free to point me to the
right direction if this mailing list is inappropriate for questions like
this.
Is it possible to use/integrate Aerogear with existing Keycloak
installation? We are already using Keycloak for all things auth in our
application and have found ourselves in the situation where we potentially
have to manage separate infrastructure - which makes the whole point of
using Keycloak a bit irrelevant.
As an alternative, we could consider using Keycloak supplied with with
Aerogear - unfortunately, it looks like Aerogear has disabled Keycloak
option to create additional realms.
I would really appreciate it if you could share your thought on this.
Thanks
Egor
--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Using-existing-Keycloak-install...
Sent from the aerogear-dev mailing list archive at Nabble.com.
10 years, 11 months
Admin endpoints
by Bruno Oliveira
Good morning, moving forward with
https://issues.jboss.org/browse/AGPUSH-1036. What is the most
recommended approach for admin-ui.
Have separated endpoints for the admin like:
1.
@RolesAllowed("admin")
@Path("/admin/applications")
public class AdminApplicationEndpoint extends AbstractBaseEndpoint {
@GET
@Produces(MediaType.APPLICATION_JSON)
public Response listAllPushApplications(){
//queries
}
}
Or introduce a new method inside the current PushApplicationEndpoint:
2.
@GET
@Produces(MediaType.APPLICATION_JSON)
@RolesAllowed("admin")
public Response listAllPushApplications(){
//queries
}
// READ
@GET
@Produces(MediaType.APPLICATION_JSON)
public Response listAllPushApplicationsByUsername(@Context HttpServletRequest request) {
return Response.ok(pushAppService.findAllPushApplicationsForDeveloper(extractUsername(request))).build();
}
If the option 2 is the correct. How the Angular.js service would look
like? Once the username is not informed as argument on
pushApplicationService.js, because for obvious reasons it can be
retrieved with HttpServletRequest.
One of my poor ideas due to my "amazing" Angular skills would be to do
something like:
@GET
@Produces(MediaType.APPLICATION_JSON)
@RolesAllowed("admin")
@Path("/all")
public Response listAllPushApplications(){
//queries
}
And:
backendMod.factory('pushApplication', function ($resource) {
return $resource('rest/applications/all/:verb', {
.....
Help?
--
abstractj
PGP: 0x84DC9914
10 years, 12 months
