Skip to content

[Android] useRive remains null when loaded event is delivered before subscription #448

Open
Open
[Android] useRive remains null when loaded event is delivered before subscription#448

Description

@woals4815
woals4815
opened on Sep 29, 2026

Description

On an Android physical device, useRive() can remain null indefinitely even though the native animation is loaded and playing. We observed RiveReactNativeLoaded:<viewTag> being dispatched by the JS event emitter with zero listeners, followed by useRive() subscribing 224 ms later.

As a result, effects guarded on riveRef never apply initial data-binding values. Navigation/re-entry can change the outcome.

Environment

  • rive-react-native: 9.8.3 (runtime reproduction)
  • React Native: 0.83.4, Hermes, New Architecture / Bridgeless
  • Expo: 55 development build
  • Android: 14 / API 34, Samsung SM-A135N physical device
  • StrictMode enabled
  • Remote .riv URL, auto-bind enabled
  • Android Rive SDK override: 11.6.1
  • Existing local patch validates downloaded bytes and uses File + setRiveFile instead of setRiveBytes; diagnostic-only logging was added to native load/emit and JS ref/subscription callbacks. This is not an unmodified-package reproduction.

Observed sequence

Same native view, viewTag=13066. Times relative to native load start:

Time Event
0 ms Native load starts
144 ms Downloaded bytes received
195 ms Native configuration finishes
196 ms Native emits RiveReactNativeLoaded:13066
200 ms JS RCTDeviceEventEmitter.emit executes; listenerCount(eventName) === 0
403 ms Ref callback receives an object without internalNativeEmitter
424 ms First useRive() subscription registered
560 ms Another subscription registered for the same tag
Later No loaded callback received; two waiting listeners remain

We temporarily observed the JS emitter by wrapping emit, recording only loaded-event names, timestamps and listener counts, then invoking the original method. No artificial delay or event replay was introduced in this reproduction. The observer was removed afterwards.

Native emit timing alone is insufficient evidence because delivery to JS can be delayed; another view successfully received an event emitted before its JS subscription. The zero-listener observation above is at actual JS dispatch.

In an earlier occurrence, manually replaying the loaded event for the affected view caused the hook to expose its ref and the existing binding effect to apply successfully. No server state or asset change was needed.

Relevant implementation

useRive() registers the listener only when its ref callback receives a Rive handle, and calls setRef(node) only inside that listener. It does not check whether loading has already completed. A late subscriber cannot recover the missed notification.

There are two associated lifecycle observations:

  • The forwarded ref is attached both to the outer View and to useImperativeHandle, explaining the callback receiving a non-Rive object before the Rive handle.
  • The loaded subscription is removed only on receipt. Detach/re-attach can leave duplicate waiting subscriptions. In the observed failure, the first event was already missed before the subsequent re-attachment.

Reproduction scope

This was captured in an existing app by entering a screen with a remote Rive preview and initial data-binding setters, then navigating away and entering again. It is timing-dependent. We do not yet have a standalone public reproduction project or a redistributable asset.

Conceptual usage (not a standalone verified repro):

const [setRiveRef, riveRef] = useRive();
useEffect(() => {
  if (!riveRef) return;
  riveRef.setNumber('acc_head', selectedValue);
}, [riveRef, selectedValue]);

return <Rive ref={setRiveRef} url={assetUrl}
  artboardName="main_artboard" stateMachineName="main_state_machine"
  dataBinding={AutoBind(true)} autoplay style={{width: 250, height: 250}} />;

Expected behavior / question

The hook should expose a ready handle even if native loading completes before the JS listener is attached. A retained readiness result / an await-ready API, or subscription followed by a current-readiness check, could avoid relying on a transient notification. Detach and stale responses also need handling.

Is there a supported solution in the legacy runtime, or is migration to @rive-app/react-native and its awaitViewReady() path recommended?

Related: #333 (initial binding issues), #216 (onLoad API). This report specifically concerns the Android loaded event delivered before subscription sequence.

We inspected v9.8.5's source and found the same hook structure, but have not yet runtime-tested 9.8.5. We will follow up with that result separately.

