Start listening to the platform: read the launch URL, then subscribe to deep links.
Idempotent: an existing subscription is removed first, so a hot reload cannot leave two listeners answering the same link.
The launch URL when the application was opened with one.
Remove every listener and unbind. Used on adapter teardown.
Build the intent the adapter dispatches when it starts.
The application always resolves something on launch: the URL it was opened with when there is one, the base path otherwise. That is the native equivalent of the browser adapter's synthetic first navigation.
OptionallaunchUrl: string
The URL the application was opened with, if any.
The launch intent.
Navigate from within the application.
This is what the router's navigator calls, so a router.navigate('/tasks') in a page
re-enters the kernel exactly like a deep link would.
The target URL or path.
Optionalmetadata: unknown
Navigation metadata, the native history.state.
Resolve an intent's URL into an absolute one.
A deep link already carries its scheme and host; an in-app path does not, and the router needs a real URL to match against. Resolving here rather than in the middleware keeps the base URL in one place.
The URL or path to resolve.
The absolute URL.
Register a listener for navigation intents.
The listener to register.
A function removing the listener.
Stop listening to the platform. Safe to call when never bound.
StaticcreateCreate a navigation source.
The source options.
A new navigation source.
Where navigation intents come from, and how the application emits its own.
This is the native counterpart of
windowfor the browser adapter: the object the adapter listens to and that middleware receives as the execution context. It holds no React Native import of its own, so the same instance drives a device and a test.Two things arrive from outside (the launch URL and deep links) and one from inside (
navigate), and all three are the same kind of event, which is why the router does not need to know which one it is answering.