core

The catalogue, the session, the downloads and the reader — everything the SDK does that isn't drawing a screen of its own.

Take this module alone to build your own interface on top of the catalogue. Everything starts at CGS, which hands out the four services once CGS.init has run:

How results are shaped

Three shapes cover the catalogue and the session, and which one you get says how the call behaves:

• CgsResult — a one-shot call that either succeeded or failed with a CgsError. Nothing is thrown.

• StateFlow<CgsStreamState<T>> — a single item, observed. A failure can still hold the copy last cached, so a transient network problem never has to blank the screen.

• PaginatedResource — a list. Observe its state, call loadNextPage() as the user scrolls, refresh() to force a round trip.

A download is an Item of its own, with a state and a progress to follow.

Content follows the session: sign in as another account or switch profile, and every flow restarts against the new session on its own, dropping what it held. Each one is also bound to the CoroutineScope you pass in and stops five seconds after nothing collects it, so nothing keeps running once your screen is gone. Downloads are kept per profile as well: Download.trackedIssues lists the active profile's.

Opening an issue or an article

Every entry point is an open overload — what is being opened is said by the argument, not by the name — and each takes identifiers, so any of them can be called straight from a tap: Reader.open takes an issue id, an ArticleId, or a list of them to swipe through. Each launches a full-screen Activity of its own and returns immediately; the reader fetches what it needs behind its own loading state. An issue already on the device opens offline, one that is not is downloaded on the spot — and kept, as if the download had been started through Download. An article is fetched as it opens, so it needs a connection unless it was opened moments before.

CGS.reader().open(activity, issueId, page = 12)

Downloading ahead of time, and following a download's progress, is what CGS.download is for. Reading never requires it.

Every open also takes a theme, the reader's palette. Left out, the reader draws with the engine's own colors; to match your brand, subclass OneReaderColors and override only the colors you care about:

class BrandReaderColors : OneReaderColors() {
    override val primary = OneReaderColor.parse("#E10E49")
}

CGS.reader().open(activity, issueId, theme = OneReaderTheme(colors = BrandReaderColors()))

The rendering itself is done by the OneReader engine, which this module brings in as a dependency (co.cafeyn:cgs-reader). Its theme — OneReaderTheme, OneReaderColors and OneReaderColor, in com.milibris.onereader.theme — is the only part of it meant to be used; nothing else in it is meant to be called.

Permissions

This module and the engine it depends on add these permissions to your merged manifest, and declare the activities the reader opens along with them, so there is nothing to add on your side:

All of them are install-time permissions — added by the manifest merger, never requested at runtime.