v6 - POC - Button in every component

[jreij]

Description

POC exploring what it looks like when every component has a submit button by default, aligning the Android SDK with Web.

What changes for merchants

• Every component now renders a submit button by default, including the ones that previously had no UI at all.

• Merchants no longer have to call controller.submit() themselves to make those flows work. Previously a component without UI would sit there doing nothing unless the merchant wrote:

  if (!controller.requiresUserInteraction()) {
      controller.submit()
  }

  That is now opt-in: call it only if you actually want to skip the button and submit immediately.

• requiresUserInteraction() keeps its meaning — it tells you whether the shopper must interact before the component can be submitted, not whether the component has UI.

• Google Pay stays requiresUserInteraction() == true even though it is a button-only component; that is intended.

• The stored card component deliberately does not use the generic scaffolding. It manages its own UI and state, and its requiresUserInteraction() reflects the security code requirement policy, so both flows (with a CVC field and without) keep working.

Internal

All components now have aligned scaffolding — validator, reducer, state factory, view state producer — so a component without input fields is structurally the same as one with fields, it just has no content above the button.

Example app

Modified for the POC only: the advanced flow example auto-submits, while the sessions flow relies on the button. This is purely to exercise both paths side by side.

Not ready to merge

This is a POC. Before it can be merged tests need to be added and the code tidied up.

Checklist

• If applicable, make sure Breaking change label is added.
• Code is unit tested
• Changes are tested manually
• Aligned public API changes with other platforms (if applicable)
• Related issues are linked

[gemini-code-assist]

Code Review

This pull request refactors several payment components, including StoredBlikComponent and GenericPaymentComponent, to utilize generic state management classes (such as GenericComponentStateFactory, GenericComponentStateReducer, and GenericViewStateProducer) and introduces a reusable GenericContent composable. It also updates the example app view models to simplify submit button visibility and automatically trigger submission when user interaction is not required. The review feedback suggests defining GenericViewState as a data class to optimize Compose recompositions, utilizing existing helper methods in V6SessionsViewModel to avoid duplicating state update logic, and binding the non-null value of viewState.securityCode inside the let block in StoredCardContent to prevent smart-casting issues across lambda boundaries.

[github-actions]

✅ No public API changes