[aerogear-dev] my AeroGear notes

Wed Jun 5 17:23:06 EDT 2013

On Wed, Jun 5, 2013 at 10:33 PM, Yavuz Selim YILMAZ <yavuzsel at buffalo.edu>wrote:

> Hi,
>
> Thanks for the replies. Some responses are inline.
>
>
> ---
> Yavuz Selim Yilmaz
> SUNY at Buffalo
> Computer Science and Engineering
> PhD Candidate
>
> On Jun 5, 2013, at 2:28 AM, Matthias Wessendorf <matzew at apache.org> wrote:
>
> Hello Yavuz,
>
> thanks for the interest in AeroGear and sharing your feedback with our
> community!
>
> We are for sure interested in how we can improve the experience. We really
> appreciate your comments!
>
> A few comments in-line!
>
>
>
>
>
> On Wed, Jun 5, 2013 at 12:04 AM, Yavuz Selim YILMAZ <yavuzsel at buffalo.edu>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.
>>
>
>
> As you (probably) noticed, they can be used individually.   Do you think
> we should phrase that different on the side, or in the docs ?
>
>
> I started using AeroGear with the knowledge of there exist an open source
> library which makes mobile to REST API communication easier. But once I saw
> the AeroGear controller while reading through aerogear.org, I thought
> mobile libraries communicate with REST APIs through this controller on the
> server side (as the controller is there and is not a client library, i
> thought like this. it's maybe my misunderstanding though). And I found no
> explanation on my iOS API trial path which states the opposite (i.e. I
> don't need AeroGear controller, or better to say the library directly
> communicates with REST API). Once I get to know more and more about
> AeroGear, then it becomes clear (like checking more docs, playing with the
> example apps etc.). But if I choose to try quickly and pick a mobile lib,
> then it's harder to figure the things out.
>

Ok, as seen on the integration tests: Only RESTful APIs are "required". Can
you open a JIRA ticket with a "suggestion" on how the documentation should
be changed?
(I understood this comment more like: "If the library was more clear on the
backend == REST, it would have been easier..." - correct me if I am wrong
here)

>
>
>
>> - 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.
>>
>
>
> That's an interesting comment. You are basically say the demos apps where
> broken? Or update too often ? If the too often, please have in mind that we
> are early stage, and that things are changing on a fast pace
>
>
> Here is my example: aerogear-android-todo app (versionCode=1) does not
> compile on my eclipse (it does if I compile on terminal). I think if and
> when the libs used in the example apps changed (i saw recent updates or bug
> reports), it sometimes (as in my case) causes problems. (probably my
> problem is related to a recent update on m2eclipse or android-sdk-deployer
> or something else, as the project shows error on pom.xml file. or maybe,
> even if I followed the links you provided to install those, I could not do
> it correctly - but on the contrary, it works well if I create a maven
> android project on eclipse and then add AeroGear dependency to pom.xml and
> use the AeroGear in my project).
>

I think that Sebastian had recently some issues there too - he added a fix
for that.

Sebi, any comment ?

>
>
>
>>
>>
>> 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).
>>
>
> The backend should be pretty independent. For iOS, we do have integration
> tests against different cloud services (not only against our backend):
> - World Of Warcraft:
> https://github.com/aerogear/aerogear-ios-integration/blob/master/AeroGear-iOS-Integration/AeroGear-iOS-IntegrationTests/WorldOfWarcraft_PipeTests.m
> - Github's GIST API:
> https://github.com/aerogear/aerogear-ios-integration/blob/master/AeroGear-iOS-Integration/AeroGear-iOS-IntegrationTests/AGPagingWebLinking_GitHub.m
> - Twitter's Search:
> https://github.com/aerogear/aerogear-ios-integration/blob/master/AeroGear-iOS-Integration/AeroGear-iOS-IntegrationTests/AGPagingBody_Twitter.m
>
> We do not even know what they used for writing these backends. Do you
> think the different client libs should state more clearly that they can be
> used independently?
>
>
> This would be an awesome solution I believe. As I started with a client
> library (while just knowing that there is an AeroGear controller), I was
> confused about server side. If that client lib's guide was talking a little
> bit about the server side, I think I could've got it quickly.
>

Can u open a JIRA for this, so that we do not forget about it ?

