Good example of using Readium as a core application component for navigation?

[mcpierce]

I'm working on an OPDS reader application (cross platform, targeting iPad and Android tablets) to use with my server project (ComiXed). I've been using Readium to retrieve the OPDS feed, and am currently struggling with getting it to download a publication from the server.

Is it possible to use Readium as the core of the app's server navigations? IOW, is there a way I can provide a component of Readium the server details (hostname, port, initial uri, username, password) and have it do the interactions, and just have my app respond to state changes during navigation? It would certainly make the application easier to write.

I looked but didn't see a decent example of how to do this. Is there an example somewhere of just this sort of application?

[qnga]

Hi,
If I understand correctly, what you are looking for is a piece of UI enabling users to navigate through OPDS feeds. It would require some decisions about UI so it's out of the scope of Readium and we don't have one.

All what Readium can do for you is parsing responses from your OPDS server and, for convenience, doing the HTTP requests (see OPDS1Parser and OPDS2Parser).

[mcpierce]

No that’s actually he opposite of what I asked. I want to attach my own UX components to Readium to display the links, publications, etc. when a user wants to navigate our server. I’m asking for an example app that’s shows how one would initiate events in readium to talk to a server and provide navigation events.

[mcpierce]

Sure. What I imagine it would be like is to have a core object where you set the connection details (address, port, protocol, username, password), register a callback method that is invoked when a set of navigation links is returned, a callback for updating the application state with the details for a single publication, and a similar one for when a publication is downloaded.

The core object would also have a method that takes as input a URI (initially it would be given the root URI for the site), call the server, process the payload, and invoke the appropriate callback for either links or a single publication.

There would also be a way to register a translator that converts the various domain objects from Readium's internal representation to an application-specific representation.

With that sort of framework, a developer could integrate Readium into the core of an app like the one I'm writing and focus on responding to events (initiating navigation, displaying links or a publication, storing a publication after download) rather than the details of connecting to the site.

[mickael-menu]

The toolkit already has APIs to return an OPDS model from a URI, which contains navigation links, publications, etc. If you pass your own instance of HttpClient with your own DefaultHttpClientCallback, you can handle the basic auth authentication (as well as other OAuth authentication schemes).

You can also use the HttpClient to download a publication from a link. Readium can't select the download link for you because it depends on a lot of factors (which format the user wants to download, which DRM is supported by the app, etc.).

The model and maybe some additional helpers to dig into the publication links could definitely be improved to facilitate the implementation, but I don't see how a callbacks approach would be more helpful here. Most of the interactions themselves are UX and Readium is not expected to replace your view models.

[mcpierce]

> The model and maybe some additional helpers to dig into the publication links could definitely be improved to facilitate the implementation, but I don't see how a callbacks approach would be more helpful here. Most of the interactions themselves are UX and Readium is not expected to replace your view models.

Thanks for that. I thought about this over vacation and the area where I think the callbacks (either lambdas or listener objects) would work would be to update the state for an application. Not exactly replacing the view model but enhancing it by updating it in response to network requests.

So, for example, an app written with Jetpack Compose could register its ViewModel as an end point with Readium when the framework receives the payload of a request (a list of feeds, a publication, etc.). This would then trigger a recomposition based on that update. Then the UI would only need to make an asynchronous call into the framework to do the retrieval.

If this already exists in the framework, I guess what I need are some good examples of such.

[mickael-menu]

This is already what you get in the individual OPDS2Parser.parseUrlString() APIs. It returns a ParseData which contains either a feed or a publication.

There are no need for callbacks because there are no push events from the OPDS server. You (the app) supplies an URL to an OPDS feed and Readium returns the parsed response as a native model. When you get the response you can update the state.

[qnga]

Have a look at the test apps. That's all what we have.