Hi everyone :android-wave: We’re trying to get mo...

# compose

[Simona Stojanovic]

Hi everyone 👋

We’re trying to get more input from you all on the way you use the Accompanist Pager for Compose :)
Would you be so kind 🌻 to answer any of the following:

- What are some of the most important API features that you found in the Accompanist Pager and some you didn’t find so useful?
- Are most cases covering single full-page paging with tabs or not?
- Have you been using Lazy lists in any way as a replacement, and if so, how?
- Related to the above, have you been using Lazy lists to potentially build smaller pages (like carrousels) and was that sufficient?

Any feedback is much appreciated, thanks a lot! 🤙

[Albert Chang]

Probably not answering your questions but I wonder what the reason is to use lazy layout instead of non-lazy layout. Since the width/height of the items (pages) are fixed, non-lazy layout seems the better choice to me as it should be more performant. Non-lazy layout also makes it possible to control offscreen page limit. I’m using pager built by non-lazy custom layout in my app and it’s working well for me.

[ste]

This thread

HorizontalPager uses LazyRow (which relies in scrollable), so such (very common) layout cannot be implemented

[Colton Idle]

I like lazy pager, but non lazy pager would be cool too.

[Colton Idle]

If we have row and col. and lazy row and lazy col. why not pager and lazy pager?

[Colton Idle]

could probably just get rid of pager completely and just build better support for snapping and such directly into col/row.

[Albert Chang]

I don’t think that’s a good choice because Row/Column will always compose all pages at once which is a waste. By non-lazy layout I mean a custom layout which composes and disposes pages based on the current page index and offscreen page limit, which is similar to lazy layout but can be achieved using non-lazy layout if the width/height of the items is fixed.

[levima]

Hey @Albert Chang thanks for answering this, I was wondering if you got to the point of comparing the performance between your implementation and a lazy implementation? It seems the lazy layout node re-use pool could tip the scales towards a lazy implementation

[Zoltan Demant]

Also probably not answering any of the specific questions (😅) but I thought Id at least bring up a common use-case of mine: synchronizing the pagers currentPage with an external currentPage value. Ive been able to get it working almost perfectly well, but Im still curious if this is something that I can expect to see baked into the library at some point in the future? Im also curious if others are dealing with such scenarios a lot; I for one have a lot of cases where the page should change in response to some user action, and usually that state change happens inside a "viewmodel", sometimes directly in response to an event, and sometimes after doing some async work first.

🌻: 99% of usages for me are full-screen, one of which makes use of tabs as well. My only other case is a carousel, and I decided to use the pager for it because the snapping behavior makes the most sense for that particular screen. Only challenge has been resizing the pager to accomodate the largest item in the currently visible set of items; generally I dont think the solution is perfect as it forces me to either guess a good average size to begin with, or animate the change when its needed - it would be superb to instead have a way to know the exact sizes beforehand, so plus1 for a non lazy variant.

[Albert Chang]

@levima I didn’t compare the performance but generally subcompose layout has quite some overhead so I don’t think it can defeat normal layout in terms of performance. Regarding layout node reusing, I believe we can achieve similar effect using ReusableContent.

[Simona Stojanovic]

Thanks everyone 🙂 this is very useful!