Pagination info returned has incorrect values

[tomlongo]

I’m using the new pagination API and everything works except that the NBPaginationInfo object I get back has incorrect properties. The numberOfTotalPages, numberOfTotalItems and numberOfTotalAvailableItems properties are all 0, making it impossible for me to know how many items to expect.

Is this a known issue, or could it be something wrong with my implementation?

[DavidHuie]

You better get on this, @hlfcoding!

[hlfcoding]

@tomlongo To use legacy pagination, you need to make sure in the NB Control Panel your app still is able to use legacy pagination. See the NB docs for more info. (Nevermind, I see you already posted there.) For most apps, especially ones created since the introduction of the new token-based pagination (late 2014), this is no longer possible. If you're sure you can use legacy pagination, just set shouldUseLegacyPagination to true (defaults to false), on your client instance. numberOfTotalPages, numberOfTotalItems, numberOfTotalAvailableItems (computed), are all 0 when legacy pagination isn't available one way or the other.

@DavidHuie Thanks for the reminder!

[tomlongo]

Hello @hlfcoding thanks for the help. I see, so what you're saying is that the numberOfTotalPages etc. is only available in the legacy pagination, not with the new?

I'd rather use the new method given the legacy one is deprecated, but is there a way I can get that same information using the new method? Currently i can't see any way of finding out the total number of items/pages when fetching people

[hlfcoding]

Unfortunately, and mostly for performance reasons I cannot get into here, the NationBuilder API currently does not have a separate endpoint that provides item or page counts, and only the legacy pagination mode provides that information. The new pagination response is geared towards infinite scroll and simple prev-next button use cases.

[tomlongo]

hmm, that's a shame. The way I'm implementing this is to use a local syncing model, so it goes off and fetches all people at once, stores it in CoreData, them from then on it only pings the API for records changed since the last sync every few minutes.

This means viewing/searching people is instantaneous for the user, and it takes the pressure off your API because the app never needs to query it unless updating data.

However, that initial sync takes some time for nations with a lot of people, so I need a way of determining the total pages so i can show them a progress bar. How safe is it to use the legacy pagination? I'm weary using something that is deprecated is all.

[hlfcoding]

This means viewing/searching people is instantaneous for the user, and it takes the pressure off your API because the app never needs to query it unless updating data.

I'm not sure that's actually better, because it sounds like your app could be fetching a lot of data all at once. I may be wrong about your app, but if your users ever all update at around the same time (ie. for some event), it could actually increase load on our API. We've had issues with large nations that perform large-scale people-sync via API.

However, that initial sync takes some time for nations with a lot of people, so I need a way of determining the total pages so i can show them a progress bar.

An alternate approach you can do is sort-fetch the newest person and the oldest (first added) person, then guesstimate based on the last synced id how many people are left.

How safe is it to use the legacy pagination? I'm weary using something that is deprecated is all.

If you can see a 'Use legacy pagination' checkbox in your nation's admin/oauth/test_tokens path, go ahead and use it. This is my unofficial (but probably accurate) forecast: we will not foreseeably remove legacy pagination support altogether, and will notify ahead of time if that happens. You should reach out to our services team if you need additional help, or if you want to ask for an exception to be made for your nation to allow legacy pagination to be enabled.

I feel like we've reached the end of discussion. Closing...