Activity

  1. woals4815 commented on Sep 29, 2026

    @woals4815
    woals4815
    on Sep 29, 2026
    Author

    Confirmed on 9.8.5 with the default Android SDK

    The disk-space blocker is resolved. I rebuilt and installed rive-react-native 9.8.5 on the same Samsung SM-A135N (Android 14, RN 0.83.4 / Expo 55, Hermes / Bridgeless, StrictMode).

    This test used app.rive:rive-android:11.7.2, confirmed through Gradle dependencyInsight. The previous custom download patch was not applied: this was the npm 9.8.5 implementation with diagnostic logs only; the original setRiveBytes loading path was retained. No artificial subscription delay or corrective event replay was used.

    Reproduction

    The home view initially loaded and applied the equipped accessory correctly. Opening the pet-detail screen created a new Rive view whose loaded notification was lost. The same accessory data was present, but the new view stayed unaccessorized and useRive() remained null.

    For the affected viewTag=760:

    Event Device epoch ms
    Native load starts 1790666126476
    Native receives bytes 1790666126629
    Native emits loaded event 1790666126702
    JS emitter dispatch; listenerCount = 0 1790666126849
    First useRive subscription 1790666128756
    Binding effect skipped, ref=null 1790666128903
    StrictMode re-subscription 1790666129311
    Binding effect skipped again 1790666129356

    The first subscription came 1907 ms after actual JS event dispatch. No loaded callback was received for tag 760. Runtime inspection confirmed that the rendered Rive native view was tag 760 and the hook ref was still null, despite the expected numeric accessory value being available.

    For comparison, the preceding home view (tag 598) dispatched its loaded event with two listeners, received it, and applied the binding successfully. So the failure is timing-dependent within the same run.

    This confirms the originally reported late-subscription failure also occurs on 9.8.5 + its default Android runtime 11.7.2, without our prior download behavior patch. This remains an instrumented existing-app reproduction, not a standalone public example.

  2. woals4815 commented on Sep 30, 2026

    @woals4815
    woals4815
    on Sep 30, 2026
    Author

    How we addressed this locally

    We implemented a local patch-package fix on 9.8.3 after the 9.8.5 reproduction above. It is currently in an internal review PR, not a claim of a released upstream fix or a production rollout.

    The approach is subscribe first, then query retained native readiness, rather than adding a delay or repeatedly applying binding values.

    Native side

    • Each native view retains { generation, ready }.
    • Starting a new load advances the generation and clears readiness; successful view configuration marks it ready. These state changes are emitted through the existing RiveReactNativeLoaded:<viewTag> channel, now with a payload.
    • Added a Promise-returning native getReadyState(viewTag) method so a late subscriber can recover a completion it missed.
    • Late successful URL-load callbacks are ignored if their generation is no longer current. Disposal invalidates the retained readiness.
    • Android snapshot access runs on the UI thread. On iOS, event registration and snapshot methods explicitly share the main queue, as do readiness updates and URL response handling.

    JS side

    Conceptually:

    const subscription = emitter.addListener(loadedEventName, acceptState);
nativeModule.getReadyState(viewTag).then(acceptState);

    acceptState ignores older generations, duplicate states, and callbacks after detach. Within one generation, a late ready: false snapshot cannot undo a newer ready: true notification.

    The hook keeps its subscription for same-view reloads, clears it on ref detach/replacement, and exposes a fresh handle identity after a new ready generation so existing binding effects run again. We also removed forwarding the external Rive ref to the outer ordinary <View>, leaving useImperativeHandle responsible for the Rive handle.

    Our app's separate safe-ref wrapper now delegates to the same patched hook instead of maintaining another loaded-event subscription. The package's source, CommonJS and ESM entrypoints are kept in sync.

    This requires rebuilding the native app; it is not a JS-only OTA fix. A retained awaitViewReady() result, as used by the successor runtime, is another way to provide the essential guarantee. We chose snapshot + subscription to fit the existing legacy bridge and to observe reloads without introducing native pending waiters.

    Validation performed

    • Regression checks against the patched implementation cover completion before subscription, snapshot/event duplicates, stale snapshots, same-view reloads, queued callbacks after detach, and snapshot failure followed by recovery.
    • Related hook/binding/component tests: 36 passing tests across 3 suites; TypeScript and lint passed.
    • Android library compilation and the device-compatible app build passed.
    • iOS Rive Pod target compiled successfully for the arm64 simulator. iOS app runtime/UI verification is still pending.
    • On the same Android device, the fitting-room accessory displayed correctly after entry/re-entry, and selecting a different accessory updated the preview.
    • We also detached and reattached the JS ref of an already loaded native view. Readiness recovered with no additional loaded event (observed event count stayed 2 → 2), the listener count returned from 0 → 1, and subsequent preview updates worked. The temporary observer was removed after verification.

    We have not completed every app flow or production validation, and this is still an existing-app test rather than a standalone public reproduction. Sharing the implementation contract and results here in case they help with a supported legacy fix or migration guidance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions