Native Back Navigation Control

[deodad]

Mini Apps are built on top of web standards and the back button has long been a part of the web. For some Mini Apps it'd be useful for users to be able to navigate back using a native control.

Proposal
An opt-in flag a Mini App can set when initializing that indicates it wants native back navigation support. This flag can be included in the ready options. If this option is set, Mini Apps can expect a native control to be made available to users and to receive backNavigationTriggered events when the user triggers that control. It will be up to Mini Apps to handle those events as they see fit for their application.

Hosts can render this control as they see fit. For instance, on web a button in the header may be used and on mobile a native horizontal swipe gesture may be used (see Instagram shopping WebView experience for an example of this).

Who needs this and who doesn't
Mini Apps that are designed as web apps (i.e. paragraph, pinetree, kiwi news). Many Mini Apps won't need this and can rely on simple controls rendered within their apps. Thus opt-in instead of opt-out.

Questions
Is a single flag sufficient or do we need explicit controls for hiding and showing? For instance, when an app first opens there is likely no well defined behavior for back. An complementary approach could let Mini Apps enable it via a call like enableBack() and disable it via disableBack() so that it can be enabled / disabled based on whether back is well defined. My bias is to ship something simple and avoid additional complexity for apps and hosts (like a disabled state for the button). For instance, closing the app / no-op both seem like reasonable default behaviors apps.

Mini Apps are built on top of web standards and the back button has long been a part of the web. For some Mini Apps it'd be useful for users to be able to navigate back using a native control.

SDK Changes
Add an option enableBackNavigation to the ready action with type boolean | 'web'.

• If false no navigation control will be rendered by the parent.
• If true the parent will include a native navigation control that will trigger backNavigationTriggered events. It's up to the applicatin to handle these events and trigger the appropriate behavior.
• If 'web' the parent will include a native navigation control that will trigger backNavigationTriggered events and a default handler will be setup that hooks into the web History / Navigation APIs to trigger back automatically.

Defaults to false.

Add an backNavigationTriggered event to the SDK emitter.

Draft PR here:
#329