react-native-image-stitcher 0.1.2 → 0.2.0

package/src/camera/useDeviceOrientation.ts

@@ -12,42 +12,49 @@
  * the app is orientation-locked: window dimensions don't change
  * when only the device rotates.
  *
- * 2026-05-18 (Issue #3) — rewritten on top of `expo-sensors`
- * `DeviceMotion` (CoreMotion-fused on iOS, SensorManager on
- * Android).  The previous implementation used
- * `react-native-sensors` raw accelerometer with an Android-only
- * sign convention (`y > 0` ⇒ portrait), which silently failed on
- * iOS — Apple's CoreMotion convention is `y < 0` ⇒ portrait
- * because device-Y points from the phone's bottom to the top,
- * and gravity in that frame is `-Y`.  Users on iOS saw the hook
- * stuck at its initial value ('portrait') regardless of physical
- * rotation, which cascaded into wrong panorama bake-rotation and
- * a broken landscape band layout.
+ * 2026-05-21 (v0.2 — Expo modules removal) — rewritten back onto
+ * `react-native-sensors` accelerometer.  `expo-sensors`'
+ * `DeviceMotion` was used previously (Issue #3 / 2026-05-18) because
+ * it normalised Android signs to iOS convention for us, but that
+ * pulled the entire Expo modules runtime into every consuming
+ * host app — a heavy tax for one orientation hook (see
+ * `docs/host-app-integration.md`).  We now do the same sign
+ * normalisation explicitly in JS and stay on `react-native-sensors`
+ * (already a peer dep for the pan-guide gyroscope).
  *
  * Sign conventions used here (per platform docs):
  *
- *   iOS (CMDeviceMotion.accelerationIncludingGravity, reported in
- *   m/s² in the device reference frame):
- *     portrait              → y ≈ -9.8
- *     portrait-upside-down  → y ≈ +9.8
- *     landscape-left  (home indicator on user's RIGHT) → x ≈ +9.8
- *     landscape-right (home indicator on user's LEFT)  → x ≈ -9.8
+ *   iOS (CMAccelerometerData, reported in G's; react-native-sensors
+ *   passes through, in m/s²-ish G-multiples):
+ *     portrait              → y ≈ -1   (gravity along device -Y)
+ *     portrait-upside-down  → y ≈ +1
+ *     landscape-left  (home indicator on user's RIGHT) → x ≈ +1
+ *     landscape-right (home indicator on user's LEFT)  → x ≈ -1
  *
- *   Android (Sensor.TYPE_ACCELEROMETER, reaction-force convention):
- *     portrait              → y ≈ +9.8   ← opposite sign vs iOS
+ *   Android (Sensor.TYPE_ACCELEROMETER, reaction-force convention,
+ *   m/s²):
+ *     portrait              → y ≈ +9.8  ← OPPOSITE SIGN vs iOS
  *     portrait-upside-down  → y ≈ -9.8
  *     landscape-left        → x ≈ -9.8
  *     landscape-right       → x ≈ +9.8
  *
- *   We flip the Android x/y to match the iOS convention before
- *   classification so the rest of the logic stays platform-
- *   independent.  The classification then unambiguously maps to
- *   the user-visible `DeviceOrientation` enum.
+ *   We flip the Android x/y signs to match the iOS convention
+ *   before classification, so the classifier stays platform-
+ *   agnostic and operates entirely in iOS-convention values.
+ *   (Previous react-native-sensors implementation, pre-Issue-#3,
+ *   forgot this — Apple's CoreMotion convention is `y < 0` ⇒
+ *   portrait, but the old code used `y > 0` ⇒ portrait, so iOS
+ *   was stuck at the initial value regardless of rotation.  Don't
+ *   regress.)
  */
 
 import { useEffect, useState } from 'react';
-import { DeviceMotion } from 'expo-sensors';
-import type { DeviceMotionMeasurement } from 'expo-sensors';
+import { Platform } from 'react-native';
+import {
+  accelerometer,
+  setUpdateIntervalForType,
+  SensorTypes,
+} from 'react-native-sensors';
 
 
 export type DeviceOrientation =
@@ -57,59 +64,43 @@ export type DeviceOrientation =
   | 'landscape-right';
 
 
-/// Threshold (m/s²) above which gravity dominance is considered
-/// conclusive.  5 m/s² out of ~9.8 means the phone is at least ~30°
-/// tilted toward that axis — comfortable for stable orientation
-/// classification without flipping on minor wobbles.
-const DOMINANT_AXIS_THRESHOLD = 5.0;
+/// Threshold above which a single axis is considered to dominate.
+/// Phone-at-rest under gravity reads ~1 G on whichever axis is
+/// aligned with vertical; the off-axis reading is ~0.  Anything
+/// more than half a G (~5 m/s² on Android, ~0.5 on iOS in G's) is
+/// safely in "dominant" territory without flipping on small wobbles.
+/// We compare against the magnitude after sign-normalisation, so
+/// the threshold is platform-dependent: iOS reports in G's,
+/// Android in m/s².
+const DOMINANT_AXIS_THRESHOLD_IOS = 0.5;        // G's
+const DOMINANT_AXIS_THRESHOLD_ANDROID = 5.0;    // m/s²
 
 /// Sample at ~10 Hz — plenty for orientation detection (phones
 /// don't physically flip faster than this).
 const SAMPLE_INTERVAL_MS = 100;
 
 
-function classify(x: number, y: number): DeviceOrientation | null {
-  // 2026-05-18 (Issue #3 round 2) — re-derived sign convention.
-  //
-  // Through expo-sensors, BOTH platforms normalize to the iOS
-  // CoreMotion gravity-vector convention: stationary phone reports
-  // the gravity vector itself in the device frame.  Device axes:
-  // +X points from phone-left to phone-right; +Y from phone-bottom
-  // to phone-top; +Z out of the screen toward the viewer.
-  //
-  // Per-orientation gravity-vector signs in the device frame:
-  //
-  //   portrait (upright)      → y ≈ -9.8
-  //     Phone-Y points up in world; gravity is along device -Y.
-  //
-  //   portrait-upside-down    → y ≈ +9.8
-  //     Phone-Y points down in world; gravity is along device +Y.
-  //
-  //   landscape-left  (Apple: home indicator on user's RIGHT;
-  //                    phone rotated 90° CCW from portrait):
-  //     phone-X axis points from user-bottom to user-top in this
-  //     orientation, so gravity (world-down) is along device -X.
-  //     → x ≈ -9.8
-  //
-  //   landscape-right (Apple: home indicator on user's LEFT;
-  //                    phone rotated 90° CW from portrait):
-  //     phone-X axis points from user-top to user-bottom, so
-  //     gravity is along device +X.
-  //     → x ≈ +9.8
-  //
-  // The earlier implementation had an Android-specific axis flip
-  // baked in.  Removed — expo-sensors normalizes Android signs to
-  // match iOS, and the platform branch was producing wrong values
-  // (Android portrait → reported as portrait-upside-down; iOS
-  // landscape-left → reported as landscape-right).
+function classify(
+  x: number,
+  y: number,
+  threshold: number,
+): DeviceOrientation | null {
+  // Inputs are in iOS-convention gravity-vector signs:
+  //   +X points from phone-left to phone-right; +Y from phone-
+  //   bottom to phone-top; +Z out of the screen toward the viewer.
+  //   At rest under gravity:
+  //     portrait (upright)   → y ≈ -g  (phone-Y points up; gravity is -Y)
+  //     portrait-upside-down → y ≈ +g
+  //     landscape-left       → x ≈ -g  (phone-X points up; gravity is -X)
+  //     landscape-right      → x ≈ +g
   if (Math.abs(y) > Math.abs(x)) {
-    if (y < -DOMINANT_AXIS_THRESHOLD) return 'portrait';
-    if (y > DOMINANT_AXIS_THRESHOLD) return 'portrait-upside-down';
+    if (y < -threshold) return 'portrait';
+    if (y > threshold) return 'portrait-upside-down';
   } else {
-    if (x < -DOMINANT_AXIS_THRESHOLD) return 'landscape-left';
-    if (x > DOMINANT_AXIS_THRESHOLD) return 'landscape-right';
+    if (x < -threshold) return 'landscape-left';
+    if (x > threshold) return 'landscape-right';
   }
-  // Phone face-up or face-down (z dominates): keep the previous
+  // Phone face-up or face-down (z dominates) — keep the previous
   // orientation rather than flicker.
   return null;
 }
@@ -119,21 +110,26 @@ export function useDeviceOrientation(): DeviceOrientation {
   const [orientation, setOrientation] = useState<DeviceOrientation>('portrait');
 
   useEffect(() => {
-    DeviceMotion.setUpdateInterval(SAMPLE_INTERVAL_MS);
+    setUpdateIntervalForType(SensorTypes.accelerometer, SAMPLE_INTERVAL_MS);
+
+    const isAndroid = Platform.OS === 'android';
+    const threshold = isAndroid
+      ? DOMINANT_AXIS_THRESHOLD_ANDROID
+      : DOMINANT_AXIS_THRESHOLD_IOS;
 
     let last: DeviceOrientation = 'portrait';
-    const sub = DeviceMotion.addListener((m: DeviceMotionMeasurement) => {
-      const g = m.accelerationIncludingGravity;
-      // First emissions can be null on cold start while CoreMotion
-      // warms up; skip until data arrives.
-      if (!g) return;
-      const next = classify(g.x, g.y);
+    const sub = accelerometer.subscribe(({ x, y }) => {
+      // Normalise Android reaction-force convention to iOS gravity
+      // convention by flipping signs.  No-op on iOS.
+      const gx = isAndroid ? -x : x;
+      const gy = isAndroid ? -y : y;
+      const next = classify(gx, gy, threshold);
       if (next && next !== last) {
         last = next;
         setOrientation(next);
       }
     });
-    return () => sub.remove();
+    return () => sub.unsubscribe();
   }, []);
 
   return orientation;

package/src/index.ts

@@ -54,6 +54,9 @@ export type {
 // ─────────────────────────────────────────────────────────────────────
 // Hosts running their own non-AR capture flow can reuse this hook to
 // get the same translation-budget gating logic <Camera> uses internally.
+// As of v0.2 this hook is implemented on `react-native-sensors` raw
+// accelerometer + JS IIR gravity subtraction (was `expo-sensors`'
+// fused DeviceMotion through 0.1.x — see the hook's file header).
 export { useIMUTranslationGate } from './sensors/useIMUTranslationGate';
 export type {
   UseIMUTranslationGateOptions,