Firebaseui-android: Load More option for recyclerview

[santoshgistto]

Load More option for recyclerview

[puf]

This is definitely something we'd love to add to FirebaseUI at some point. Thanks for the feature request!

[santoshgistto]

thanks for response :)

[astromme]

Is #110 still the best option? Got here after posting http://stackoverflow.com/questions/41133864/loading-more-items-on-user-scroll-with-firebaseindexrecycleradapter

[astromme]

Any news on this? I see https://github.com/firebase/FirebaseUI-Android/pull/7 but it appears it never got merged?

Also see http://stackoverflow.com/questions/32396840/dynamically-change-the-limit-of-a-firebase-query-reference-on-android

[WillieCubed]

@samtstern @SUPERCILEX
Hey, with Firestore's release, can we revisit this? I think this is definitely more attainable now.

[samtstern]

Yes we definitely can! I've gotten a working prototype of paginating
infinite scroll to work with Firestore so I know it's possible, although
mine was too messy to publish.

I'm thinking efficient infinite scroll is actually more useful than
something where we expect the developer to explicitly load more but open to
discussing both.

On Fri, Oct 6, 2017, 6:55 PM Willie Chalmers III [e-mail]
wrote:

@samtstern https://github.com/samtstern @SUPERCILEX
https://github.com/supercilex
Hey, with Firestore's release, can we revisit this? I think this is
definitely more attainable now.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/firebase/FirebaseUI-Android/issues/17#issuecomment-334903115,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIEw6lixJhwy3BflNiIboP6nunVAmcuQks5sptotgaJpZM4GKcFY
.

[saneeshvs]

With firestore ui release should we be able to pagination? @puf

[samtstern]

@saneeshvs no this feature is still not implemented.

[saneeshvs]

@samtstern will this feature be implemented in the future

[samtstern]

Maybe! We'd like to do it but have not yet found the time or settled on a
design we like.

On Wed, Nov 1, 2017, 7:08 PM Saneesh V S [e-mail] wrote:

@samtstern https://github.com/samtstern will this feature be
implemented in the future

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/firebase/FirebaseUI-Android/issues/17#issuecomment-341190915,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIEw6kO4zGp16abLZnb5yYiQDZkSHVcAks5syLOLgaJpZM4GKcFY
.

[saneeshvs]

@samtstern Hoping to see this feature soon

[kumarkeviv]

@samtstern do we have any update on this feature? As this will significantly reduce the un-necessary read operations in Firestore.

If its planned for later releases, could you please share the concept behind how you did it? So meanwhile we can try to implement of our own.

Thanks for the help.

[Vansangkima]

Been waiting on this as well

[mahmoudshawkat]

I've been trying to implement this feature on a project I work on, tired of thinking of the most efficient way to do it, can't wait to see it as a built in feature in FirebaseUI.

If you can kindly share the idea behind it, that would be deeply appreciated

Best wishes

[Morphipapa]

We would also love to see this feature.

[bigahega]

Any news on the issue?

[tamimattafi]

hello, any news ?

[kumarkeviv]

@SUPERCILEX @samtstern We would love if you could provide an update on this. I understand that the development team is busy, but its among the most critical feature in almost all the application.

Even if this is not possible to add in Firebase UI at this time, could you please @samtstern share the logic of your version of implementation you mentioned before? This will at-least give us an idea on how to build our own implementation.

[Jawnnypoo]

If you all are interested, I have created a sort of proof of concept of being able to load more when reaching the end of the list here:

https://github.com/Commit451/FirestoreAdapter

It is written in Kotlin and I am still working through some issues, such as the fact that the list gets scrolled back up to the top after rotation and other things like that, but it does work as far as loading more items until reaching the end of the collection within Firestore.

[samtstern]

Everyone: we appreciate your interest, but posting comments asking for updates is not helpful. We have not designed this feature nor written any code for it yet. When we do, the development will be transparent (as usual) and you'll be able to follow along in pull requests and branches.

[dazza5000]

how would you all like this to work - a load more header/foot or infinite scroll?

[svidata]

@samtstern Hello, we need pagination because as lists tend to increase the app starts to lag and the only way is to write custom adapter, and going through using child listeners and keeping track of end keys and start keys to make each batch of data fit. And this makes the code messy and there is no good way of implementing it manually. We just want to know if it is a feature that might be included in firebase ui. Thanks.

[dazza5000]

I was curious how you wanted it to work. Does it auto load more? Does
it have a load more button at the bottom? How many does it load
initially and each new load?

On 1/27/18, svidata [e-mail] wrote:

Hello, we need pagination because as lists tend to increase the app starts
to lag and the only way is to write custom adapter, and going through using
child listeners and keeping track of end keys and start keys to make each
batch of data fit. And this makes the code messy and there is no good way of
implementing it manually. We just want to know if it is a feature that might
be included in firebase ui. Thanks.

--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/firebase/FirebaseUI-Android/issues/17#issuecomment-361015922

[samtstern]

Ok I have been working on a paginated RecyclerView adapter for Firestore. The one thing I can get working in a rock-solid way has the following caveats:

• Not realtime. If an item is updated/removed/etc after it has been originally fetched the update will not be shown in the current session.
• No live additions. If the user has already scrolled to the very bottom and an item is added at the end of the query, this will not be detected.

