3.0.0

[mickael-menu]

:loudspeaker: We're beginning a new development cycle with breaking changes to prepare the 3.0 release of the Readium Kotlin Toolkit. Starting from now:

• develop will contain only critical bugfixes and dependency upgrades
• a new v3 branch will host new features and breaking changes, until it's ready for production

Here's an (incomplete) list of changes to be expected.

Major new features

• New TTS and audio navigators based on Jetpack media3, supporting background playback.
• Streaming of ZIP archives (e.g. LCP-protected audiobooks hosted on a remote server).

Breaking changes

• [x] Prefix all resources with readium_.
• [x] Enable Explicit API mode.
• [x] Remove localized exceptions strings from our modules. This is the responsibility of the apps.

Shared

• [x] Remove the legacy compressedLength Link property.
• [x] Remove Ref<Publication> from the Publication.Context (see this comment).
• [x] Remove ReadingProgression.TTB/BTT/AUTO.
• [x] Remove the Parcelable conformance on Publication, and deprecate the PublicationRepository. ❓ https://github.com/readium/kotlin-toolkit/issues/65

Navigator

• [x] Remove all the Activity navigators.
• [x] Extract the VisualNavigator's presentation and goLeft/goRight in a new interface dedicated to "flowing" publications, as it wouldn't make sense for a video-based publication.
• [x] Remove older settings API.
• [x] Remove the HTTP server.
• [x] Remove highlight.js

LCP

• [x] We need to make the database calls in License.kt asynchronous and remove allowMainThreadQueries() on the Room setup (see https://github.com/readium/r2-lcp-kotlin/pull/116).
• [x] Fix lifecycle issue in LcpDialogAuthenticating

Delayed until a next version

• Media overlays
• Migrate all usage of JSONObject to kotlinx-serialization.
• Isolate every non-public APIs shared among Readium modules into a private internal module.
• The app should handle footnotes (in R2BasicWebView.onTap).

[alexwhb]

@mickael-menu I'm a big fan of this project and all the work you guys are doing. I'm curious if you guys have consider moving to Kotlin Multiplatform rather than porting code to Swift or vise versa. Obviously the UI stuff has to be on the respective platforms, but I think you could simplify your codebase a decent amount with KMM. Just a thought.

Also I wrote a very hacked together media overlay implementation a while back, but it's certainly not a very well thought through implementation. Wondering if media overlays are something you've thought about how to implement? I know it's on your radar since it's in the road map... If time allows I'd be interested in possibly collaborating on an implementation. My org has a decent amount of ebooks with media overlays, and I'd love to integrate that feature at some point into our app. I've spent probably a month or so poking around this codebase, so I generally know where things are and how it works. Let me know if that'd be something you'd be interested in.

[mickael-menu]

@alexwhb Thank you! I've looked into KMP and found it really promising. Personally I have more faith in sharing a "backend" codebase in Kotlin than going all the way with Flutter or ReactNative. However, this is not a priority at all and most of the code that would benefit from KMP is already done. This year will be focused on the Navigator which will be obviously much more platform-specific.

Yes we would definitely be interested in a contribution around Media Overlays! Last year we were working on a specification for representing media overlays-like metadata in the Readium Web Publication Manifest, but it's a bit stale at the moment: https://github.com/readium/webpub-manifest/pull/83

Also I'll be working soon on Text-to-Speech. There might be some work that could be shared between media overlays and TTS.

[alexwhb]

@mickael-menu I think that makes a lot of sense in regards to KMP. You basically have written all the fundamental logic already so it'd be more work to port at this point. Also totally agree on your point in regards to Flutter/ReactNative. That's my favorite aspect of KMP is that it's not really intended to make the UI side multiplatform. I think it's a generally bad idea to go away from native UI unless you are prototyping something out.

Awesome! I'll take a look at your linked issues. I could definitely see TTS having a good amount of overlap which would be a huge productivity gain. I'm finishing up some stuff on my app currently, but I think I should have some time on the side or in the next few weeks to look at things again. I'll contribute to the discussion of the best way to move forward at the very least. :) Hopefully we can get some good ideas flowing on how to best approach things.

As always very much appreciate your time and the work you guys are doing. I tried writing an ebook player a several years back, from a lot less of an established project and it was super overwhelming so this is an incredibly exciting project.

[Docik]

Dear Readium team, thank you for your hard work, you can't imgine, how useful Readium is for me and my team. Do you have any (at least rough) estimate, when version 3.0 could be released?

[mickael-menu]

Probably before the next 6 months.

[ctechdev]

Compared to the previous estimate for v3, are there any different forecasts for the release?

[qnga]

Some new features need changes deeper than expected. I hope we'll be able to release the v3 by Christmas.

[qnga]

Everything's done. v3 coming soon.