Ατελής κύλιση σε εφαρμογές: τι είναι, αρχή και υλοποίηση

Τι είναι η ατελής κύλιση σε εφαρμογές κινητών;

Ατελής κύλιση (Infinite Scroll) είναι ένα μοτίβο φόρτωσης δεδομένων όπου νέα στοιχεία προστίθενται αυτόματα στο τέλος της λίστας καθώς ο χρήστης κυλάει. Ο χρήστης δεν χρειάζεται να πατήσει κουμπιά «Επόμενο» ή «Φόρτωση περισσότερων» — το σύστημα καθορίζει μόνο του πότε να ζητήσει την επόμενη δόση δεδομένων και εισάγει απρόσκοπτα νέες εγγραφές στην υπάρχουσα λίστα.

Το Infinite Scroll έγινε δημοφιλές χάρη στα κοινωνικά δίκτυα — Twitter, Instagram και TikTok το χρησιμοποιούν ως κύριο μηχανισμό παράδοσης περιεχομένου. Σύμφωνα με τη Nielsen Norman Group (2024), το Infinite Scroll αυξάνει την αφοσίωση κατά 30–50% για εφαρμογές περιεχομένου, καθώς μειώνει το γνωστικό φορτίο: ο χρήστης δεν χρειάζεται να αποφασίσει για μετάβαση στην επόμενη σελίδα. Ωστόσο, για εργασίες που απαιτούν ακριβή πλοήγηση (αναζήτηση, σύγκριση προϊόντων), το Infinite Scroll μπορεί να μειώσει την αποτελεσματικότητα.

Τεχνικά, η ατελής κύλιση αποτελείται από τρία στοιχεία: scroll listener (παρακολουθεί τη θέση κύλισης), threshold (απόσταση από το τέλος της λίστας για ενεργοποίηση φόρτωσης) και pagination mechanism (αίτημα API και εισαγωγή δεδομένων). Η σωστή ρύθμιση του threshold είναι κρίσιμη: με πολύ πρώιμη ενεργοποίηση (1000 px πριν το τέλος) ο χρήστης λαμβάνει περιττά αιτήματα, με πολύ αργή (50 px) θα παρατηρήσει παύση φόρτωσης.

Πώς λειτουργεί το Infinite Scroll: αρχιτεκτονική και μηχανική

Η αρχιτεκτονική του Infinite Scroll βασίζεται στο μοντέλο συμβάντων: το στοιχείο λίστας παράγει ένα συμβάν όταν φτάνει στο όριο κύλισης, το ViewModel το επεξεργάζεται και καλεί το repository για φόρτωση της επόμενης δόσης δεδομένων. Μετά τη λήψη της απάντησης, τα νέα στοιχεία εισάγονται στη λίστα και το UI ενημερώνεται μέσω του adaptor. Αυτή η αλυσίδα πρέπει να είναι ασύγχρονη και να μην μπλοκάρει το νήμα UI.

Ο βασικός αλγόριθμος του Infinite Scroll περιλαμβάνει τέσσερα βήματα. Αρχικοποίηση: κατά το πρώτο άνοιγμα της οθόνης φορτώνεται η πρώτη δόση δεδομένων (page 1 ή cursor = null). Παρακολούθηση: ο scroll listener ελέγχει αν ο χρήστης έχει φτάσει το όριο — συνήθως 200–500 px πριν το τέλος της λίστας. Φόρτωση: αποστέλλεται αίτημα στο API με παραμέτρους σελιδοποίησης, στο UI εμφανίζεται δείκτης φόρτωσης (spinner στο υποσέλιδο). Εισαγωγή: νέα στοιχεία προστίθενται στον adaptor, η θέση κύλισης προσαρμόζεται για αποφυγή άλματος.

Μια κρίσιμη πτυχή είναι το debounce αιτημάτων. Εάν ο χρήστης κυλάει γρήγορα μέχρι το τέλος, ο ενεργοποιητής μπορεί να εκκινηθεί πολλές φορές πριν ληφθεί απάντηση από τον διακομιστή. Χωρίς debounce αυτό οδηγεί σε διπλά αιτήματα (race condition). Η λύση είναι να αποκλείεται ένα νέο αίτημα έως ότου ολοκληρωθεί το προηγούμενο. Η σημαία isLoading στο ViewModel αποτρέπει πολλαπλές κλήσεις: set isLoading = true κατά την αποστολή αιτήματος, επαναφορά κατά τη λήψη απάντησης ή σφάλματος.

