On 01/15/2013 05:37 AM, Matthias Wessendorf 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 <
https://gist.github.com/4532661>:
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
<
https://github.com/aerogear/aerogear-android/blob/master/src/org/jboss/ae...
Yeah I totally fubarred that when I was putting together the gist.
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 ?
I don't hate it. I don't love it but I don't hate it. On the one hand
it makes where the pageContext comes from explicit and you get it with
your request. On the other hand you don't always a PageContext for a
request so it will be something devs always have to drag around.
Not sure I like (or understand) the |Pipe.getPageContext(List
result)| call. Current mindset is that the|PageContext| 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").....
It easily works in Java land. (To leak some implementation here look at
WeakHashMap, the entries die when the keys die).
I'm open to suggestions because I am not in love with this method either.
Perhaps I am just wrong.
You are not wrong at all.