AK Mobile components
Business pages use components exported by apps/ak-mobile/components/ak-ui. AK UI isolates tokens, platform compatibility, touch sizing, event types, and the underlying uView or native implementation.
Pages see only the stable semantic `ak-*` contract, while underlying libraries and platform differences stay in the adapter layer. Compatibility fixes do not require every business page to change.
Choosing a component
- Start with the semantically closest
ak-*component; propose a new component only when the current layer cannot express the need. - Keep data fetching, authorization, and business state in the Feature Page rather than a presentational component.
- Contain platform differences in AK UI or a platform adapter; feature pages do not accumulate scattered platform checks.
- Define loading, empty, error, disabled, long-text, and bilingual behavior before visual polish.
- If a feature seems to require direct
up-*use, extend the AK UI adapter instead of creating a second public API in business pages.
Props, events, and slots
The Props/Event/Slot tables on component pages reflect current source. A new field updates implementation, example, bilingual reference, platform evidence, and validation together.
Visible strings are translated by the page through AkI18n and passed in. Touch targets are at least 44×44. Loading/disabled states prevent repeated submission. Business pages never use up-* directly. Platform availability still requires matching Android, iOS, and HarmonyOS build/device evidence.
Reading platform evidence
- Static check passed means types, imports, and constraints align; it is not a platform build.
- Platform build passed means that compiler completed; it is not install, launch, or interaction acceptance.
- Simulator passed covers only the named OS, version, and device model—not hardware.
- Physical device passed records platform, OS, device, build type, and screenshot/log evidence.
- HarmonyOS runtime claims require matching HBuilderX/DevEco output and real-device evidence.