Στις πλατφόρμες κινητών, χρησιμοποιούνται εξειδικευμένοι μηχανισμοί για Infinite Scroll. Στο iOS είναι το prefetchDataSource στο UICollectionView, το οποίο ζητά αυτόματα δεδομένα για κελιά εκτός οθόνης. Στο Android — η Paging 3 Library από την Google, η οποία παρέχει έτοιμη αρχιτεκτονική με PagingSource, PagingData και PagingDataAdapter. Η Paging 3 υποστηρίζει RemoteMediator για συνδυασμό δεδομένων δικτύου και τοπικών δεδομένων και διαχειρίζεται αυτόματα την κατάσταση φόρτωσης.

Σελιδοποίηση Cursor-based vs offset-based

Η offset-based σελιδοποίηση χρησιμοποιεί παραμέτρους page και size: page=2, size=20 επιστρέφει εγγραφές 21–40. Αυτή η προσέγγιση είναι απλή στην υλοποίηση, αλλά έχει ένα θεμελιώδες πρόβλημα — αν μεταξύ αιτημάτων προστίθενται ή αφαιρούνται εγγραφές στη βάση δεδομένων, η μετατόπιση διαταράσσεται (ο χρήστης βλέπει διπλότυπα ή κενά). Για ροές με υψηλή συχνότητα αλλαγών (ειδήσεις, σχόλια), η offset-based σελιδοποίηση δίνει εσφαλμένα αποτελέσματα.

Η cursor-based σελιδοποίηση χρησιμοποιεί ένα μοναδικό αναγνωριστικό του τελευταίου στοιχείου (δρομέας): after=id_12345&limit=20. Ο διακομιστής επιστρέφει 20 εγγραφές που ακολουθούν τον καθορισμένο δρομέα. Αυτή η προσέγγιση εγγυάται συνέπεια δεδομένων ανεξάρτητα από εισαγωγές και διαγραφές. Σύμφωνα με το GraphQL Best Practices (2024), η cursor-based σελιδοποίηση συνιστάται για όλες τις real-time εφαρμογές όπου τα δεδομένα αλλάζουν δυναμικά.

Η επιλογή μεταξύ προσεγγίσεων εξαρτάται από τον τύπο εφαρμογής. Για κοινωνικά δίκτυα (Instagram, TikTok) — μόνο cursor-based, καθώς η ροή ενημερώνεται συνεχώς. Για καταλόγους με σπάνιες αλλαγές (κατηγορίες προϊόντων ηλεκτρονικού καταστήματος) η offset-based σελιδοποίηση είναι αποδεκτή. Για υβριδικά σενάρια, η Google συνιστά το Paging 3 RemoteMediator, το οποίο συνδυάζει cursor-based σελιδοποίηση από το δίκτυο με offset-based σελιδοποίηση από την τοπική βάση δεδομένων Room.

Υλοποίηση Infinite Scroll σε iOS και Android

Στο Android, η τυπική προσέγγιση είναι η βιβλιοθήκη Paging 3 από το Jetpack. Το PagingSource ορίζει την πηγή δεδομένων (δίκτυο ή DB), το PagingData περιέχει τμήματα δεδομένων και το PagingDataAdapter τα εμφανίζει στο RecyclerView. Η Paging 3 διαχειρίζεται αυτόματα την απόσταση προφόρτωσης, την επανάληψη και την ανανέωση. Για ενσωμάτωση με δίκτυο χρησιμοποιείται το RemoteMediator: φορτώνει δεδομένα από το API, τα αποθηκεύει στο Room και ενημερώνει το PagingSource για ενημερώσεις. Σύμφωνα με το Google I/O 2024, πάνω από το 60% των Android εφαρμογών με Infinite Scroll χρησιμοποιούν Paging 3.

Παράδειγμα βασικής υλοποίησης Paging 3:

