GWT RPC supported?

[rick...@gmail.com]

I'm looking to choose a mobile development environment to use to extend access to mobile devices for my existing GWT/App Engine web application. Codename One looks great in many ways and the programming model is very clear to me because of previous Swing, JavaFX, and GWT experience. My existing GWT application uses GWT RPC to communicate with the app engine server. That, coupled with it being very simple to use makes it my first choice for network middleware for my situation. However, I would consider changing to Google Cloud Endpoints or some other widely used open source solution for both my GWT application and the mobile apps that I plan to develop. I would like to have a solution that allows me to pass entity objects bi-directionally between the client and server to support the ability to update on the client and then store the updated object on the server. I'm looking at m-gwt/phonegap, as well, btw. I would greatly appreciate some guidance on what technical approaches would work in CodenameOne and GWT to communicate with App Engine, and hopefully meet my needs stated above. Thank you in advance for any comments/guidance.

[Shai Almog]

We use App Engine and GWT as well but we don't support GWT endpoints since this is mostly a JavaScript/Java bridge and we are a native API.
Yes we could implement this but I think we could do better since we aren't constrained by the limitations of JavaScript (threads).

We don't have a standardized wire protocol at the moment although we do have parsers for JSON, XML & CSV.

[Rick Horowitz]

Thanks for the quick reply. I've used serialized JSON and XML (prefer JSON). So, just serialize the JSON objects and send to/from a servlet? Any particular tools or frameworks you might suggest? Also, if you are familiar with Google Cloud Endpoints, could that be used with Codename One, and would you be able to offer a quick how to if I were to look for help later on? From what I understand (though admittedly little research of Endpoints) it appears to generate native proxies to use with android, iphone, etc. 

--
You received this message because you are subscribed to a topic in the Google Groups "CodenameOne Discussions" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/codenameone-discussions/rm1ar46iL-k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to codenameone-discu...@googlegroups.com.
Visit this group at http://groups.google.com/group/codenameone-discussions.
To view this discussion on the web visit https://groups.google.com/d/msgid/codenameone-discussions/efd2440d-4ef4-455c-8967-2a61c55bb8bc%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Rick Horowitz

[Shai Almog]

We are familiar with Google cloud endpoints but we don't support them. They are overly tailored to writing applications the way Google expects them to be written which doesn't mesh well with how we see the platform moving forward.
Ideally we'd like to offer something similar but more server agnostic and more appropriate to what we are trying to achieve.
Supporting the GWT way of doing things with the double interfaces and callback semantics makes very little sense in Codename One since we can use threads. The entire reason that API exists is to allow the semantics of non-blocking JavaScript IO.
Normally the IDE hides some of the suckiness of that API (by generating the interfaces etc) which means that if we support it we'd have to replicate some of that functionality in all 3 IDE plugins which is a pain. I'd rather have a good simple API.

You can use the JSON/XML parsers that are builtin, they do not serialize to objects since we have no reflection (to keep the size down). At a future point in time we might have a better approach.