>
>
>
>
>> 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]).
>>
>
> Looks like the controller guide needs some improvements? Or being more
> clearly on the REST API (which is what you really need). Feel free to
> suggest changes to our docs! We are more than happy to improve, especially
> based on user feedback
>
>
> I think my confusion was about client side libs (about what should be the
> server side specs). So your previous suggestion (libs guides state about
> backend side) would work awesome (and for the controller guide, as I am not
> familiar to Java backend (not as much as I do to iOS and Android), maybe it
> was hard specifically for me, so leaving that part).
>
>
>
>
>> - 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.
>>
>
> I am sorry to hear, but that has been changed recently - So I guess you
> are a "victim" of this fast pace here. Have a look at the template's "login
> code":
>
> https://github.com/aerogear/aerogear-ios-xcode-template/blob/master/AeroGear/Application.xctemplate/ViewController.m#L26-L44
>
>
>
> Good news. :)
>
>
>>
>> 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.
>>
>
>
> You mean integrated into the Eclipse Tooling? We do have guides for
> Eclipse for instance:
> http://aerogear.org/docs/guides/aerogear-android/
>
>
> I integrated maven to eclipse and now using it. But my point is coming
> into scene considering this flow:
>
> - I started to develop for Android, so followed the
> documentation/guidelines that Google provides. Google recommends (and
> follows on the guidelines) using Eclipse and provides ADT plugin which
> takes care of the compilation. So, going through that docs, one does not
> need maven at all. So, I was expecting to have an option for AeroGear,
> which will work with my setup (i.e. Eclipse + ADT). But AeroGear requires
> me to use maven.
>

Not sure here. With the recent Google I/O, they are moving away from
Eclipse (to IntelliJ) and I have seen some discussions around that here.
But I do not recall details

>
>
>
>
>> 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.
>>
>
> Is that because on the documentation ?
>
>
> I think this goes to the same explanation with the previous one. As I was
> not using maven for developing Android apps, it was not as quick as iOS.
> (not because of documentation, but because it was requiring me to use new
> tools)
>

So basically better (non-maven related) tooling for AeroGear-Android, right
?

>
>
>
>> - 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).
>>
>
> in iOS the idea was to have a generic "parameter provider", since the
> "where" is pretty much dependent on the server. So configure your own
> "params and their values" was the idea behind in iOS. I think that the
> "where" is gone (or going away) in Android land as well
>
>
>
>
>>
>>
>> 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).
>>
>
> CORS support is available in the AG-js library, but yeah that's something
> your backend needs to "setup" as well.
>
>
>
>> - 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).
>>
>
> Cordova names their supported platforms that way (ios, android) - we can
> not do much about this, also I think it does make sense (since they
> generate the bindings and abstraction for that particular platform (e.g.
> iOS or Android or whatnot :))
>
>
>
>> - 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).
>>
>
>
> You are talking about the Kitchensink example, right ? I think that is
> generally a bit older now... I will have Luke/Kris comment on the future
> directions there :-)
>
>
> Yes, the kitchensink app.
>
>
>
>
>>
>> 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.
>>
>
> that's perfectly ok!
>
>
>>  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,
>>
>
> if your backend devs are PHP guys -> go that route
>
>
>> and then add another layer using AeroGear controller? Or should I go with
>> Java implementation from the start?
>>
>
> Not needed. If you feel comfortable with Java, feel free to use the
> AG-Controller or straight JAX-RS. It's up to you. See the integration test
> examples I shared above: We basically have no details about the backened -
> we just leverage their REST APIs
>
>
>
>>  So, to restate and simplify: my AeroGear controller needs to connect to
>> an existing LDAP instance. What's the AeroGear recommended approach for
>> this?
>>
>
> Good question :-) Do you mind starting a new thread for the LDAP
> connection issue?
>
>
>
>>
>>
>> Thanks for your time to read (and respond). Cheers,
>>
>
> Yavuz, thanks again for trying AeroGear and giving such a detailed
> analysis! We truly appreciate it!! I hope some given answers make sense.
> Let us know if you need more, or feel free to suggest improvements.
>
>
> Thanks!!!
> -Matthias
>
>
>
>>
>> ---
>> 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
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>

-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130605/99759304/attachment-0001.html 