mPaaS の統一コンポーネントライブラリ (AntUI) は、標準化されたビジュアル仕様に基づき、抽象的なビジュアルコンセプトを具体的なコントロールに変換します。これにより、コントロールを統合する際に、クライアント側で一貫したビジュアルスタイルが保証されます。
統一コンポーネントライブラリのアーキテクチャ
AntUI のアーキテクチャは、ビルディングブロックのようにボトムアップで構築され、統一されたコントロールシステムを形成します。
以下の表は、アーキテクチャの各レイヤーをボトムアップで説明したものです。
アーキテクチャレイヤー | 説明 |
このレイヤーはビジュアル仕様をモジュール化し、AntUI システムの基盤を形成します。アトミックリソース、アトミックコントロール、Iconfont アイコンが含まれます。基盤レイヤーは、ビジュアル仕様の最小単位から構築されます。 | |
これは AntUI のコアモジュールであり、最も頻繁に使用されるコントロールが含まれています。共通リソース、基本コントロール、スタイルマネージャーが含まれます。共通レイヤーは、基盤レイヤーの要素を組み合わせて構築されます。すべての一般的なクライアントシナリオで使用できます。 | |
このレイヤーは、資金、マーチャント、ソーシャルネットワーキング用のコントロールなど、シナリオ固有の機能を備えたコントロールのコレクションを構築します。mPaaS はスーパーアプリであるため、その規模から多くのサービスでカスタム処理が必要になります。シーンレイヤーは、これらのシナリオのために共通レイヤーの上にカスタムコントロールを構築します。 | |
このレイヤーは、プラットフォーム固有の処理と H5 コンテナーのサポートを提供します。統一とプラットフォームのカスタマイズとの間の競合を解決します。アトミック、複合、およびシーン要素が AntUI の基盤を形成しますが、実用的なアプリケーションは Android、iOS、および H5 のニーズを満たす必要があります。アプリケーションレイヤーは、これらの違いに対処するために、プラットフォーム固有のカスタマイズのためのインターフェイスを提供します。 |
基盤レイヤー
基盤レイヤーはビジュアル仕様をモジュール化し、AntUI システムの基盤を形成します。アトミックリソース、アトミックコントロール、Iconfont アイコンが含まれます。
アトミックリソース
コントロールが使用する色、サイズ、間隔などのアトミックリソースを定義し、その一意性を保証します。例として、赤、黄、青などの色や、12、14、16 などのフォントサイズが挙げられます。
アトミックコントロール
プラットフォームフレームワークのネイティブコントロールをラップして、アトミックコントロールの基本ライブラリを構築します。
Iconfont アイコン
一般的なシナリオのアイコンを収集し、使用可能なコントロールアイコンのライブラリとして Iconfont フォーマットで提供します。
共通レイヤー
共通レイヤーは AntUI のコアとなる統一モジュールです。最も頻繁に使用されるコントロールが含まれており、共通リソース、基本コントロール、スタイルマネージャーが含まれます。
共通リソース
タイトルの色、コンテンツの色、リンクの色など、使用シナリオに応じてアトミックリソースを再定義します。
基本コントロール
このレイヤーは、ビジュアルデザインのモックアップで定義されたコントロールを 1 対 1 で視覚的に再現します。Android と iOS プラットフォーム間で一貫した命名と実装を維持し、クライアント開発を簡素化します。
スタイルマネージャー
スタイルを抽象的に定義し、一元管理します。これにより、特定のコントロールを複数のスキン間で切り替えることができます。スタイルの抽象化は、増分定義を使用して実装されます。つまり、ビジネスで必要な要素のスタイルにのみ集中すればよいということです。
シーンレイヤー
シーンレイヤーは、資金、マーチャント、ソーシャルネットワーキング用のコントロールなど、シナリオ固有の機能を備えたコントロールのコレクションを構築します。
アプリケーションレイヤー
アプリケーションレイヤーは、プラットフォーム固有の処理や H5 コンテナーのサポートなどの機能を提供します。統一とプラットフォームのカスタマイズとの間の競合を解決します。
Android と iOS のプラットフォームでは、ビジュアル仕様が異なります。たとえば、AntUI は各プラットフォームでアクションシートを異なる方法で処理します。
iOS では、アクションシートは画面下部から表示されます。
Android では、画面中央のポップアップリストとして処理されます。
H5 コンテンツでは、ポップアップダイアログボックスやタイトルバーなどの要素に対して、しばしば異なる処理が必要になります。H5 コンテンツにネイティブなルックアンドフィールを保証するため、統一コンポーネントライブラリは H5 コンテナー用に統一された JavaScript Application Programming Interface (JSAPI) を定義しています。この API により、適切なプラットフォームコントロールを簡単に呼び出すことができます。これにより、H5 ページを Android と iOS で異なる方法で処理できます。
連携
デザイナーと開発者間のコミュニケーションコストを削減し、冗長なコントロール開発やビジュアルデザイン作業を避けるため、統一コンポーネントライブラリ (AntUI) は開発タスクとビジュアルデザインタスクを統合しています。
デザイナーが仕様を作成し、開発者はこれらの仕様を解釈してコントロールを作成します。完全な開発ガイドが実装を簡素化し、ワンストップのコントロールシステムを形成します。
統一された命名により、開発者とデザイナーの間で共通の理解が生まれます。命名規則の詳細については、本トピックの「コンポーネントの仕様と原則」をご参照ください。
デザインボードは、デザイナーが既存のコントロールを理解するのに役立ちます。要素をドラッグアンドドロップするだけで、ページの基本構造を構築できます。
ポータルは、開発ドキュメントとビジュアル仕様を集約します。また、デモのダウンロードも提供しているため、コントロールの視覚効果を直接確認できます。
コンポーネントの仕様と原則
命名スタイル
同じタイプのコントロールは、Android と iOS の両プラットフォームで同じ名前でなければなりません。コントロール名にはプレフィックスとして AU が付きます。すべてのカスタムコントロールプロパティはキャメルケースを使用します。
重要一部のコンポーネントにはプラットフォームによる差異がある場合があります。あるプラットフォームでは実装が必要でも、別のプラットフォームでは不要なコンポーネントもあります。
基本コントロールとビジュアル/インタラクション仕様のマッチング
仕様に含まれていないコントロールは、標準コントロールに追加できません。
仕様にはないが、すでに複数の場所で使用されているコントロールは、候補コントロールコレクションに配置する必要があります。
1 つの仕様が、必ずしも 1 つのコントロールとして実装されるとは限りません。たとえば、タイトルバーの仕様がこれに該当します。
ユーザビリティ
commonui とは異なり、システムコントロール (APImageView や APTextView など) の単純なラッパーは作成しないでください。システムコントロールが必要な場合は、ネイティブコントロールを使用してください。
名前は正確で、曖昧さがないものでなければなりません。
類似の機能は、異なるコントロール間で一貫している必要があります。
ユーザーの慣習に従ってください。
拡張性
コントロールの機能にハードコーディングを使用しないでください。たとえば、切り替え可能なタブ数の動的な変更をサポートします。
ダイアログボックスやナビゲーションバーなどの一部のコントロールは、外部からレイアウトを変更できるようにする必要があります。
新規性
Android の RecyclerView など、最新のプラットフォーム機能を使用できます。