Fix reader scrolling and soften predictive back - #12
Conversation
|
Warning Review limit reached
Next review available in: 51 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughPredictive-back animation calculations now use direct gesture progress, smoothed fading, revised document transforms, identity home frames, and progress-based cancellation durations. Compose applies these frames inline, and the document container no longer consumes pointer events needed by the embedded WebView. ChangesPredictive-back behavior
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant PredictiveBackGesture
participant HomeScreen
participant DocumentSurface
participant WebView
PredictiveBackGesture->>HomeScreen: Update home frame from gesture progress
PredictiveBackGesture->>DocumentSurface: Update document frame from gesture progress
DocumentSurface->>WebView: Pass unconsumed motion events
Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
@coderabbitai review |
✅ Action performedReview finished.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
app/src/main/java/de/unbow/mora/ui/MoraApp.kt (1)
326-342: 🚀 Performance & Scalability | 🔵 Trivial | ⚡ Quick winHome's predictive-back frame is always Identity — drop the redundant computation.
calculatePredictiveDocumentBackFrame(...).homeis unconditionallyPredictiveDocumentBackTransform.Identity, same asPredictiveDocumentBackFrame.Idle.home. Both branches here yield an identical, constant result, so the full frame calculation (fade smoothing, scale/translation/cornerRadius math) runs every frame purely to read a constant.♻️ Proposed simplification
.graphicsLayer { - val frame = if (predictiveBackVisualActive) { - calculatePredictiveDocumentBackFrame( - progress = predictiveBackProgress, - swipeEdge = predictiveBackSwipeEdge, - maximumTranslation = maximumBackTranslation, - maximumCornerRadius = maximumBackCornerRadius, - ) - } else { - PredictiveDocumentBackFrame.Idle - } - scaleX = frame.home.scale - scaleY = frame.home.scale - alpha = frame.home.alpha + scaleX = 1f + scaleY = 1f + alpha = 1f }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@app/src/main/java/de/unbow/mora/ui/MoraApp.kt` around lines 326 - 342, Remove the predictiveBackVisualActive conditional and calculatePredictiveDocumentBackFrame call from HomeScreen’s graphicsLayer; use the constant PredictiveDocumentBackTransform.Identity values for home scale and alpha directly, preserving Home’s existing non-animated appearance.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@app/src/main/java/de/unbow/mora/ui/MoraApp.kt`:
- Around line 326-342: Remove the predictiveBackVisualActive conditional and
calculatePredictiveDocumentBackFrame call from HomeScreen’s graphicsLayer; use
the constant PredictiveDocumentBackTransform.Identity values for home scale and
alpha directly, preserving Home’s existing non-animated appearance.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 7af92e93-ec4e-46d5-9519-5244837e5661
📒 Files selected for processing (3)
app/src/main/java/de/unbow/mora/ui/MoraApp.ktapp/src/main/java/de/unbow/mora/ui/PredictiveDocumentBack.ktapp/src/test/java/de/unbow/mora/ui/PredictiveDocumentBackTest.kt
## Summary - bump Mora to `versionName 0.3.1` / `versionCode 5` - record the v0.3.0 tag and hidden Draft as a permanently blocked, unpublished exact-asset candidate - align the English and Chinese READMEs, roadmap, project status, changelog, and release guide with the v0.3.1 stable path ## Why Real-device testing of the exact v0.3.0 Draft found Reader touch interception and an overly forceful predictive-Back transition. PR #12 fixes those regressions on `main`; a distributed replacement must use a new version name and version code rather than moving or republishing the failed tag. ## Validation - `.\gradlew.bat --no-daemon --no-build-cache --rerun-tasks testDebugUnitTest lintDebug assembleDebug` - Debug APK badging: `de.unbow.mora`, `versionName 0.3.1`, `versionCode 5`, `minSdk 26`, `targetSdk 36` - verified the live v0.3.0 annotated tag target, hidden Draft status, and Draft APK SHA-256 before recording the blocked audit entry - `git diff --check` ## Release boundary This PR does not create a tag, build a signed candidate, alter the v0.3.0 tag or Draft, or publish a Release. After merge and green `main` CI, the protected signed v0.3.1 candidate still requires the complete exact-asset real-device gate and explicit maintainer approval before tagging. Co-authored-by: bjcdeshu <186153588+bjcdeshu@users.noreply.github.com>
1 participant
Summary
WebViewswipesRoot cause
The document
Surfaceconsumed every pointer change atPointerEventPass.Final.That prevented the embedded
AndroidView/WebViewfrom receiving a usablevertical gesture. On the exact blocked v0.3.0 Draft, a controlled 1000 px center
swipe left visible Section 9/10/11 bounds unchanged.
The old predictive transition also combined 45% window translation, a
1.10→1.00 Home zoom, 0.90 outgoing scale, and a fade concentrated into the final
20%. Current-run capture reproduced the maintainer's report: large spatial
movement and dense document/Home text overlap.
Behavior after the fix
gesture distance and hides the toolbar
Section 40
the gesture outside its local hit target
no longer visually dominant
The motion direction follows current Android Compose guidance for custom in-app
predictive Back: keep the destination stable and use a restrained outgoing
transform driven by gesture progress.
Validation
.\gradlew.bat --no-daemon --no-build-cache --rerun-tasks testDebugUnitTest lintDebug assembleDebugright-edge progress drag, left/right predictive Back completion
git diff --checkRelease boundary
The immutable
v0.3.0tag and hidden Draft remain blocked and will not be moved,republished, or have assets replaced. This PR intentionally does not change
version metadata. After merge and green
mainCI, release finalization will movethe stable target to a new patch version and repeat the complete signed
exact-asset gates.
Summary by CodeRabbit
New Features
Bug Fixes