Yeah I totally fubarred that when I was putting together the gist.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
isvoid
, instead a Callback is invoked (onSuccess(list)
), see Pipe.java
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.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 thereadWithFilter
, like:-(void) readWithFilter:(void (^)(id<AGFilterConf! ig< span class="o" style="font-weight:bold">> 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 ?
It easily works in Java land. (To leak some implementation here look at WeakHashMap, the entries die when the keys die).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").....
You are not wrong at all.
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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev