Application Development - Paging Approaches

This article was originally written here: https://tomavelev.com/blog/Application%20Development%20-%20%20Paging%20Approaches

Every application that is serious enough, that archives even a partial success, and especially if it archives big size, big scale, data or social reach, needs to show to the users – big, maybe even very big quantity of some data type. Doing this at once – at that point, dumping the huge amounts of information becomes impractical and even impossible. Many times, even the servers could get overwhelmed if the applications are not coded properly, let alone – some end users with desktop or even mobile device.

To resolve this – Paging has been born. But, Paging itself is just a concept that has a lot of user experience and source code / design pattern / variations and approaches and also layers and levels – where it adds complexity, parametrization and logic. I don’t think I could list them all, but, I’ll describe some of them here with places where I’ve seen them used.

DB Layer Paging – All self-respecting Database Systems – relational, non-relational, whatever – have some way, some instruction or procedure to page data so to not flood the application layer. Dive deep into the chosen data storage technology and you’ll probably find it. If it does not support such functionality – it should be red alert for you about it.

Model & Dao (& Service) Layers – In most cases paging could be implemented with:

• PAGE_SIZE (input value)
• offset (number of records) or page number (input value)
• list of records – PAGE_SIZE big (output value)
• total (number of records) or total page count (output value).

The page size could be small number but offset should support very big – depending on the number of records, so the user of the software could go to the last page.

Passing around these two numbers may make APIs more hard to modify and change. For this issue – a search object is often used (and passed as parameters). Besides the basic paging stuff it could hold also – sorting field(s), direction, query parameters and whatever you’d like. Adding this to an object will require – change in the data access layer, change in the setting of these fields, but not in the APIs themselves – if a search object is used.

Controller & Front-end/Display Layers – no matter on what platform, on what display, on what type of service the data is out-placed – somewhere, somehow – one of the following functionalities are used:

Manual page change – The basic approach is to have manual change of the currently viewed page. Even in this simple thing – there are variations.

• First, Previous, Next, Last – Four buttons for jumping to the beginning, next page, previous page and at the end. If the currently viewed page is first or last, or there are too few records – these buttons could be missing or disabled.
• Numbers – the 4 previous buttons are not very data descriptive. The most normal way is to have numbers paging. You could have odd numbers displayed with one – readonly – the current. Example if you have 100 pages and you want to show links to 5 of them – you could display:
  • 1 (readonly), 2,3, […. – this displayed as text] 99,100
  • 1 […], 4, 5(readonly), 6, […], 100
  • 1,2,[…], 98,99,100(readonly)
• Letters – less common way of displaying pages is with letters. When the records with some letter become bigger than the page size, letter repetition must be used with similar to the numbers approach. One example is – Google uses an endless “o” for paging.
• Load more button – for loading next page – after the end of the displayed record is reached. This approach could be little annoying to the end user if he/she wants to go to some deep page.
• Pull to Refresh – for restarting the data view port from the beginning. This approach is used a lot in the mobile world – to reload the records from the first page – with the most recent.

Automatic Page load. This is additional – automatic variation of the option “load more button”. It is also called – Lazy Loading. There are two technical or architectural options when implementing it.

• lazy loading append – it is appending to the visual or to the data layer the newly loaded records and showing the scroll accordingly. This approach could lag the client if the records become too many.
• lazy loading with virtual scroll – to resolve the problem of over-loading data – many UI frameworks have implemented virtual scrolling partially – in the presentation layer or even entirely – in the data loaded to the client and the presentation layer. On whatever screen – the number of records that can be displayed is limited and having more instances of some visual component – HTML DIV, iOS/Android View, Desktop Widget, or whatever – is a waste of memory and a placeholder for bad performance. And Because the scroll itself is a visual element, it could also be tweaked and painted according to the total number of records and not the amount of records loaded into the client layer – archiving this way full page-ability.