Quantcast

[aerogear-dev] Android - server endpoint

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[aerogear-dev] Android - server endpoint

Marko Strukelj

I want to share some links from Google I/O 2012 that describe current solution from Google with respect of ease of development - how to have a REST endpoint in support of client apps on multiple platforms.

One interesting solution is something they call Endpoints. It's AppEngine-centric, but you can think of AppEngine as your server-side wherever it's hosted. The idea is that you create your endpoint - a REST service, annotate it with some annotations and then use tooling to generate client library for your REST service. And you can generate client libs in java, ObjectiveC, javascript ...

A very nice demo of this (starts playing where the interesting part begins):
http://youtu.be/NU_wNR_UUn4?t=9m24s

Note at 19:36 into the video (http://youtu.be/NU_wNR_UUn4?t=19m36s) a mentioned JSON description of deployed REST service, and API Explorer.

API Explorer is really cool stuff - you can explore your REST service from your browser, and interact with it. And JSON based metadata about the service allows direct usage in javascript libraries in the browser.

At 22:41 into the movie (http://youtu.be/NU_wNR_UUn4?t=22m41s) there is a demo of Google Plugin for Eclipse used to generate client side API from a web service.



There is another interesting video on the topic:
http://youtu.be/dylFNrvZ_3U?t=26m45s

It starts a bit slowly but it's necessary to explain what a demo app does, and then gets more interesting about 35:40 into the video (http://youtu.be/dylFNrvZ_3U?t=35m40s).


Some food for thought ...

- marko
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [aerogear-dev] Android - server endpoint

Matthias Wessendorf
Hey Marko,

thanks for the info!

On Tue, Aug 14, 2012 at 8:22 PM, Marko Strukelj <[hidden email]> wrote:
>
> I want to share some links from Google I/O 2012 that describe current solution from Google with respect of ease of development - how to have a REST endpoint in support of client apps on multiple platforms.
>
> One interesting solution is something they call Endpoints. It's AppEngine-centric, but you can think of AppEngine as your server-side wherever it's hosted. The idea is that you create your endpoint - a REST service, annotate it with some annotations and then use tooling to generate client library for your REST service.


here is already a blog entry that explains how to replace w/ JAX-RS


> And you can generate client libs in java, ObjectiveC, javascript ...
>

does one of the videos show the actual ObjC code generation ?

-Matthias



> A very nice demo of this (starts playing where the interesting part begins):
> http://youtu.be/NU_wNR_UUn4?t=9m24s
>
> Note at 19:36 into the video (http://youtu.be/NU_wNR_UUn4?t=19m36s) a mentioned JSON description of deployed REST service, and API Explorer.
>
> API Explorer is really cool stuff - you can explore your REST service from your browser, and interact with it. And JSON based metadata about the service allows direct usage in javascript libraries in the browser.
>
> At 22:41 into the movie (http://youtu.be/NU_wNR_UUn4?t=22m41s) there is a demo of Google Plugin for Eclipse used to generate client side API from a web service.
>
>
>
> There is another interesting video on the topic:
> http://youtu.be/dylFNrvZ_3U?t=26m45s
>
> It starts a bit slowly but it's necessary to explain what a demo app does, and then gets more interesting about 35:40 into the video (http://youtu.be/dylFNrvZ_3U?t=35m40s).
>
>
> Some food for thought ...
>
> - marko
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [aerogear-dev] Android - server endpoint

Matthias Wessendorf
here it goes....


http://bazinga-unit.blogspot.de/2012/08/replacing-google-cloud-endpoints-with.html

On Tue, Aug 14, 2012 at 8:30 PM, Matthias Wessendorf <[hidden email]> wrote:

> Hey Marko,
>
> thanks for the info!
>
> On Tue, Aug 14, 2012 at 8:22 PM, Marko Strukelj <[hidden email]> wrote:
>>
>> I want to share some links from Google I/O 2012 that describe current solution from Google with respect of ease of development - how to have a REST endpoint in support of client apps on multiple platforms.
>>
>> One interesting solution is something they call Endpoints. It's AppEngine-centric, but you can think of AppEngine as your server-side wherever it's hosted. The idea is that you create your endpoint - a REST service, annotate it with some annotations and then use tooling to generate client library for your REST service.
>
>
> here is already a blog entry that explains how to replace w/ JAX-RS
>
>
>> And you can generate client libs in java, ObjectiveC, javascript ...
>>
>
> does one of the videos show the actual ObjC code generation ?
>
> -Matthias
>
>
>
>> A very nice demo of this (starts playing where the interesting part begins):
>> http://youtu.be/NU_wNR_UUn4?t=9m24s
>>
>> Note at 19:36 into the video (http://youtu.be/NU_wNR_UUn4?t=19m36s) a mentioned JSON description of deployed REST service, and API Explorer.
>>
>> API Explorer is really cool stuff - you can explore your REST service from your browser, and interact with it. And JSON based metadata about the service allows direct usage in javascript libraries in the browser.
>>
>> At 22:41 into the movie (http://youtu.be/NU_wNR_UUn4?t=22m41s) there is a demo of Google Plugin for Eclipse used to generate client side API from a web service.
>>
>>
>>
>> There is another interesting video on the topic:
>> http://youtu.be/dylFNrvZ_3U?t=26m45s
>>
>> It starts a bit slowly but it's necessary to explain what a demo app does, and then gets more interesting about 35:40 into the video (http://youtu.be/dylFNrvZ_3U?t=35m40s).
>>
>>
>> Some food for thought ...
>>
>> - marko
>> _______________________________________________
>> aerogear-dev mailing list
>> [hidden email]
>> 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



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [aerogear-dev] Android - server endpoint

Matthias Wessendorf
Got it... the iOS bits are here:
http://www.youtube.com/watch?v=NU_wNR_UUn4&feature=player_detailpage#t=1611s

Interesting... in the demo code I still saw the 'game' is using
another iOS lib, from Google:
http://code.google.com/p/gtm-http-fetcher/

I think I need to take a look at the generated .h and .m files for iOS...

Anyway, the approach is very interesting, but it's more app specific.
It generates APIs for the particular apps, for different platforms.
Yay!

Under the cover these 'generated APIs' use some sort of (minimal) http
client library, which is - again - specific for its native platform.

For #aerogear, the initial task is coming up with the actual client
libs, for JS, iOS and Android,

Once that is somewhat done, I think it would be cool to see if the
TODO app would be build with something like this,
But... right now, I think that's a bit out of scope..

-Matthias

On Tue, Aug 14, 2012 at 8:30 PM, Matthias Wessendorf <[hidden email]> wrote:

> here it goes....
>
>
> http://bazinga-unit.blogspot.de/2012/08/replacing-google-cloud-endpoints-with.html
>
> On Tue, Aug 14, 2012 at 8:30 PM, Matthias Wessendorf <[hidden email]> wrote:
>> Hey Marko,
>>
>> thanks for the info!
>>
>> On Tue, Aug 14, 2012 at 8:22 PM, Marko Strukelj <[hidden email]> wrote:
>>>
>>> I want to share some links from Google I/O 2012 that describe current solution from Google with respect of ease of development - how to have a REST endpoint in support of client apps on multiple platforms.
>>>
>>> One interesting solution is something they call Endpoints. It's AppEngine-centric, but you can think of AppEngine as your server-side wherever it's hosted. The idea is that you create your endpoint - a REST service, annotate it with some annotations and then use tooling to generate client library for your REST service.
>>
>>
>> here is already a blog entry that explains how to replace w/ JAX-RS
>>
>>
>>> And you can generate client libs in java, ObjectiveC, javascript ...
>>>
>>
>> does one of the videos show the actual ObjC code generation ?
>>
>> -Matthias
>>
>>
>>
>>> A very nice demo of this (starts playing where the interesting part begins):
>>> http://youtu.be/NU_wNR_UUn4?t=9m24s
>>>
>>> Note at 19:36 into the video (http://youtu.be/NU_wNR_UUn4?t=19m36s) a mentioned JSON description of deployed REST service, and API Explorer.
>>>
>>> API Explorer is really cool stuff - you can explore your REST service from your browser, and interact with it. And JSON based metadata about the service allows direct usage in javascript libraries in the browser.
>>>
>>> At 22:41 into the movie (http://youtu.be/NU_wNR_UUn4?t=22m41s) there is a demo of Google Plugin for Eclipse used to generate client side API from a web service.
>>>
>>>
>>>
>>> There is another interesting video on the topic:
>>> http://youtu.be/dylFNrvZ_3U?t=26m45s
>>>
>>> It starts a bit slowly but it's necessary to explain what a demo app does, and then gets more interesting about 35:40 into the video (http://youtu.be/dylFNrvZ_3U?t=35m40s).
>>>
>>>
>>> Some food for thought ...
>>>
>>> - marko
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> [hidden email]
>>> 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
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [aerogear-dev] Android - server endpoint

Glen Daniels
In reply to this post by Marko Strukelj
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.  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
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.

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.

Thoughts?

Thanks,
--Glen

On 8/14/12 2:22 PM, Marko Strukelj wrote:

> I want to share some links from Google I/O 2012 that describe current
> solution from Google with respect of ease of development - how to
> have a REST endpoint in support of client apps on multiple
> platforms.
>
> One interesting solution is something they call Endpoints. It's
> AppEngine-centric, but you can think of AppEngine as your server-side
> wherever it's hosted. The idea is that you create your endpoint - a
> REST service, annotate it with some annotations and then use tooling
> to generate client library for your REST service. And you can
> generate client libs in java, ObjectiveC, javascript ...
>
> A very nice demo of this (starts playing where the interesting part
> begins): http://youtu.be/NU_wNR_UUn4?t=9m24s
>
> Note at 19:36 into the video (http://youtu.be/NU_wNR_UUn4?t=19m36s) a
> mentioned JSON description of deployed REST service, and API
> Explorer.
>
> API Explorer is really cool stuff - you can explore your REST service
> from your browser, and interact with it. And JSON based metadata
> about the service allows direct usage in javascript libraries in the
> browser.
>
> At 22:41 into the movie (http://youtu.be/NU_wNR_UUn4?t=22m41s) there
> is a demo of Google Plugin for Eclipse used to generate client side
> API from a web service.
>
>
>
> There is another interesting video on the topic:
> http://youtu.be/dylFNrvZ_3U?t=26m45s
>
> It starts a bit slowly but it's necessary to explain what a demo app
> does, and then gets more interesting about 35:40 into the video
> (http://youtu.be/dylFNrvZ_3U?t=35m40s).
>
>
> Some food for thought ...
>
> - marko _______________________________________________ aerogear-dev
> mailing list [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [aerogear-dev] Android - server endpoint

Matthias Wessendorf
On Tue, Aug 14, 2012 at 9:42 PM, Glen Daniels <[hidden email]> 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 :-)


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


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 …
>
> 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 :-))

-Matthias

>
> Thoughts?
>
> Thanks,
> --Glen
>
> On 8/14/12 2:22 PM, Marko Strukelj wrote:
>> I want to share some links from Google I/O 2012 that describe current
>> solution from Google with respect of ease of development - how to
>> have a REST endpoint in support of client apps on multiple
>> platforms.
>>
>> One interesting solution is something they call Endpoints. It's
>> AppEngine-centric, but you can think of AppEngine as your server-side
>> wherever it's hosted. The idea is that you create your endpoint - a
>> REST service, annotate it with some annotations and then use tooling
>> to generate client library for your REST service. And you can
>> generate client libs in java, ObjectiveC, javascript ...
>>
>> A very nice demo of this (starts playing where the interesting part
>> begins): http://youtu.be/NU_wNR_UUn4?t=9m24s
>>
>> Note at 19:36 into the video (http://youtu.be/NU_wNR_UUn4?t=19m36s) a
>> mentioned JSON description of deployed REST service, and API
>> Explorer.
>>
>> API Explorer is really cool stuff - you can explore your REST service
>> from your browser, and interact with it. And JSON based metadata
>> about the service allows direct usage in javascript libraries in the
>> browser.
>>
>> At 22:41 into the movie (http://youtu.be/NU_wNR_UUn4?t=22m41s) there
>> is a demo of Google Plugin for Eclipse used to generate client side
>> API from a web service.
>>
>>
>>
>> There is another interesting video on the topic:
>> http://youtu.be/dylFNrvZ_3U?t=26m45s
>>
>> It starts a bit slowly but it's necessary to explain what a demo app
>> does, and then gets more interesting about 35:40 into the video
>> (http://youtu.be/dylFNrvZ_3U?t=35m40s).
>>
>>
>> Some food for thought ...
>>
>> - marko _______________________________________________ aerogear-dev
>> mailing list [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [aerogear-dev] Android - server endpoint

Marko Strukelj

----- Original Message -----

> On Tue, Aug 14, 2012 at 9:42 PM, Glen Daniels <[hidden email]>
> 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.

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
qmx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [aerogear-dev] Android - server endpoint

qmx
Administrator
> 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.
A point to keep in mind is that code generation should be our **last** resort - in a ideal world we have just one client library that autodiscovers the rest via a single endpoint.


-- qmx


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [aerogear-dev] Android - server endpoint

Matthias Wessendorf
On Wed, Aug 15, 2012 at 5:19 PM, Douglas Campos <[hidden email]> wrote:
> A point to keep in mind is that code generation should be our **last** resort

I have to say (I guess b/c of XDoclet and EJB 2.x :-)) I am not too
much a fan of code generation

> in a ideal world we have just one client library that
> autodiscovers the rest via a single endpoint.
>

dynamic binding, based on metadata (e.g. WADL)


>
> -- qmx
>



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [aerogear-dev] Android - server endpoint

Marko Strukelj
In reply to this post by qmx
----- Original Message -----

> > 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.
> A point to keep in mind is that code generation should be our
> **last** resort - in a ideal world we have just one client library
> that autodiscovers the rest via a single endpoint.
>

You mean that your javascript module has dependencies specified, and automatically downloads other javascript modules...
Or you mean that in java client you have a .jar that automatically downloads other jars? Sounds like module system and bootstrap code that harneses the module system to pull down all the code.

But how does that address hiding plumbing away from the developer? And productivity features like typesafety, and codecompletion that IDEs give you?
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [aerogear-dev] Android - server endpoint

Bruno Oliveira
My 2 cents, 

I was watching that video tonight, is a great approach, assuming that we'll only use app engine for it, already mentioned in this thread.

So, we're discussing endpoints generation without app engine. We're assuming that our backend will be only Java right? So how could I do the same with torquebox and ruby? Can I generate client source code to ring endpoints on immutant? OpenShift doesn't run only Java, right?

http://tb-aerogear.rhcloud.com/ <- aerogear + torquebox + ruby

I would rather to go with well defined endpoints on the server side and build nice APIs to the client side, is just my opinion.



-- 
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile

On Wednesday, August 15, 2012 at 12:41 PM, Marko Strukelj wrote:

----- Original Message -----
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.
A point to keep in mind is that code generation should be our
**last** resort - in a ideal world we have just one client library
that autodiscovers the rest via a single endpoint.

You mean that your javascript module has dependencies specified, and automatically downloads other javascript modules...
Or you mean that in java client you have a .jar that automatically downloads other jars? Sounds like module system and bootstrap code that harneses the module system to pull down all the code.

But how does that address hiding plumbing away from the developer? And productivity features like typesafety, and codecompletion that IDEs give you?
_______________________________________________
aerogear-dev mailing list


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Loading...