Package App Ui

Package App Ui module

Owns the shared customer screens, interactions, styles and approved brand assets.

Why there is one canonical set of screens

The shared UI package contains the customer-facing screens, visual state and navigation used by both the browser demonstration and the intended native application. Venue-themed content, table entry, menus, account forms and basket panels should not be reimplemented independently in WordPress and Android. This reduces styling drift and prevents one environment from receiving a bug fix that the other misses. The decision introduces a necessary abstraction: screens ask for services rather than directly invoking a demo API or native plugin.

Important source responsibilities

legacy/AppScreens.js carries the original high-level screen navigation and account/profile panels. legacy/VenueScreens.js provides venue and content views. legacy/TableOrdering.js implements table-first ordering and basket interactions. These remain legacy/global-style JavaScript and have not been completely converted to typed modular components. flows/DestinationRouter.js validates controlled venue/table links; flows/DeviceExperience.js manages connection, Retry and device experience operations at the abstract service level.

Presenter and phone behaviour

The WordPress presenter mounts these screens with demo services, so a QR scan or payment can be illustrated without a physical native bridge. The mobile runtime mounts them with native services that must either perform the real operation or fail safely. Browser test success does not mean the Android plugin has camera permission or that a server order was committed. Keep fictional data out of a native bundle, and do not introduce a runtime switch that could enable fake business success on a production phone.

Correct change sequence

When a new action is added to a shared screen, first specify what state it reads, which service capability it invokes, and what success, cancellation, timeout and error states mean. Update both runtime adapters deliberately. Keep venue/table identity in the action contract. For operations involving money or account information, require a server result before displaying a permanent success. Extend relevant browser and native contracts, then inspect screenshots at supported widths.

Known unfinished work

The older global screen modules still need typed extraction and accessibility review. The live native content providers are not complete; menu, event, offer and reward data remain different from presenter examples. Certain event/offer deep links reach a section without resolving the exact content record. Do not hide these differences in documentation. They explain why a screen may appear complete while its real service remains unavailable.

Verification

Run UI compile, browser journey tests across all five venues, table-first ordering, account negative paths and QR/offline cases. Check asset inclusion and exclusion: presenter chrome belongs to the demo, and mobile packages must include only approved native/shared artwork. Test the same meaningful actions on the real Android APK after native dependencies are resolved. Every change to this package must update the affected user-flow documentation, not merely a file hash.

Source files in this module

Maintenance and evidence

Check all affected file references and the matching human-readable user/architecture page when source changes. Run the module’s contract or governance checks; staging, payment and native hardware tests remain independent of source inventory coverage.