Closed GoogleCodeExporter closed 9 years ago
I can't answer why the 100 limit stops things at 100, was that a different
query?
You are mixing the method concept of maxResults and the service property
shouldFetchNextPages. The maxResults controls how many results you can get for
each server request you send. But, shouldFetchNextPages tells the library to
check and see if a query returned an indication that there is another (next)
page of results and if so, follow it merging the results. If you turn on
logging, you'll see the limit happens on each network transaction and then the
library is sending the request for the next page under the hood for you.
Original comment by thomasvl@google.com
on 9 May 2012 at 3:39
100 and 200 is the same query with different maxResults.
I think maxResults and shouldFetchNextPages are designed to be used together,
as the doc states:
===
For APIs that provide a nextPageToken or nextStartIndex property, the library
can automatically fetch all pages, and return an object whose items array
includes the items of all pages (up to 25 pages). This can be turned on by
setting the shouldFetchNextPages property of a service or a ticket:
// Turn on automatic page fetches
service.shouldFetchNextPages = YES;
Note, however, that results spread over many pages may take a long time to be
retrieved, as each page fetch will lead to a new http request. The server can
be told to use a larger page size (that is, more items in each page returned)
by fetching a query for the feed with a maxResults value:
// Specify a large page size to reduce the need to fetch additional result pages
GTLQueryTasks *query = [GTLQueryTasks queryForTasklistsList];
query.maxResults = 1000;
ticket = [service executeQuery:query ...
Ideally, maxResults will be large enough that, for typical user data, all
results will be returned in a single page.
===
Also as Greg Robbins said in this
thread(https://groups.google.com/d/msg/google-api-objectivec-client/EcR6bqocyvM/
2WRjYNxelA0J):
===
maxResults is the property for specifying the number of list results, but it's
a poorly-named property; it should really be called maxResultsPerPage. If you
have set the service's property to automatically fetch next pages, it will
fetch a series of pages with maxResults items per page.
===
Let's say with shouldFetchNextPages, query should return 2 pages, where can I
get the response of "the request for the next page the library is sending under
the hood for me"? I suppose the library combines these two pages and returns
them all together to me in my completionHandler, as the doc states "return an
object whose items array includes the items of all pages (up to 25 pages)".
Original comment by an0...@gmail.com
on 9 May 2012 at 3:55
Look at the http log for the request/response. Is the server including a
nextPageToken or nextStartIndex in the response JSON?
Original comment by grobb...@google.com
on 9 May 2012 at 8:06
Thanks for the hint. After checking the logs, I've identified the problem:
I'm requesting a partial response as follows:
query.fields =
@"updated,items(etag,id,status,created,updated,summary,description,location,star
t,end,recurrence,extendedProperties)";
which does not include nextPageToken and causes the missing of nextPageToken in
the response.
I didn't expect that. In fact, I still think it is odd for Google Calendar to
filter out nextPageToken from the response, because nextPageToken is obviously
not part the "content" that should be controlled by fields.
Original comment by an0...@gmail.com
on 9 May 2012 at 8:39
I'll pass your suggestion on to the API server team. Thanks for letting us know.
Original comment by grobb...@google.com
on 12 May 2012 at 12:40
Original issue reported on code.google.com by
an0...@gmail.com
on 9 May 2012 at 3:18