MewX / light-novel-library_Wenku8_Android / 32719812461

36%

master: 36%

Build Type

push

github

Committed by MewX

Commit Message

Turn one page per volume key press, not two

Reported as #190, where the reporter had already found the cause:
dispatchKeyEvent switched on getKeyCode() alone, and it sees both halves
of a press, so ACTION_DOWN and ACTION_UP each called gotoNextPage().

The report notes it only happens in eink mode, and that part is worth
recording because the code gives no hint of it. OverlappedSlider.slideNext
opens with a !mScroller.isFinished() guard. Outside eink mode it then calls
startScroll with a 500ms duration, so the Scroller reads unfinished for the
whole animation and the stray ACTION_UP call, arriving as soon as the key is
released, returns early -- the page turn is even deferred until computeScroll
sees the scroll end. Eink mode skips the Scroller entirely and does scrollTo
plus moveToNext inline, leaving the flag true and the guard permanently open.
So the defect was always in dispatchKeyEvent; the animation length happened to
be de-duplicating it, and eink mode only removed the accident hiding it. Hold
a key past 500ms outside eink mode and it flips a second page there too.

Act on ACTION_DOWN and keep returning true for ACTION_UP, since consuming it
is what keeps the system volume panel off screen -- presumably why this used
dispatchKeyEvent rather than onKeyDown in the first place.

Repeats are dropped as well, which is the one change here that goes past the
report. That same Scroller guard was the only throttle on a held key: eink
mode has nothing equivalent, so a hold raced through pages faster than an eink
panel can even refresh. The cost is that holding a key to page continuously at
roughly 2/sec, which worked outside eink mode, now stops -- emergent behaviour
rather than designed, and nobody has asked for it, but it is a change.

Verified on device.

Co-Authored-By: Claude <noreply@anthropic.com>

Coverage Stats

895 of 3206 branches covered (27.92%)

Branch coverage included in aggregate %.

0 of 4 new or added lines in 1 file covered. (0.0%)

1 existing line in 1 file now uncovered.

2717 of 7000 relevant lines covered (38.81%)

1.84 hits per line