Android Studio Support
by Summers Pittman
The new Android build tools (IE Android Studio) are still in beta, but
passos and I were thinking of adding support for them for the 1.2
release. I havn't given these tools more than a cursory look, but we
will have to support them sooner or later.
What do you guys think?
11 years, 6 months
Question on our AuthenticationModule
by Matthias Wessendorf
Hi,
perhaps this is more "AeroGear-Security VS HTTP Basic/Digest", but first
some background informations:
our different "AuthenticationModule" implementations, for Android, iOS and
JavaScript, were created for the AeroGear-Security REST-APIs, which are
described here:
http://aerogear.org/docs/specs/aerogear-rest-api/
Here are the three different client platform implementations:
* Android:
https://github.com/aerogear/aerogear-android/blob/master/src/org/jboss/ae...
* iOS:
https://github.com/aerogear/aerogear-ios/blob/master/AeroGear-iOS/AeroGea...
* JavaScript:
https://github.com/aerogear/aerogear-js/blob/master/src/authentication/ad...
So, basically the interface(or the different implementations) covers the
following functionality, described in the above spec:
* enroll
* login
* logout
So far so good.
However, looking at the recent work for BASIC/DIGEST (e.g.
http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-iOS-Basic-Digest-T...),
I think it might be confusing that there is no real login call against the
server, like in the above codee, for AG-Security
Instead, the "login", is _only_ applying the credentials to that subsequent
requests can read (a) protected URL(s). Similar to "logout": Only a _reset_
of the credentials is happening. No server endpoint is invoked.
See also http://lists.jboss.org/pipermail/aerogear-dev/2013-May/002810.html
Similar to the "enroll"; The iOS proposal throws an exception, similar to
the Android version:
https://github.com/aerogear/aerogear-android/blob/master/src/org/jboss/ae...
https://github.com/cvasilak/aerogear-ios/blob/basic.digest.auth/AeroGear-...
To me, looks like none of the methods of the "AuthenticationModule
interface" are properly used, or am I wrong?
I think my question is: Does it really make sense to kinda try to add the
BASIC/DIGEST support into the "AuthenticationModule interface"?? or, could
there be something else ?
Not sure, I guess since I am not sure, I am asking here :)
Any feedback is appreciated!
Thanks!
Matthias
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
11 years, 6 months
What is our default JDK platform?
by Karel Piwko
Hi,
Most of the code is JDK6, except PushEE which requires JDK 6. Android requires
JDK 6 API as well, thanks Summers for pointing that out. The only component
that requires JDK7 is PushEE afaict.
So, even if JDK 6 is officially EOLed (at least Oracle's one), I'd prefer to
limit our code to JDK6 features. Does it make sense?
I can setup animal sniffer plugin to enforce JDK API conformance and
send PRs if you will - btw, do you guys already have a common parent with plugin
configuration?
The other question is default runtime. Would you guys recommend JDK7 or JDK6?
I'm biased here to decide myself.
Thanks,
Karel
11 years, 6 months
Progress on Unified Push Server UI
by Hylke Bons
Hey everyone,
Here's my initial version of the AeroGeer Unified Push Server Admin UI:
https://raw.github.com/hbons/aerogear-design/master/aerogear_unified_push...
This work is based off of the features/usecases and lexicon described in
http://aerogear.org/docs/specs/aerogear-server-push/ and Matthias's
earlier wireframes.
Features:
* Developer can register a |Push Application|
* Developer can add a |Mobile Variant| for different operation systems
* Developer can remove a |Mobile Variant|
* Developer can remove |Push Application|
Currently Missing features (these will be added in the next iteration):
* Enroll |Developer|
* Remove |Developer|
* |Developer| can disable Push Notifications to selected |Mobile
Variant Instances|
* |Developer| sends /Push Notification Messages/
Potentially controversial changes:
- Using "(Hybrid Web)" as a variant name instead of "SimplePush".
Matthias and I already had a short exchange here on the mailing list
about this change, hopefully the way this is used in these wireframes
will shed some light on why I think this is a better choice.
- Checkboxes instead of a list box for variants. Since there are only
a few variant types, we don't need a full fledged list, and we can
simply use some checkboxes to toggle variants.
Let me know if you have any comments or questions!
Sources can be found in https://github.com/hbons/aerogear-design.
Looking forward to your feedback,
Hylke
11 years, 6 months
my AeroGear notes
by Yavuz Selim YILMAZ
Hi All,
I am trying out the AeroGear libraries to get a sense of them. As a newbie to the libraries, I took some notes about my first experience, and would like to share my notes with you. Comments, directions and suggestions are most welcome.
General:
- It's not clear if I can use the client libraries with my own server side, or if I can use the AeroGear controller without using the client libraries. So, my initial thought was, I definitely need the AeroGear controller to integrate my AeroGear powered client app with my RESTful backend.
- Maybe it is because the external libraries/tools used in the documentation apps releases new versions so fast, but getting the example app from github, running it on my machine and then modifying the app to play with it was harder than creating a new app and using AeroGear libs in them directly.
iOS:
- iOS API Cookbook is a really nice doc to get to know about how to use AeroGear iOS API.
- It is not clear enough how the backend side should be designed to work with client libraries, and this is problem if you start using AeroGear with client side libraries (a mobile developer will probably start so, like I did). If an iOS developer wants to use the library, she should go through AeroGear Controller docs to know how the server side should be. And here "AeroGear Controller User Guide" is not enough to figure the things out. Therefore, one needs to go through aerogear-controller-demo on github to understand the details (e.g. after struggling with how the server side APIs should be, it turned out that REST API itself was what i was looking for - so easy if it was stated clearly [see general section above for why I find this difficult]).
- xCode template is a really nice start, as it makes getting the first app running quick. But template creates a part of todo app which doesn't have authentication and therefore the app isn't functional.
Android:
- Unlike iOS development, developing Android apps and compiling them has many different alternatives. But as a maintainer of Android, Google puts Eclipse + ADT option in the first place. So, I think at least there should be an option for AeroGear to use it with Eclipse + ADT setup. Especially using community tools to build is initially harder for newbies (e.g. I tried to get maven running on eclipse using m2eclipse, and todo app does not compile on my eclipse while it does on terminal). Some bugs and configuration changes in maven, maven-android, android-sdk-deployer and m2eclipse slowed down the initial steps, i.e. it was not as quick and straightforward as AeroGear iOS API to get the first app running.
- Sending query parameters to server side is slightly different on iOS and Android (or maybe I couldn't find the same way, but Android sends where clause as JSON object, while iOS sends key-value pairs as HTTP GET query parameters). So, I needed to update my server side (which i developed for iOS) to use it for Android (or I could build my where clause in iOS manually).
HTML5:
- As AeroGear.js uses AJAX to connect to the backend, and in my case (also I believe in most cases) as my RESTful endpoint was not residing on the same host with my app, I needed to use jsonp data type, which requires different response format. Therefore I needed to update my server side (again - it was designed for iOS and updated for Android).
- When I create a pipe, I specify the baseURL and my endpoint, but I needed to specify the data type when I was actually reading from the pipe. I felt like if I know what my endpoint returns in terms of its data and application type, then I should be able to set data type while creating my pipe.
- Although documentation is not complete yet, AeroGear.js file is well commented (going through the comments, it's easy to understand what and how to do).
Hybrid with Cordova:
- The documentation for converting HTML5 + REST apps to Hybrid apps uses some directory names (e.g. "ios") which causes confusion (when I read, I got confused about whether the directory named "ios" is what I can choose its name or it is something Cordova or Xcode creates and so it is a required name or directory in all apps).
- HTML5 documentation and example app employs modernizr for feature detection (mobile or desktop) and to load appropriate libraries accordingly. However, modernizr does not load fast in hybrid app (though hybrid app is for sure mobile, I first kept all the implementation as it is to make it "implement once and use for all builds -HTML5, iOS hybrid and Android hybrid-", but it didn't work). After removing modernizr from HTML5 implementation and loading only mobile libs, it required no more effort to make html5 app hybrid (it just did work).
I also have a question, and your answers and/or directions are appreciated in advance.
- For now, I created some simple REST API's in PHP to try the mobile side libs. What is your recommendation of building server side (which uses existing database let's say) if it is going to be used with AeroGear? I mean, is it OK to go with PHP to provide REST API, and then add another layer using AeroGear controller? Or should I go with Java implementation from the start? So, to restate and simplify: my AeroGear controller needs to connect to an existing LDAP instance. What's the AeroGear recommended approach for this?
Thanks for your time to read (and respond). Cheers,
---
Yavuz Selim Yilmaz
SUNY at Buffalo
Computer Science and Engineering
PhD Candidate
11 years, 6 months
