You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since ObjectBox 2.0.0 there is an implementation of LiveData<PagedList< DATAENTITYMODEL >>,
which was a very good integration with androids paging2 library back then.
Thanks for your suggestion! As things keep changing (think Jetpack Compose) and this is often very use case specific, I don't think we will provide this.
Maybe the time is ripe to implement this on the objectbox-side of things?
From my point of view for the following reasons:
The workaround to convert the ObjectBoxDataSource to a paging3-compatible PagingSource by using the paging3-extension asPagingSourceFactory() on the instance returned by ObjectBoxDataSource.Factory(query) works in general, but the initial loading (with a RemoteMediator mediating between a Retrofit-instance and ObjectBox) always loads three pages instead of one, producing significant unnecessary overhead. I think this bug is somewhere between PositionalDataSource and asPagingSourceFactory, so I doubt this will be fixed by Google.
The paging3-library from Google is still relevant and a self-made paging-implementation is non-trivial, especially with an already existing implementation based on paging3, with support for both RecyclerView- and LazyColumn-usage (I am still in the process of migration to Jetpack Compose, so this would help both).
Jetpack Compose support for paging3 is stable since paging3 version 3.2.0, see Google documentation on collectAsLazyPagingItems.
collectAsLazyPagingItems works on a Flow<PagingData< DATAENTITYMODEL >> so it is exactly what is needed to support Jetpack Compose properly.
Everybody would benefit from a centrally maintained version of the current paging-standard-library on android, Google's paging3-library.
It would make sense to deprecate ObjectBoxDataSource since paging2 is deprecated. And since it currently resides wrongly in the objectbox-dependency objectbox-android-objectbrowser, it would be practical to move it to its own dependency objectbox-android-paging3, anyway.
When Google removes support for paging2-DataSource in paging3, ObjectBox would not have any working support for Googles paging-libraries anymore.
@ajans Thanks for your interest and details! To be honest, I don't think we'll have the time to add support for this (or any other future adapters for UI frameworks). But we would be open to refer to a third party project that makes this available.
Hi Everyone, @greenrobot-team I would like to share an implementation here which uses ObjectBox and Flow:
Before reading this page, sorry I just searched for implementations, I did my own version of Pagination with ObjectBox and Kotlin Flow
Which is independent from JetPack.
An example
Maybe there are a lot of things you don't like. Feel free to give me a feedback to improve.
Ok, The main disadvantage or limitation or whatever of my approach is that it is not based on an ObjectBox-native observer/subscriber mechanism. So that, it is glued to kotlin flow mechanism.
Dear Sir @greenrobot-team : Was my implementation coherent with the ObjectBox way ? I didn't read the full documentation of Objectbox so exists the possibility that i didn't use a concept or an implementation. (to re-invent the wheel that some programmer of greenrobot-team already has done).
Please, Be kind if I am far from ObjectBox way of programming. I just wanted to implement a Layer within " Flow-ObjectBox way" to paginate in a Composable view.
My idea was to create something like:
val mSomeEntityBox:Box<SomeEntity> =ObjectBox.mBoxStore.boxFor(SomeEntity::class.java)
mSomeEntityBox.query().build().flowPaginated(final long offset, final long limit)
and in some way change the offset and limit.
Working like:
@fllaryora I don't have time to review this, but on a quick look the most important thing I saw: make sure queries are closed and in general any native resources are cleaned up once done using them. Otherwise, this can leak transactions and cause issues due to object finalization taking a long time.
Activity
greenrobot-team commentedon Sep 30, 2024
Thanks for your suggestion! As things keep changing (think Jetpack Compose) and this is often very use case specific, I don't think we will provide this.
Maybe have a look at the source of the v2 paging source for inspiration to write a v3 one.
ajans commentedon Aug 15, 2025
Maybe the time is ripe to implement this on the objectbox-side of things?
From my point of view for the following reasons:
ObjectBoxDataSourceto a paging3-compatiblePagingSourceby using the paging3-extensionasPagingSourceFactory()on the instance returned byObjectBoxDataSource.Factory(query)works in general, but the initial loading (with aRemoteMediatormediating between aRetrofit-instance andObjectBox) always loads three pages instead of one, producing significant unnecessary overhead. I think this bug is somewhere betweenPositionalDataSourceandasPagingSourceFactory, so I doubt this will be fixed by Google.RecyclerView- andLazyColumn-usage (I am still in the process of migration to Jetpack Compose, so this would help both).collectAsLazyPagingItems.collectAsLazyPagingItemsworks on aFlow<PagingData< DATAENTITYMODEL >>so it is exactly what is needed to support Jetpack Compose properly.ObjectBoxDataSourcesince paging2 is deprecated. And since it currently resides wrongly in the objectbox-dependencyobjectbox-android-objectbrowser, it would be practical to move it to its own dependencyobjectbox-android-paging3, anyway.DataSourcein paging3, ObjectBox would not have any working support for Googles paging-libraries anymore.greenrobot-team commentedon Aug 18, 2025
@ajans Thanks for your interest and details! To be honest, I don't think we'll have the time to add support for this (or any other future adapters for UI frameworks). But we would be open to refer to a third party project that makes this available.
lucf15 commentedon Aug 24, 2025
@ajans here is an implementation based on LimitOffsetPagingSource by
androidxwhich uses ObjectBox:fllaryora commentedon Jul 24, 2026
Hi Everyone,
@greenrobot-team I would like to share an implementation here which uses ObjectBox and Flow:
Before reading this page, sorry I just searched for implementations, I did my own version of Pagination with ObjectBox and Kotlin Flow
Which is independent from JetPack.
An example
Maybe there are a lot of things you don't like. Feel free to give me a feedback to improve.
If you are curious see the test
Ok, The main disadvantage or limitation or whatever of my approach is that it is not based on an ObjectBox-native observer/subscriber mechanism. So that, it is glued to kotlin flow mechanism.
Dear Sir @greenrobot-team : Was my implementation coherent with the ObjectBox way ? I didn't read the full documentation of Objectbox so exists the possibility that i didn't use a concept or an implementation. (to re-invent the wheel that some programmer of greenrobot-team already has done).
Please, Be kind if I am far from ObjectBox way of programming. I just wanted to implement a Layer within " Flow-ObjectBox way" to paginate in a Composable view.
My idea was to create something like:
and in some way change the offset and limit.
Working like:
but with flows.
Thanks in advance
I hope My code be useful for someone who is looking for a paginated solution of objectBox with kotlin flow.
greenrobot-team commentedon Aug 10, 2026
@fllaryora I don't have time to review this, but on a quick look the most important thing I saw: make sure queries are closed and in general any native resources are cleaned up once done using them. Otherwise, this can leak transactions and cause issues due to object finalization taking a long time.