I'm not a fan of those PageContext objects (remembers me of some wild-ass ThreadLocals
leaking all over)
My proposal for the paging aware APIs would be something like this:
public interface PagedResult<T> {
List<T> next();
List<T> prev();
List<T> page(int offset, int limit);
}
and the Async counterpart
public interface AsyncPagedResult<T> {
void next(Callback<List<T>> callback);
void prev(Callback<List<T>> callback);
void page(int offset, int limit, Callback<List<T>> callback);
public static interface Callback<U> {
public void onResult(U result);
}
}
I don't like the idea of having a companion object for holding the pagination state.
Thoughts?
-- qmx
On 15/01/2013, at 08:37, Matthias Wessendorf <matzew(a)apache.org> wrote:
Hi Summers,
https://gist.github.com/4532661
That is a way to do paging which keeps Pipes immutable, uses readWithFilter, and
doesn't impose any (for convenient definitions of any) bookkeeping on the developer.
from your Andorid gist:
A) Once the response has been received, the Pipe implementation will return a List of
objects. If this List instance is passed to Pipe.getPageContext the appropriate
PageContext will be returned
Note: There is no 'return' - the readWithFilter is void, instead a Callback is
invoked (onSuccess(list)), see Pipe.java
B) The developer will receive from readWithFilter() a List of object. If she passes this
list into Pipe.getPageContext(List result) she will receive the PageContext associated
with this result.
Do you mean like:
...
myPipe.readWithFilter(filter, new Callback<List<Data>>() {
@Override
public void onSuccess(List<Data> data) {
// get the PageContext:
PageContext ctx = myPipe.getPageContext(data);
...
}
@Override
public void onFailure(Exception e) {
}
});
Not sure about that.....
But for iOS I am thinking about passing in the PageContext into the closure/block of the
readWithFilter, like:
-(void) readWithFilter:(void (^)(id<AGFilterConfig> config)) config
success:(void (^)(id listOfObjects, id pageContext))success
failure:(void (^)(NSError *error))failure;
A usage would look like:
[pipe readWithFilter:^(id<AGFilterConfig> config) {
// set the filter args and override the given defaults
} success:^(id listOfObjects, id pageContext) {
// work with the listOfObjects reponse.
// for paging/query info, access the given pagecontext,
// of the CURRENT request
...
} failure:^(NSError *error) {
// handle errorz
}];
Any thoughts ?
Not sure I like (or understand) the Pipe.getPageContext(List result) call. Current
mindset is that thePageContext just (and only) belongs to the previous (executed)
request... Not sure I want to support something like
// first call:
List<SomeType> first;
myPipe.readWithFilter(.....) // set first inside of callback
...
// second call:
List<SomeType> second;
myPipe.readWithFilter(.....) // set second inside of callback
...
// third call:
List<SomeType> third;
myPipe.readWithFilter(.....) // set third inside of callback
...
/// A BIT LATER ....:
myPipe.getPageContext(first);
I am not sure if that (myPipe.getPageContext(first);) is really desired (or would even
easily work, as it would need to store the "metadata").....
Perhaps I am just wrong.
--
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