i think google should clarify it's own philosophy in a special article in
the developer guide, because as of right now , there way too many "black
holes" on the subject of transports and frameworks that use them

GWT-RPC
JSON
RequestFactory
AutoBeans
XML.

i know that autobeans and rtf both uses json under, but that would only
clarify the situation.

an FAQ and a  table matrix should  be created specifying  how each
technology is based used AND it's future directions (like for example the
use GWT-RPC in android, possible break in future version of java etc... ,
and other platforms compared to other technologies) also some basic
benchmarks would be usedfull.


On Mon, Jul 18, 2011 at 10:08 AM, Michel Jonker
<michel.jon...@e-office.com>wrote:

> Hi,
>
> Thanks for this encouragement.
> I am a newby at GWT/App Engine and want to start creating applications
> that follow Google's philiosofy.
> Later (when I am more comfortable) I probably can add my own patterns
> and stuff.
>
> The main lesson I learned from this discussion is that GWT-RPC comes
> with serialization 'challenges'. Which is not such a problem when you
> work with web applications but is a much bigger issue when you have
> distributed apps (like Android connected to App Engine).
>
> Thanks for all the replies
>
> Michel
>
>
> On 14 jul, 22:24, "Aidan O'Kelly" <aida...@gmail.com> wrote:
> > I'm using RequestFactory for a 'non-data-orientated' app and its works
> > very nicely.
> >
> > Chained method invocation:
> >
> > MyServiceRC serviceRequest = appRequestFactory.MyServiceRC();
> > serviceRequest.giveMeAString().to(stringReceiver);
> > if (needPojo == true)
> >     serviceRequest.giveMeAPojo().to(pojoReceiver); // Pojo would be a
> > ValueProxy for example.
> >
> > // Now fire both methods in one RPC request, and do whatever
> > processing we want once both completed.
> > serviceRequest.fire(processStringAndPojoReceiver);
> >
> > A pretty nice way to call server side methods. You are certainly not
> > restricted just to persisting and retrieving datastore objects with
> > RequestFactory.
> >
> > On Thu, Jul 14, 2011 at 10:36 AM, Michel Jonker
> >
> >
> >
> >
> >
> >
> >
> > <michel.jon...@e-office.com> wrote:
> > > Hi,
> > > This is a cross post from the AppEngine group, but since I got no
> > > response there, I want to try this group.
> >
> > > I am trying to figure out the best practise to consume my App Engine
> > > services from both Android and GWT.
> > > Since the services are not that data oriented, I first considered GWT-
> > > RPC.
> > > But given the fact that the GPE 2.4 sample project voor Android comes
> > > with
> > > RequestFactory, I am leaning towards this approach.
> > > I was hoping someone could validate this 'best practise' :
> > > When you have both Android and GWT consumers of your App Engine
> > > service,
> > > apply the RequestFactory pattern.
> >
> > > TIA
> >
> > > Michel Jonker
> >
> > > --
> > > You received this message because you are subscribed to the Google
> Groups "Google Web Toolkit" group.
> > > To post to this group, send email to
> google-web-toolkit@googlegroups.com.
> > > To unsubscribe from this group, send email to
> google-web-toolkit+unsubscr...@googlegroups.com.
> > > For more options, visit this group athttp://
> groups.google.com/group/google-web-toolkit?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google Web Toolkit" group.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> To unsubscribe from this group, send email to
> google-web-toolkit+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-web-toolkit?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Reply via email to