fix(#98): initial device computation breaking sensor usages

[gladiuscode]

This PR fixes #98

Summary by CodeRabbit

• Bug Fixes
  • Improved device orientation handling during startup, pause, resume, and shutdown for more consistent behavior.
  • Ensured sensors and rotation monitoring are enabled/disabled at the right times to avoid flicker and unnecessary usage.
  • Added safeguards so orientation sensors aren’t turned off while actively in use, improving stability and battery efficiency.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Warning

Rate limit exceeded

@gladiuscode has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 25 minutes and 39 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

📥 Commits

Reviewing files that changed from the base of the PR and between e1b1ced and 1542be2.

📒 Files selected for processing (1)

• android/src/main/java/com/orientationdirector/implementation/OrientationDirectorModuleImpl.kt (3 hunks)

Walkthrough

Enables orientation sensors earlier and refines lifecycle handling in OrientationDirectorModuleImpl: conditional sensor re-enable on resume, guarded sensor disable on pause/destroy during initial-orientation computation, unconditional AutoRotationObserver toggles on resume/pause/destroy, and broadcast receiver registration/unregistration adjusted; init notes added.

Changes

Cohort / File(s)

Summary

Sensor & Observer Lifecycle android/src/main/java/com/orientationdirector/implementation/OrientationDirectorModuleImpl.kt

Enables orientation sensors earlier during initialization; on host resume re-enables sensors only when previously enabled or when initial device orientation isn't computed, while AutoRotationObserver is always enabled; on host pause/destroy disables sensors conditionally (guarded by initial-computation and in-use checks), always disables AutoRotationObserver, and unregisters the broadcast receiver; adds guards in initial-orientation completion and onOrientationAnglesChanged plus NOTE comments documenting init rationale.

Sequence Diagram(s)

sequenceDiagram
  autonumber
  participant Host
  participant OrientationSensors
  participant AutoRotationObserver
  participant BroadcastReceiver

  Host->>OrientationSensors: enable early during init (NOTE(1.init))
  Host->>AutoRotationObserver: (init) configure (not necessarily enabled)
  Host->>BroadcastReceiver: register on resume

  alt hostResume
    Host->>OrientationSensors: if (sensorsEnabled || !initialComputed) enable
    Host->>AutoRotationObserver: enable (unconditional)
    Host->>BroadcastReceiver: register
  end

  alt hostPause or hostDestroy
    Host->>OrientationSensors: if (sensorsEnabled || !initialComputed) disable (guard: not in-use && initialComputed)
    Host->>AutoRotationObserver: disable (unconditional)
    Host->>BroadcastReceiver: unregister
  end

  note over OrientationSensors: onOrientationAnglesChanged applies initial-computation guard\nand avoids disabling while "in use"

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

• Inspect lifecycle branches: init, hostResume, hostPause, hostDestroy for correct conditional logic.
• Verify race conditions around initial-orientation computation and "in-use" sensor checks.
• Confirm broadcast receiver registration/unregistration pairing and AutoRotationObserver enable/disable are always symmetric and leak-free.

Possibly related PRs

• feat(android): introduce new rotation sensor #80 — Related changes to sensor enable/disable and rotation-vector handling that interact with the lifecycle logic here.
• fix(android): broken interface computation #89 — Touches the same Kotlin class and alters device/interface orientation computation; likely overlaps with these lifecycle/state changes.

Poem

🐰 I woke the sensors with a curious hop,

Kept them waiting 'til the first angle stop.
On resume I peek; on pause I may rest,
Guards in my paws keep the logic best.
Hop lightly, rotate true — carrot-powered cues! 🥕

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately references issue #98 and identifies the core problem: initial device computation breaking sensor usages, which is the root cause of orientation detection failures in release builds.
Linked Issues check	✅ Passed	The code changes directly address the linked issue #98 by fixing the sensor management lifecycle to ensure orientation sensors work correctly in release builds, enabling proper device orientation detection for modal content rotation.
Out of Scope Changes check	✅ Passed	All changes are focused on fixing the sensor lifecycle management in OrientationDirectorModuleImpl.kt, which is directly scoped to resolving the orientation detection bug reported in issue #98.

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

♻️ Duplicate comments (1)

android/src/main/java/com/orientationdirector/implementation/OrientationDirectorModuleImpl.kt (1)

51-54: Same observer lifecycle issue as noted in the resume callback.

See previous comment regarding decoupling AutoRotationObserver from the areOrientationSensorsEnabled flag.

📜 Review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between aa5f12b and 2884cc9.

📒 Files selected for processing (1)

• android/src/main/java/com/orientationdirector/implementation/OrientationDirectorModuleImpl.kt (2 hunks)

🔇 Additional comments (2)

android/src/main/java/com/orientationdirector/implementation/OrientationDirectorModuleImpl.kt (2)

39-40: LGTM! Enables sensors for initial device orientation computation.

This correctly enables orientation sensors during initialization to ensure the initial device orientation is computed before the first user interaction. The guard at lines 171-173 will automatically disable these sensors after the first orientation reading if the user hasn't explicitly called enableOrientationSensors().

---

169-174: LGTM! Guard correctly prevents premature sensor disabling.

The condition !didComputeInitialDeviceOrientation && !areOrientationSensorsEnabled correctly ensures sensors are only disabled after initial computation if the user hasn't explicitly enabled them via enableOrientationSensors(). This prevents disabling sensors that should remain active.

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 2884cc9 and c8862ab.

📒 Files selected for processing (1)

• android/src/main/java/com/orientationdirector/implementation/OrientationDirectorModuleImpl.kt (2 hunks)

🔇 Additional comments (2)

android/src/main/java/com/orientationdirector/implementation/OrientationDirectorModuleImpl.kt (2)

47-47: Partial fix for AutoRotationObserver lifecycle management.

The PR partially addresses the past review comment by making AutoRotationObserver lifecycle unconditional (always enabled on resume at line 47, always disabled on pause at line 54 and destroy at line 61). This prevents the resource leak when enableOrientationSensors() is never called.

However, the lifecycle management is still complex due to the three-state system (init pending, user-enabled, user-disabled). The critical race condition flagged in my previous comment must be addressed to fully resolve the initialization issues.

Based on past review comments, this change addresses the AutoRotationObserver resource leak concern.

Also applies to: 54-54, 61-61

---

169-174: Guard logic is correct but depends on race condition fix.

The guard to disable sensors after initial computation (when areOrientationSensorsEnabled is false) is a good optimization. The dual condition check is correct:

• !didComputeInitialDeviceOrientation: ensures this only runs on the first orientation change
• !areOrientationSensorsEnabled: ensures sensors stay enabled if user explicitly enabled them

However, this code may never execute if the race condition (flagged in my earlier comment) occurs. Once the race condition is fixed, this logic will work as intended.