Full vertical scroll (or less internal components)

[sdsantos]

I'm using Readium with a specific requirement: full vertical scroll, instead of the existing mix of vertical scroll + swipe to switch chapters. This currently requires skipping a lot of the library UI code and managing my own RecyclerView of chapters with R2WebView items inside. With the version currently in develop this kind of usage becomes harder because a lot of important navigator components are internal like EpubNavigatorViewModel and WebViewServer.

a) Could the visibility of those components be revised?
b) A ViewPager is currently being used for displaying chapter resources. Could a RecyclerView with a PagerSnapHelper be an interesting alternative? That way switching between all pages, scroll + chapter pages, or full scroll would be way easier.

[mickael-menu]

I'm using Readium with a specific requirement: full vertical scroll, instead of the existing mix of vertical scroll + swipe to switch chapters.

That's interesting. If you already implemented it, could you share a screencast of what it looks like? We are not particularly happy with the horizontal swipes across chapters and would be opened to have a different behavior.

a) Could the visibility of those components be revised?

Unlikely, because they would increase the API surface and prevent any significant implementation changes. We used to have too much stuff public and are trying to reduce the public API to keep it maintainable and the private implementation flexible.

That being said, we're open to make public some components as "helpers", if they are really independent and their APIs clearly defined. WebViewServer and ReadiumCss could make good candidates. Though this is pretty low priority and we want to be careful when exposing private details.

b) A ViewPager is currently being used for displaying chapter resources. Could a RecyclerView with a PagerSnapHelper be an interesting alternative? That way switching between all pages, scroll + chapter pages, or full scroll would be way easier.

The EPUB navigator didn't change much since the beginning. There was an attempt to migrate to ViewPager2, but it was aborted because it is only a good fit for paginated modes. There's also an old issue suggesting just that, but not much else.

In the context of Navigator 2, we (core developers) are experimenting with Jetpack Compose to implement a new navigator. At the moment, we don't plan to improve the way resources are displayed in the current EPUB navigator. However, if you want to tackle this in the current implementation, I think it would be a welcome contribution.

[sdsantos]

That's interesting. If you already implemented it, could you share a screencast of what it looks like? We are not particularly happy with the horizontal swipes across chapters and would be opened to have a different behavior.

Here's how it's looking with the latest develop branch. I haven't migrated to the new ReadiumCss so the layout isn't how it should be.

readium_scroll.1.mp4

Unlikely, because they would increase the API surface and prevent any significant implementation changes. We used to have too much stuff public and are trying to reduce the public API to keep it maintainable and the private implementation flexible.

That being said, we're open to make public some components as "helpers", if they are really independent and their APIs clearly defined. WebViewServer and ReadiumCss could make good candidates. Though this is pretty low priority and we want to be careful when exposing private details.

Right now this means I had to copy over the WebViewServer, ReadiumCss, Layout and HtmlInjector. And I will either have to duplicate the EpubNavigatorViewModel as well, with more internal dependencies likely, or just copy the code that maintains the Preferences API + ReadiumCss.

[mickael-menu]

Here's how it's looking with the latest develop branch. I haven't migrated to the new ReadiumCss so the layout isn't how it should be.

This looks great. Why don't you contribute it back into Readium? That would solve the problem of accessing internal components.

As a first step and to limit regressions until it's battle tested, it could be a copy of the EpubNavigatorFragment, or better have the EpubNavigatorFragment be able to switch between the current implementation and the RecyclerView one based on a config option.

[sdsantos]

This looks great. Why don't you contribute it back into Readium? That would solve the problem of accessing internal components.

Currently, it's not an implementation that is easy to detach from the specifics of the app we're building. Also, it does not support many of the configurations and settings available, many are hardcoded. Maybe with some time, I would be able to make it more abstract so it would be fit for sharing.

[mickael-menu]

Alright, I'm looking forward to it if you find the time to extract your implementation!

So for this, you used a RecyclerView, and the PagerSnapHelper is used when in paginated mode? For the continuous scroll, do you resize the WebViews every time the HTML height changes, and disable any scrolling directly in the web view?

[sdsantos]

So for this, you used a RecyclerView, and the PagerSnapHelper is used when in paginated mode? For the continuous scroll, do you resize the WebViews every time the HTML height changes, and disable any scrolling directly in the web view?

I'm using a plain RecyclerView. We don't support a paginated mode, just a full vertical scroll. RecyclerView items naturally expand with the contents of the WebView, it's the RecyclerView that scrolls and not the WebViews.

[qnga]

One more question! How do you deal with the loading time? For instance when a fling would get beyond the already loaded resources. When working on that, I felt like it would be a mess to handle this edge case.

[sdsantos]

One more question! How do you deal with the loading time? For instance when a fling would get beyond the already loaded resources. When working on that, I felt like it would be a mess to handle this edge case.

Before the WebView has loaded we show a progress bar for each chapter, and the view has some minimum fixed height. So basically once you reach a chapter that hasn't loaded yet, you can scroll through chapters very quickly, which is a bit weird, but works out well if you tapped a link to go to another chapter far away.

The good thing is that without the WebServer, chapters are loading very fast now.

[qnga]

Got it! Thanks.