kotlin-toolkit
kotlin-toolkit copied to clipboard
readium
A better way to pass `Publication` objects around
Passing complex or large objects between Activity or Fragment instances is notoriously a pain. This is an issue with Readium's Publication objects, which can't be stored in an Intent or arguments Bundle.
The 2.0.0 version introduced a couple of helper extensions on Intent using an in-memory PublicationRepository. An alternative if you have a single-activity app would be to store the Publication into the shared ViewModel. But both of these solutions fail when the app process is killed and restored, which can cause crashes or plainly loose the reader state.
As this is an app architecture issue, and not related to Readium, I suggest we:
- Deprecate the
Intenthelper extensions. - Show the best practice in the test app by:
- Adding a custom
PublicationRepositoryimplementation which also owns aStreamerto openPublicationobjects on the fly when they are not cached (process death). - Passing a
PublicationIdbetweenFragmentandActivityinstances which can be used with thePublicationRepository.
- Adding a custom
The three Bundle extensions should also be deprecated, all of which are also in Intent.kt. They are used the OPDS feeds to pass the Publication from the list to the detail screen of the one that is selected.
Yes, I think that everything in this file should be deprecated eventually.
You're raising a good point about the OPDS feeds, the implemented solution should probably be different for OPDS, as there's no need for a Streamer. Maybe a "repository" implementation for this could be shipped with the lcp module.
I'm wondering if it's wise to return Publication objects from the OPDS parsers instead of the "dumb" Manifest data classes. This would simplify this issue (although TransactionTooLargeException could still occur). For a "streaming" OPDS feed serving publications with a full reading order, the Manifest could always be transformed into a Publication by a Streamer object, if needed.
Yeah ideally we don't want to pass around those large objects in Intents/Bundles, plus Compose doesn't support that anyways. But the OPDS feed implementation is limited to the testapp, and not something developers should follow anyways as it's not greatly written (I know because I rewrote it 😆)
