Mobile Platform as a Service:Introduction to the Native framework

Unified component library architecture

AntUI builds its unified control system from the bottom up, similar to building blocks.

The following table describes the architecture layers from bottom to top.

Architecture layer	Description
Foundation layer	Modularizes visual specifications as the base of AntUI, built from the smallest units of the visual specifications. Includes atomic resources, atomic controls, and Iconfont icons.
Common layer	The core AntUI module with the most frequently used controls. Includes common resources, basic controls, and a style manager. Built by combining foundation layer elements for common client scenarios.
Scene layer	Builds scenario-specific control collections for domains such as funds, merchants, and social networking. At super-app scale, many mPaaS services need custom controls built on top of the common layer.
Application layer	Provides platform-specific handling and H5 container support, resolving the tension between unification and platform customization. While atomic, composite, and scene elements form the AntUI foundation, the application layer exposes interfaces for Android, iOS, and H5 customization.

Foundation layer

The foundation layer modularizes visual specifications as the base of AntUI. It includes:

• Atomic resources

  Defines the atomic resources used by controls — colors, sizes, and spacing — to ensure uniqueness. Examples: colors (red, yellow, blue) and font sizes (12, 14, 16).

• Atomic controls

  Wraps native platform controls into a basic atomic control library.

• Iconfont icons

  Provides a library of common icons in Iconfont format.

Common layer

The common layer is the core AntUI module with the most frequently used controls:

• Common resources

  Maps atomic resources to usage scenarios, such as title color, content color, and link color.

• Basic controls

  Reproduces controls from visual design mockups on a one-to-one basis, with consistent naming and implementation across Android and iOS.

• Style manager

  Manages styles centrally through abstract definitions, enabling multi-skin switching per control. Uses incremental definitions so you only specify the styles your business requires.

Scene layer

The scene layer builds collections of controls with scenario-specific features, such as controls for funds, merchants, and social networking.

Application layer

The application layer handles platform-specific behavior and H5 container support, resolving the tension between unification and customization.

The Android and iOS platforms have different visual specifications. For example, AntUI handles actionsheets differently on each platform:

• On iOS, the actionsheet appears from the bottom.

• On Android, it is handled as a pop-up list in the center of the screen.

H5 content often requires different handling for elements such as pop-up dialog boxes and title bars. To give H5 content a native look and feel, AntUI defines a unified JSAPI for the H5 container. This JSAPI calls the appropriate platform controls, so H5 pages are handled differently on Android and iOS.

Design-development integration

AntUI integrates development and visual design workflows, reducing communication overhead and eliminating redundant control development and visual design work.

Designers create specifications, and developers interpret them to build controls. A comprehensive development guide simplifies this into a one-stop system.

• Unified naming creates a shared understanding between developers and designers. Naming conventions are detailed in Component specifications and principles.

• Design boards let designers understand existing controls and build page structures through drag-and-drop.

• The portal aggregates development documents, visual specifications, and downloadable demos for previewing control effects.

Component specifications and principles

• Naming style

  Same-type controls must share the same name on Android and iOS. Control names use the AU prefix. Custom control properties use camelCase.

  Important

  Some components have platform differences and may only need implementation on one platform.

• Matching basic controls with visual/interaction specifications

  • Controls not included in the specifications cannot be added to the standard controls.

  • Controls not in the specifications but used in multiple places belong in the candidate control collection.

  • A specification does not have to map to a single control — for example, the title bar specification.

• Usability

  • Unlike commonui, do not wrap system controls (such as APImageView and APTextView). Use native controls directly.

  • Names must be accurate and unambiguous.

  • Similar features should be consistent across different controls.

  • Follow user conventions.

• Extensibility

  • Avoid hard-coding control features. For example, the number of switchable tabs must support dynamic changes.

  • Controls such as dialog boxes and navigation bars must support external layout modification.

• Novelty

  You can use the latest platform features, such as Android's RecyclerView.