On 01/16/2013 06:46 AM, Matthias Wessendorf wrote:
Hello,
a few quick/simple q's:
<
https://gist.github.com/2d75e480500c69993227#javascript>JavaScript
One question on the two gists...
Kris' gist <
https://gist.github.com/4539188> uses |pipe.next()| of
scrolling forward, Summer's comparison gist
<
https://gist.github.com/4542125> uses |pipe.read(page:"next")| for
the JS.
I think I do like the 'plain' read overload in JS... - but having a
more explicit next() (and others) is not that bad; but (currently) my
vote would be |pipe.read(page:"prev".....|.
Oh... What happens when I have a /regular/ pipe, object (where the
|paged| setting is NOT specified on its ctor), and I invoke
|pipe.read(page:"next")| ? I hope it does not issue a JS/type error
:-) but I'd expect to have a straight read of ALL the "objects" (or
"entities")...
<
https://gist.github.com/2d75e480500c69993227#android>Android
You have the following:
|cars.readWithFilter(filter, new Callback<Car>() {
@Override
void onSuccess(List<Car> data) {
firstPage = data;
}
@Override
void onError(Exception ex) {
//handle error
}
});
firstPage.next(.......);
|
I am wondering what is the |fristPage| here (since the |data| on the
|onSuccess| has been assigned to it)
firstPage is a field with a type of PagedList
<
https://gist.github.com/2d75e480500c69993227#change-offset-and-limit>C...
Offset and Limit
I like both (JS and Android) :) The Android solution is similar to
what I had in mind for iOS
<
https://gist.github.com/cbff741b3b21a50c3b67>...
I will update the comparison gist soon !
-Matthias
On Tue, Jan 15, 2013 at 11:00 PM, Summers Pittman <supittma(a)redhat.com
<mailto:supittma@redhat.com>> wrote:
On 01/15/2013 02:51 PM, Douglas Campos wrote:
> As we wrap the day one of API design discussions, what about summarize the API
proposals with usage?
>
> JS/iOS/Android:
>
> 1) usage example, covering some mentioned usecases like changing the paging
"midflight" - something really straight to the point (no fluff, just stuff)
I forked Kris's gist and added android stuff using my proposal
(sans blocking methods)
https://gist.github.com/4542125
I went for pedantic in a couple of examples...
> 2) API definition
>
> I think this will give the orthogonal view we need to come to a decision.
>
> kris: What about you providing a snippet of the API you hate too? just for
comparison sake :P
>
> -- qmx
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev