Make useful _AudioNavigator properties public?

[domkm]

_AudioNavigator has many properties that are very useful for displaying audiobooks composed of multiple resources but most of them are currently private. For example, if I want to display the current total time (not the resource time), I need to pull the durations of each resource from the publication, sum durations preceding the current one, and then add the current resource time to that sum. This same logic is in _AudioNavigator, but it's private. I propose that all of these vars be given public getters or that all of this information be included within the MediaPlaybackInfo callback object.

[mickael-menu]

As it is something that updates during the playback, how about adding a resourceStartingTime in MediaPlaybackInfo? Is there any other info that you need?

[domkm]

I'm still working through this to see what else I need, though I do think getting the resource itself in addition to the resource index would be useful. I also wonder if it might be confusing for time (current property) to mean the time in the current resource and for resourceStartingTime to mean the total time of the current location minus the time.

[mickael-menu]

Agreed, all the properties of MediaPlaybackInfo are relative to the resource, so startingTime would be enough. We could argue that having the info relative the publication could be helpful too, especially regarding your other issue #394.

Why do you need access to the Resource object directly? A Resource instance is supposed to have an "owner" that takes care of close()ing it after it's done with it, to avoid leaking handles. Providing the Resource here could be an issue.

Here you need to do publication.get(publication.readingOrder[playbackInfo.resourceIndex]).

[domkm]

Regarding resourceStartingTime/startingTime, I think the prefix with resource makes sense given the existing resourceIndex. Also, my understanding is that throughout this library x refers to a thing related to the current resource while totalX refers to a thing related to the publication. For example, progression/totalProgression and durations/totalDuration. I wonder if it might be the most consistent to add totalTime which is time plus the sum of the previous resource durations. I suppose, for consistency with MediaPlaybackInfo.progress at least, adding totalProgress would also make sense, and I could see using it myself to display playback percent. What do you think?

Regarding my statement about the "resource itself", I was imprecise. Sorry. I did not mean the Resource object, which I wasn't familiar with. I was thinking of the Link object representing the resource, which has href and other potentially useful data. This is a pretty minor point though, as it's easy to look it up given the resourceIndex.

I think, for now, adding totalTime would address my use case.

[mickael-menu]

Regarding resourceStartingTime/startingTime, I think the prefix with resource makes sense given the existing resourceIndex.

Actually, I think we should rename it to readingOrderIndex. It's more accurate and you know that it can be used with publication.readingOrder.

I wonder if it might be the most consistent to add totalTime which is time plus the sum of the previous resource durations. I suppose, for consistency with MediaPlaybackInfo.progress at least, adding totalProgress would also make sense, and I could see using it myself to display playback percent. What do you think?

Sounds reasonable and consistent. 👍 I would use this opportunity to rename it progression and totalProgression too. By the way, this API was still experimental in the last released version, so it's a good time to do this kind of changes.