Pagination Simplified

During our journey as front end developers we come across lists of data for which requires us to implement pagination.

The process is simple as load the list of data, and when the end is reaching, if server has more data then fetch the data from the server with the next page information and also it’s state that is loading or completed.

Level 1:

We may have a single list in our screen.

We have to fetch the list, keep the count of items available at server and then check whether list is approaching end to make load more call.

Simple right.

Level 2:

There can be a scenario where there are multiple lists in a single screen which needs pagination.

Now we have to handle the whole process for each lists.

Level 3:

Even complex , where the user can click item from list and then want to continue pagination from the detail page which is swipe-able and also continue from the list after coming back and maintain same list of data on both side.

Where we may have to keep sending next page information between screens.

Level 4:

This can get even complex, when there is same listing in different screens, all needs pagination and have to maintain sync across all the listings.

Solution

Now this problem has a really simple and effective solution which can be used which will abstract the pagination from the views.

Let’s see how.

Step 1

All the listing types will be identified by a unique name or the types can be a Enum.

Step 2

A PageRepository class, this class just have a single responsibility of saving page information of listings.

Step 3

A PaginationChecker, which will tell whether the load more should be called or not.

The process:

• Whenever a screen ask for a list of data, the data will first be retrieved from the database with max count that is available from the server.
• The Data when received will be sent to list and also on the PaginationChecker.
• When the list is scrolled, the currentIndex will be updated in the PaginationChecker and the PaginationChecker can be asked whether load more should be called or not.
• When the PaginationChecker returns true, then on the PageRepository should be called to loadMore().
• On loadMore call, the PaginationChecker can be asked for isNextPageAvailable() if it says true, then the API can be hit with the pagination data from pageRepo.getNextPage(type).
• Before initiating the API call, as the list loading is going to start, the same must be marked in PageRepository that the list type is loading, to prevent repeated calls, till the API completes.
• After the response is received, the new pagination info and the api status needs to be updated in the PageRepository.
• After inserting data into db, the list will be updated reactively and the whole process will continue effortlessly.

A simple abstract illustration of the whole flow will look like:

The whole setup can be reused in any View(Activity/Fragment) with Listing (ViewPager/ RecyclerView/ListView) without needing to implement any pagination again!

The great thing, load a listing and the scrolling can be continued from any screen and all the lists in all the screens will be in sync with the data and also the status of the data, in loading or completed.