[aerogear-dev] my AeroGear notes

Bruno Oliveira bruno at abstractj.org
Wed Jun 5 04:15:10 EDT 2013


Ahoy my friend, I'll also add few comments inline.

Yavuz Selim YILMAZ wrote:
> 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.

Not really, JBoss is our first class citizen, but is possible to 
integrate with [put your favorite backend here].

Examples:

- Ruby: https://github.com/abstractj/todo-aerogear-sinatra
- Node.js: https://github.com/abstractj/todo-aerogear-node

These examples can give you and idea.

> - 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.

If the documentation is not clear, file JIRAs with what must be improved 
and we will work on it.

https://issues.jboss.org/browse/AEROGEAR

> 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).

We are backend agnostic, as I mentioned.

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]).

You don't need to understand the details of AeroGear Controller to make 
use of client libraries, you just need to know how to deploy AeroGear 
Controller demo and the API provided by our demo 
(http://aerogear.org/docs/specs/aerogear-rest-api/)

But bear in mind, only make use of AeroGear Controller if you want to.

> - 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.

Don't hold your breath, it's open source, so patches are than welcome.

> 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?

That's totally fine, choose your favorite backend and go for it.

  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?

If you want to make use of LDAP, you have to stick with PicketLink 
(http://picketlink.org/) or Apache Shiro (http://shiro.apache.org/). 
Currently I'm working to make this integration simple. I'd love to hear 
your feedback and what's missing for you.

Open JIRAs to me as needed https://issues.jboss.org/browse/AGSEC

>
>
> Thanks for your time to read (and respond). Cheers,

Thanks for your feedback Yavuz.

>
> ---
> Yavuz Selim Yilmaz
> SUNY at Buffalo
> Computer Science and Engineering
> PhD Candidate
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


More information about the aerogear-dev mailing list