In the same spirit (inspired from http://stackoverflow.com/questions/5412059/how-to-implement-general-pagination) : 


public interface PagedResult<T> {

    PagedResult<T> next();

    PagedResult<T> prev();

    PagedResult<T> withOffset(int offset);

    PagedResult<T> withLimit(int limit);

    List<T> result();

}


On Tue, Jan 15, 2013 at 1:38 PM, Douglas Campos <qmx@qmx.me> wrote:
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@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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev