PAGINATION_CHANGED not reliable to indicate finished state, in scroll view (continuous)

[hz0324]

We want to make a loading cover for our reading app. When user open a book, this loading cover will make the reading area invisible, so that we can do some neccessary manipulation to the page before it is ready for the user. But we don't know WHEN to dimiss the cover.

My question is: Is there a init ready alike event in readiumJs that can be used for this purpose? Or, how can I make sure readiumJs is done generating new DOM elements (aka. init finished)?

PS: I have tried ReadiumSDK.Events.CONTENT_DOCUMENT_LOADED event, but it is not quite suitable for what we need.

Please help. Thanks

[danielweck]

Try ReadiumSDK.Events.PAGINATION_CHANGED:

reader.on(ReadiumSDK.Events.PAGINATION_CHANGED, function (pageChangeData)
{

});

See how it's used in the ReadiumJS cloud reader / Chrome app, to switch the loading indicator (spinner) off: https://github.com/readium/readium-js-viewer/blob/master/src/js/EpubReader.js#L451

[hz0324]

Thank you sir. I have tested the behaviour on Chrome Readium Reader, I found it is not a concrete solution to our need.

In CONTINUOUS mode, the spinner can show forever untill I scroll my mouse (it is not happen all the time, but quite common when you reopen a book at middle of certain chapter). Continuous-scroll mode is also the reason why we can not use ReadiumSDK.Events.CONTENT_DOCUMENT_LOADED. In AUTO and DOCUMENT scroll mode, you can make sure there is only one document loaded at initiation, so you can confidently do something in its callback. But for CONTINUOUS croll mode, there will be uncertain number of documents loaded, which makes ReadiumSDK.Events.CONTENT_DOCUMENT_LOADED unreliable. (Actually If I know how many documents will be loaded at any given circumstance, the problem will be solved as well. But I got no clue about this.)

Could you please share some information about how Readium make a decision about "well, I need to load another document now" in CONTINUOUS scroll mode? And whether there is a concrete clue or sign I can make use of to make sure Readium is done with loading the LAST document at the moment in CONTINUOUS mode?

Thanks.

[danielweck]

Your observations about ReadiumSDK.Events.CONTENT_DOCUMENT_LOADED are correct.

I haven't checked the emitted ReadiumSDK.Events.PAGINATION_CHANGED in continuous scroll mode for some time. So, from the top of my head: a naive implementation could use debounce in order to collate consecutive quick-firing events, but this would be quite a crude design approach.

To be honest, I assumed (perhaps wrongly ... I need to go check this) that ReadiumSDK.Events.PAGINATION_CHANGED was only raised at the moment when all documents in the scrollview's pool are "ready" (even those that are completely hidden / outside of the visible viewport). To be tested...

[rkwright]

Re-opening since it sounds like the issue isn't really closed...