Here's what it does have:

• A paging adapter that can dynamically load/unload "pages" of data to keep memory use low.
• A scroll listener to turn the paging adapter into an "infinite scroll" adapter (optional, you can page manually)

Would this be useful to people? It's different than anything we've provided before but still could be useful for a lot of content-driven apps like news, ecommerce, etc.

[saneeshvs]

Yes it will be useful

On Fri, 2 Mar 2018, 12:56 a.m. Sam Stern, [e-mail] wrote:

Ok I have been working on a paginated RecyclerView adapter for Firestore.
The one thing I can get working in a rock-solid way has the following
caveats:

• Not realtime. If an item is updated/removed/etc after it has been
  originally fetched the update will not be shown in the current session.
• No live additions. If the user has already scrolled to the very
  bottom and an item is added at the end of the query, this will not be
  detected.

Here's what it does have:

• A paging adapter that can dynamically load/unload "pages" of data to
  keep memory use low.
• A scroll listener to turn the paging adapter into an "infinite
  scroll" adapter (optional, you can page manually)

Would this be useful to people? It's different than anything we've
provided before but still could be useful for a lot of content-driven apps
like news, ecommerce, etc.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/firebase/FirebaseUI-Android/issues/17#issuecomment-369702047,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ASmeMeKhnLuBjUDPKWgWYVbpZ0fJxDMRks5taEtHgaJpZM4GKcFY
.

[kumarkeviv]

@samtstern yes that will be helpful for now. Thank you so much

[samtstern]

@kumarkeviv @saneeshvs thanks for the quick response! Would you mind sharing what you'd use it for? Just so I can make sure it's actually useful for your cases.

[kumarkeviv]

@samtstern we have an educational application, with one section called "Mashup" which show users the trending news in the area of their interest. It will be very helpful for us.

[samtstern]

Working on this in #1178

[saneeshvs]

I'm using it for a video sharing app

On Fri, Mar 2, 2018 at 2:10 AM, Sam Stern [e-mail] wrote:

@kumarkeviv https://github.com/kumarkeviv @saneeshvs
https://github.com/saneeshvs thanks for the quick response! Would you
mind sharing what you'd use it for? Just so I can make sure it's actually
useful for your cases.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/firebase/FirebaseUI-Android/issues/17#issuecomment-369723636,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ASmeMZL_iJCXbuDOPexF9y7_PiMCSee5ks5taFzDgaJpZM4GKcFY
.

--
Regards,
Saneesh V. S.

[dokenedgar]

@samtstern I'd love the pagination option for a project am working on whereby a user gets lists of shops selling particular items, and the number is a bit large. Any update on the pagination option?

[lahrm]

I want to use the infinite scrolling for a boot sale app. I need to first display the most recent ones then give the user the possibility to scroll to get older ones

[jordond]

@samtstern I am building chat functionality into my app, and am interested in using the paging adapter your working on. Would it suit my needs? I have a RecyclerView with setReverseLayout enabled. I need to load the initial batch of messages (say 50). Then when new messages come in, they need to be added to the bottom of the view (beginning of list). Then when the user scrolls it needs to load in the previous messages. I'm currently using a solution I rolled myself, and it works (with editing, and deleting included). But I'd much rather use a more official solution.

[samtstern]

@jordond at least for now, the paging adapter I am working on in #1178 will not work for your use case because it does not automatically detect new item additions (unless they happen to be picked up in a next page load)

[samtstern]

1178 has been merged. This means the feature will launch in version 3.4.0.

If anyone wants to try it now and give early feedback follow these instructions for using SNAPSHOT builds and try the 3.4.0-SNAPSHOT version:
https://github.com/firebase/FirebaseUI-Android#snapshot-builds

Docs here:
https://github.com/firebase/FirebaseUI-Android/blob/version-3.4.0-dev/firestore/README.md

[samtstern]

The Firestore paging adapter is still coming in the next version (renamed 4.0.0) and I have opened #1296 to discuss if we can apply the same techniques to get an RTDB adapter.

[steurt]

So the new PagedList with corresponding PagedListAdapter was announced by Google as part of the Paging library of Jetpack. See https://developer.android.com/topic/libraries/architecture/paging/.

Maybe Firebase UI's paging adapter shoud support this by offering DataSource implementations?

[samtstern]

That's exactly what we've done for Firestore! We're offering a
DataSource. Check out the 4.0.0-dev branch.

On Thu, May 10, 2018, 3:13 PM Tymen Steur [e-mail] wrote:

So the new PagedList with corresponding PagedListAdapter was announced by
Google as part of the Paging library of Jetpack.

Maybe Firebase UI's Paging adapter shoud support this by offering
DataSource implementations?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/firebase/FirebaseUI-Android/issues/17#issuecomment-388201884,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIEw6rTg8mZKekbT2gpscFYijRP3F8YGks5txLtzgaJpZM4GKcFY
.

[samtstern]

4.0.0 has been released with Firestore paging support.

[samtstern]

Closing this very old issue since we have finally release (some) paging support, even though it's only for Firestore and not RTDB. If we add more we can have a concrete discussion in a separate issue, like #1256.

Thank you to everyone who contributed here!