class FeedPagingSource(
    private val api: FeedApi
) : PagingSource<String, Post>() {
    override suspend fun load(
        params: LoadParams<String>
    ): LoadResult<String, Post> {
        val response = api.getFeed(
            cursor = params.key,
            limit = params.loadSize
        )
        return LoadResult.Page(
            data = response.items,
            prevKey = null,
            nextKey = response.nextCursor
        )
    }
}

Στο iOS, για υλοποίηση Infinite Scroll χρησιμοποιείται ο συνδυασμός UICollectionView με prefetchDataSource. Το πρωτόκολλο UICollectionViewDataSourcePrefetching περιέχει τη μέθοδο collectionView(_:prefetchItemsAt:), η οποία καλείται όταν το σύστημα προβλέπει κύλιση σε συγκεκριμένα index paths. Σε αντίθεση με το Android Paging 3, το iOS δεν διαθέτει ενσωματωμένη βιβλιοθήκη σελιδοποίησης — οι προγραμματιστές την υλοποιούν χειροκίνητα ή χρησιμοποιούν λύσεις τρίτων όπως RxSwift + NSLayoutConstraint ή αγωγούς βασισμένους στο Combine.

Παράδειγμα prefetch στο iOS:

extension FeedViewController: UICollectionViewDataSourcePrefetching {
    func collectionView(
        _ collectionView: UICollectionView,
        prefetchItemsAt indexPaths: [IndexPath]
    ) {
        let lastRow = collectionView.numberOfItems(inSection: 0) - 1
        if indexPaths.contains(IndexPath(row: lastRow, section: 0)) {
            viewModel.loadNextPage()
        }
    }
}

Το SwiftUI παρέχει μια πιο δηλωτική προσέγγιση μέσω του τροποποιητή onAppear. Ο προγραμματιστής τοποθετεί ένα ProgressView στο τέλος της λίστας και όταν αυτό εμφανίζεται, καλεί τη φόρτωση της επόμενης σελίδας. Σύμφωνα με το Apple WWDC 2024, τα νέα API AsyncSequence και Swift Algorithms απλοποιούν την υλοποίηση της ατελούς κύλισης παρέχοντας ενσωματωμένους τελεστές chunking και debounce.

Προβλήματα UX της ατελούς κύλισης και λύσεις τους

Το κύριο πρόβλημα UX του Infinite Scroll είναι η απώλεια υποσέλιδου και πλοήγησης. Στα ηλεκτρονικά καταστήματα, ο χρήστης συχνά θέλει να μεταβεί στο υποσέλιδο για επαφές ή συνδέσμους. Η ατελής κύλιση καθιστά το υποσέλιδο μη προσβάσιμο — μετακινείται συνεχώς προς τα κάτω καθώς φορτώνονται δεδομένα. Η λύση είναι η προσθήκη ενός floating κουμπιού γρήγορης κύλισης προς τα πάνω (FAB) ή η σταθεροποίηση του υποσέλιδου ξεχωριστά από τη λίστα.

Το δεύτερο πρόβλημα είναι η απουσία ιστορικού κύλισης. Αν ο χρήστης είδε ένα ενδιαφέρον προϊόν στη θέση 3, κύλησε μέχρι τη θέση 50 και μετά πάτησε «Πίσω» — επιστρέφει στην αρχή της λίστας και αναγκάζεται να κυλήσει ξανά στη θέση 50. Η λύση είναι η αποθήκευση της θέσης κύλισης στο ViewModel ή η χρήση state restoration σε επίπεδο Activity/UIViewController. Το iOS υποστηρίζει NSUserActivity για επαναφορά θέσης, το Android — onSaveInstanceState.

Το τρίτο πρόβλημα είναι η απόδοση με χιλιάδες στοιχεία. Αν η εικονοποίηση δεν έχει ρυθμιστεί, μετά από 500–1000 φορτωμένα στοιχεία η εφαρμογή αρχίζει να επιβραδύνεται λόγω αύξησης της κατανάλωσης μνήμης. Η λύση είναι η χρήση εικονοποίησης RecyclerView ή UICollectionView, η οποία διατηρεί στη μνήμη μόνο ορατά + προφόρτωμένα κελιά. Ο περιοδικός καθαρισμός παλαιών δεδομένων (discard pages πέρα από Ν σελίδες) μειώνει επίσης το φορτίο.