[aerogear-dev] Android - server endpoint

[Marko Strukelj]

----- Original Message -----
> On Tue, Aug 14, 2012 at 9:42 PM, Glen Daniels <glen at thoughtcraft.com>
> wrote:
> > Hey Marko, all,
> >
> > So this is indeed cool stuff!  A few comments:
> >
> > As you say, it's AppEngine-specific.  While it's true that the
> > blogger
> > Matthias pointed to is trying to replicate the server-side with
> > Jersey,
> > that's very much not baked, nor is that approach sanctioned by
> > Google as
> > yet.
> 
> true, but I liked the idea that he is exchanging the proprietary
> Google.
> And also we don't really care about the google platform :-)
> 
There's a JBoss project called CapeDwarf Blue (https://github.com/capedwarf/capedwarf-blue) which implements a big portion of AppEngine runtime, and it runs on JBoss AS7. So if one wants to port an application from AppEngine to AS7 for example that's quite possible. That might also mean that you could use the same or almost the same Eclipse tools to generate client libs for example - once you have additional services that provide metadata info in the same format ... Although as far as I understood the generate those libs in the cloud via some service, so tooling just triggers generation and downloads the result. 

> 
> > At the least we certainly want the AeroGear stuff to work on
> > OpenShift.
> 
> 
> > It also looks kind of Eclipse-specific.  Not sure if they expose
> > command
> > line tools for doing the codegen/etc for use with other IDEs or
> > maven
> 
> I saw the usage of CLI tool to generate the ObjC bits
> 
> > builds - but hopefully they do.  Eclipse-specificity isn't
> > necessarily a
> > huge problem but we definitely need to support other IDEs/workflows
> > as
> > well. ("right?" -- says the die-hard IntelliJ user :) )
> >
> > All in all this seems to be rather a lot like what AeroGear (and
> > Parse/Kinvey/Stackmob/etc) is trying to actually become, so perhaps
> > it's
> > more another competitor in the ecosystem as opposed to something we
> > really want to use as foundation.  That said, if there are useful
> > pieces
> > we can borrow, that'd be dandy - i.e. if we're really happy with
> > their
> > wire-level API and codegen tools then perhaps there'd be a way to
> > leverage those things with a JBoss backend.
> 

'wire-level' API covers things like HTTP communication helpers, JSON marshalling, OAuth2 ... One layer higher are probably client libraries for basic REST services used to gather metadata about the deployed service endpoints, and on top of that is probably your service. 

> 
> Areogear is providing client libs, to be used by apps;
> 
> If I understand it correctly, the google thing is gereating app libs
> (for a certrain app)
> which uses under the cover SOMETHING (from google) for http
> communication.
> Basically their differenclient libs, like
> 
> - http://code.google.com/p/google-api-objectivec-client/
> - http://code.google.com/p/gtm-http-fetcher/
> (for iOS)
> 
> 
> at SOMETHING (the client libs) is what we are after, right now …

Client native libraries are platform specific (js, java, objectivec).
For basic HTTP/HTTPS communication you either use standard native library part of the platform i.e. HXR in browser, java.net or HTTPClient in java ... 
Or you use some even higher level library that provides a nicer API to these, or some extra functionality.

Then there's JSON. Again the same story - either use something provided by the platform, or a popular alternative.

Higher you go up this stack of libraries the more your higher layer library dictates by way of its dependencies what you'll have to use for your lower layer.

So, what you need to do is decide where your stack begins. Where you will not use an existing library, but write your own and chose your own dependencies.

> >
> > Finally, their stuff isn't public yet, so it would seem somewhat
> > challenging to hitch to their wagon in the near term even if we
> > wanted to.
> 
> I can't even find examples of generated source, and in order to get
> access to the 'google thing',
> you need to sign up (not really up for it :-))
> 

The key thing I wanted to point out is the approach, not to replicate the solution in exact way (although at some point there may be good interoperabilty reasons to wanna do that).

Rather let's do a mental simulation ... 

Let's say there's a REST service exposing some resources. You open a browser go to resource endpoint and get JSON response with a list of entities.

You can do this from code - open a connection, do a GET /myresource ... set request headers, get back response which you parse in a tree of maps using JSON parser.

No problem, you can connect to any rest point this way, and after you have connected to a few you start noticing a lot of plumbing code in your application. Also you start noticing a lot of typos that you make, that cause many iterations before you get things working smoothly.

If you had some schema describing what you can expect in the result, you could use that to generate POJOs and code to automatically mashal / unmarshal these. You can also wrap the mechanics of HTTP calls away and after done with all that what you have is just a class representing a remote service with methods taking POJOS that wrap all the mechanics of the remote call and return deserialized POJOs back. 

I think that's where we're trying to get to.