(57)【要約】本出願の実施形態は、共通のコンポーネントを使用してアプリケーションを初期化するための方法およびデバイスを提供する。そのような１つの方法は、事前に生成されたコンポーネントをコンポーネントライブラリ内に格納するステップと、アプリケーションの機能アイテムが始動させることを要求される場合に、アプリケーションに関連した情報および機能アイテムに関連した情報に従ってサーバから特性データを取得するステップと、その特性データに従ってコンポーネントライブラリ内の必要なコンポーネントを決定するステップと、それらの必要なコンポーネントを使用して機能アイテムを始動させるステップとを含む。この方法は、アプリケーションの実施効率を改善すること、およびリソースの浪費を低減することが可能である。
2018537783.tif 000002
【特許請求の範囲】
【請求項１】
事前に生成されたコンポーネントを使用してアプリケーションの機能アイテムを実施するための方法であって、
前記事前に生成されたコンポーネントをコンポーネントライブラリ内に格納するステップと、
前記アプリケーションの前記機能アイテムを始動させる要求に応答して、前記アプリケーションに関連した情報および前記アプリケーションの前記機能アイテムに関連した情報に基づいてサーバから特性データを取得するステップと、
前記特性データに基づいて、前記機能アイテムを始動させるための前記コンポーネントライブラリ内の必要なコンポーネントを決定するステップと、
前記必要なコンポーネントを使用して前記機能アイテムを始動させるステップと
を含む方法。
【請求項２】
前記機能アイテムが、ページのコンテンツを表示するために使用されるとき、前記特性データは、前記コンテンツに関連付けられているインターフェースデータ、および前記ページのレイアウトテンプレートデータを含み、前記レイアウトテンプレートデータは、前記必要なコンポーネントを決定するための前記必要なコンポーネントに関連した情報を含み、前記方法は、前記必要なコンポーネントとビューモデルとの間における関連付けを確立するステップをさらに含み、前記必要なコンポーネントを使用して前記機能アイテムを始動させる前記ステップは、
前記必要なコンポーネントに対応する初期ビューモデルを、前記必要なコンポーネント、および前記必要なコンポーネントと前記ビューモデルとの間における前記関連付けに基づいて決定するステップと、
前記レイアウトテンプレートデータおよび前記インターフェースデータを使用して前記初期ビューモデルを更新して、更新されたビューモデルを取得するステップと、
前記更新されたビューモデルを使用してページレンダリングプロセスを実行して、レンダリングされたページを生成するステップと、
前記レンダリングされたページを表示するステップと
を含む、請求項１に記載の方法。
【請求項３】
前記アプリケーションのページローダによって送信された要求メッセージを受信するステップであって、前記要求メッセージは、前記アプリケーションに関連した情報および前記機能アイテムに関連した情報を含み、前記アプリケーションに関連した前記情報および前記機能アイテムに関連した前記情報は、始動させられる前記アプリケーションの前記機能アイテムを決定するために使用される、ステップと、
前記アプリケーションに関連した情報および前記機能アイテムに関連した情報を取得するステップと
をさらに含み、
前記必要なコンポーネントと前記ビューモデルとの間における関連付けを確立する前記ステップは、データレイヤを使用して前記必要なコンポーネントと前記ビューモデルとの間における関連付けを確立するステップを含む、請求項２に記載の方法。
【請求項４】
前記初期レイアウトテンプレートデータ、および基本情報に従って前記ページの初期レンダリングプロセスを実行して、初期レンダリングを生成するステップと、
前記初期レンダリングを使用して前記ページを表示するステップと
をさらに含む、請求項３に記載の方法。
【請求項５】
前記必要なコンポーネントは、ＵＩコンポーネントを含み、前記コンポーネントライブラリおよび前記データレイヤは、クライアントデバイスに配置されており、前記クライアントデバイスは、前記アプリケーションに対応するサービスパケットを含む、請求項３に記載の方法。
【請求項６】
前記クライアントは、他のモジュールをさらに含み、前記他のモジュールは、異なるアプリケーションにとって利用可能であり、前記他のモジュールは、コアライブラリ、フロー管理モジュール、およびライフサイクル管理モジュールのうちの１つまたは複数を含む、請求項５に記載の方法。
【請求項７】
前記クライアントは、適合レイヤをさらに含み、前記適合レイヤは、異なるアプリケーションのための実施情報を含み、前記データレイヤは、前記実施情報に従ってレンダリングプロセスを実行する、請求項５に記載の方法。
【請求項８】
前記アプリケーションに関連した情報および前記機能アイテムに関連した情報に基づいて前記サーバから特性データを取得する前記ステップは、
要求メッセージを前記サーバの前記適合レイヤへ送信するステップであって、前記要求メッセージは、前記アプリケーションに関連した前記情報および前記機能アイテムに関連した前記情報を含む、ステップと、
前記サーバによって送信された特性データを受信するステップであって、前記特性データは、前記アプリケーションに関連した前記情報および前記機能アイテムに関連した前記情報に基づいて前記サーバによって取得される、ステップと
を含み、
前記サーバの前記適合レイヤは、異なるアプリケーションによって送信される要求メッセージを受信することができる、請求項１に記載の方法。
【請求項９】
共通のコンポーネントを使用してアプリケーションを実行するためのデバイスであって、
事前に生成されたコンポーネントをコンポーネントライブラリ内に格納するためのメモリと、
前記アプリケーションの機能アイテムを実行する要求に応答して、前記アプリケーションに関連した情報および前記機能アイテムに関連した情報に基づいてサーバから特性データを取得し、前記特性データに基づいて前記コンポーネントライブラリ内の前記機能アイテムのための必要なコンポーネントを決定し、ならびに前記必要なコンポーネントを使用して前記機能アイテムを始動させる、前記メモリに通信可能に結合されたプロセッサと
を含むデバイス。
【請求項１０】
前記プロセッサは、
前記必要なコンポーネントに対応する初期ビューモデルを、前記必要なコンポーネント、および前記必要なコンポーネントと前記ビューモデルとの間における関連付けに基づいて決定し、
レイアウトテンプレートデータおよびインターフェースデータに従って前記初期ビューモデルを更新して、更新されたビューモデルを生成し、
前記更新されたビューモデルを使用してページレンダリングプロセスを実行して、レンダリングされたページを生成し、
前記レンダリングされたページを表示し、
前記機能アイテムが、ページコンテンツを含む場合には、前記特性データは、前記ページコンテンツに関連付けられている前記インターフェースデータ、および前記表示されるページの前記レイアウトテンプレートデータを含み、前記レイアウトテンプレートデータは、前記必要なコンポーネントを決定するためのデータを含む、請求項９に記載のデバイス。
【請求項１１】
アプリケーションを処理する方法をコンピュータシステムに実行させるためのコンピュータ可読プログラムコードが内部で具体化されているコンピュータ使用可能媒体であって、前記方法は、
事前に生成されたコンポーネントをコンポーネントライブラリ内に格納するステップと、
前記アプリケーションの機能アイテムを始動させる要求に応答して、前記アプリケーションに関連した情報および前記アプリケーションの前記機能アイテムに関連した情報に基づいてサーバから特性データを取得するステップと、
前記特性データに基づいて、前記機能アイテムを始動させるための前記コンポーネントライブラリ内の必要なコンポーネントを決定するステップと、
前記必要なコンポーネントを使用して前記機能アイテムを始動させるステップと
を含む、コンピュータ使用可能媒体。
【請求項１２】
前記機能アイテムが、ページのコンテンツを表示するために使用されるとき、前記特性データは、前記コンテンツに関連付けられているインターフェースデータ、および前記ページのレイアウトテンプレートデータを含み、前記レイアウトテンプレートデータは、前記必要なコンポーネントを決定するために使用される前記必要なコンポーネントに関連した情報を含み、前記方法は、
前記必要なコンポーネントとビューモデルとの間における関連付けを確立するステップをさらに含み、
前記必要なコンポーネントを使用して前記機能アイテムを始動させる前記ステップは、
前記必要なコンポーネントに対応する初期ビューモデルを、前記必要なコンポーネント、および前記必要なコンポーネントと前記ビューモデルとの間における前記関連付けに基づいて決定するステップと、
前記レイアウトテンプレートデータおよび前記インターフェースデータに従って前記初期ビューモデルを更新して、更新されたビューモデルを取得するステップと、
前記更新されたビューモデルを使用してページレンダリングプロセスを実行して、レンダリングされたページを生成するステップと、
前記レンダリングされたページを表示するステップと
を含む、請求項１１に記載のコンピュータ使用可能媒体。
【請求項１３】
前記アプリケーションのページローダによって送信された要求メッセージを受信するステップであって、前記要求メッセージは、始動させられる前記アプリケーションの前記機能アイテムを決定するために使用される、前記アプリケーションに関連した情報および前記機能アイテムに関連した情報を含む、ステップをさらに含む、請求項１２に記載の方法。
【請求項１４】
前記必要なコンポーネントは、ＵＩコンポーネントを含み、前記コンポーネントライブラリおよび前記データレイヤは、クライアントデバイスに配置されており、前記クライアントデバイスは、前記アプリケーションに対応するサービスパケットを含む、請求項１３に記載の方法。
【請求項１５】
前記クライアントは、他のモジュールをさらに含み、前記他のモジュールは、異なるアプリケーションにとって利用可能であり、前記他のモジュールは、コアライブラリ、フロー管理モジュール、およびライフサイクル管理モジュールのうちの１つまたは複数を含む、請求項１４に記載の方法。
【請求項１６】
前記クライアントは、適合レイヤをさらに含み、前記適合レイヤは、異なるアプリケーションのための実施情報を含み、前記データレイヤは、前記実施情報を使用してレンダリングプロセスを実行する請求項１４に記載の方法。
【請求項１７】
前記アプリケーションに関連した情報および前記機能アイテムに関連した情報に基づいて前記サーバから特性データを取得する前記ステップは、
要求メッセージを前記サーバの前記適合レイヤへ送信するステップであって、前記要求メッセージは、前記アプリケーションに関連した情報および前記機能アイテムに関連した情報を含む、ステップと、
前記サーバによって送信された特性データを受信するステップであって、前記特性データは、前記アプリケーションに関連した前記情報および前記機能アイテムに関連した前記情報に基づいて前記サーバによって取得される、ステップと
を含む請求項１１に記載の方法。
【請求項１８】
前記サーバの前記適合レイヤは、異なるアプリケーションによって送信される要求メッセージを受信することができる請求項１７に記載の方法。
【請求項１９】
前記サーバの前記適合レイヤは、異なるアプリケーションによって並列に送信される要求メッセージを受信することができ、前記サーバは、前記要求メッセージに並列に応答することができる請求項１８に記載の方法。
【請求項２０】
前記アプリケーションに関連した情報および前記機能アイテムに関連した情報を取得するステップをさらに含み、前記コンポーネントと前記ビューモデルとの間における関連付けを確立する前記ステップは、データレイヤを使用して前記コンポーネントと前記ビューモデルとの間における関連付けを確立するステップを含む請求項１３に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、ソフトウェアアプリケーションの分野に関連しており、詳細には、事前に生成されたコンポーネントを使用してソフトウェアアプリケーションを開発および／または実行するための方法およびデバイスに関連している。
【背景技術】
【０００２】
関連出願の相互参照
本出願は、２０１５年１２月２日に出願された中国特許出願第２０１５１０８７３９６０．３号に対する優先権を主張するものであり、中国特許出願第２０１５１０８７３９６０．３号は、その全体が参照によって本明細書に組み込まれている。
【０００３】
最近では、多数のアプリケーション（アプリ）が開発されており、同じ開発者が、さまざまな異なるアプリを提供する場合がある。それらのアプリが異なる場合でさえ、それらのアプリは、特にいくつかのアプリが同じ開発者によって提供される場合には、同様の機能を有することがある。しかしながら、それぞれのアプリが別々に開発される場合には、効率が大幅に低減され、開発リソースが浪費される。必要とされているものは、開発コストを低減するために、および効率を改善するために、共通のコンポーネントを使用することができる処理技術である。
【発明の概要】
【０００４】
本出願の１つの目的は、アプリケーションの実施効率を改善し、消費されるリソースの量を低減する、アプリケーションを開発するための方法を提供することである。本出願の別の目的は、共通のアプリケーションコンポーネントを使用するためのアプリケーション処理デバイスを提供することである。
【０００５】
一実施形態によれば、事前に生成されたコンポーネントを使用してアプリケーションの機能アイテム（function item）を実施するための方法が開示される。この方法は、事前に生成されたコンポーネントをコンポーネントライブラリ内に格納するステップと、アプリケーションの機能アイテムを始動させたいという要求に応答して、アプリケーションに関連した情報およびそのアプリケーションの機能アイテムに関連した情報に基づいてサーバから特性データを取得するステップと、その特性データに基づいて、機能アイテムを始動させるためのコンポーネントライブラリ内の必要なコンポーネントを決定するステップと、その必要なコンポーネントを使用して機能アイテムを始動させるステップとを含む。
【０００６】
別の実施形態によれば、共通のコンポーネントを使用してアプリケーションを実行するためのデバイスが開示される。このデバイスは、事前に生成されたコンポーネントをコンポーネントライブラリ内に格納するためのメモリと、アプリケーションの機能アイテムを実行したいという要求に応答して、アプリケーションに関連した情報および機能アイテムに関連した情報に基づいてサーバから特性データを取得するステップ、その特性データに基づいてコンポーネントライブラリ内の機能アイテムのための必要なコンポーネントを決定するステップ、ならびにその必要なコンポーネントを使用して機能アイテムを初期化するステップを行うためのプロセッサとを含む。
【０００７】
本出願のさらなる態様および利点は、一部は以降の説明において与えられることになり、一部は以降の説明から明らかになり、または本出願の実践によって理解されることになる。
【図面の簡単な説明】
【０００８】
本出願の上述のおよび／またはさらなる態様および利点は、図面と併せた実施形態についての以降の説明から明らかになり、容易に理解されることになる。
【図１】本出願の実施形態による、事前に生成されたコンポーネントを使用した例示的なアプリケーション処理方法の流れ図である。
【図２】本出願の実施形態による例示的なアプリケーション開発システムの図である。
【図３】本出願の実施形態による、事前に生成されたコンポーネントを使用した例示的な処理アプリケーション処理方法の流れ図である。
【図４】本出願の実施形態による例示的なアプリケーション処理デバイスの図である。
【図５】本出願の実施形態による例示的なアプリケーション処理デバイスの図である。
【発明を実施するための形態】
【０００９】
本出願の実施形態が詳細に記述され、それらの実施形態の例が図面において示されており、それらの図面においては、本明細書の全体を通じて同じまたは同様の参照番号が、同じまたは同様のモジュールまたは同じまたは同様の機能を有するモジュールを示している。図面を参照しながら以降で記述されている実施形態は、例示的なものであり、本出願を限定するものとして解釈されることではなく、本出願を説明することを目的としたものにすぎない。それどころか、本出願の実施形態は、添付の特許請求の範囲の趣旨および範疇内に収まるすべての変更、修正、および均等物を含む。
【００１０】
図１は、本出願の実施形態による、共通のコンポーネントを使用してアプリケーションを開発するための例示的な処理方法の流れ図である。
【００１１】
ステップ１１において、事前に生成されたコンポーネントが、コンポーネントライブラリ内に格納される。
【００１２】
アプリケーションシステムが、クライアントプログラム（アプリ）およびサーバプログラムを含む。クライアントプログラムは、サービスパケット、コンポーネントライブラリ、コアライブラリ、データレイヤ、適合レイヤ、およびアプリケーション環境を含むことができる。
【００１３】
サービスパケットは、アプリのサービス特性に基づいてアプリによって実行される論理処理プログラムを含むアプリのプライベートパッケージである。異なるアプリが、異なるサービス特性を伴う異なるサービスパケットを有することができる。異なるサービスパケットを使用することによって、同じコンポーネントが、異なるスタイルおよびレイアウトで表示されることが可能である。
【００１４】
コンポーネントライブラリ、コアライブラリ、およびデータレイヤは、異なるアプリによって共通して使用される。コンポーネントライブラリは、個々のアプリにおいて表示される汎用コンポーネントを含む。コアライブラリは、ベースライブラリ、たとえば、イベントセンター、セマティックライブラリ、テンプレートキャッシュなどを含む。データレイヤは、インターフェースデータを含むことができ、データ通信のために使用される。図２においては示されていないが、異なるアプリにとって共通して利用可能なモジュールは、フロー管理モジュールおよびライフサイクル管理モジュールなどの他のモジュールを含むこともできる。
【００１５】
適合レイヤは、コード、たとえば、コンポーネントライブラリ、コアライブラリなどが個々のアプリ環境において成功裏に稼働できることを確実にする。適合レイヤの主要な機能は、サービスレイヤ（たとえば、サービスパケット、コンポーネントライブラリ、コアライブラリ、およびデータレイヤなど）と、アプリレイヤ（たとえば、アプリケーション環境）との間にブリッジを構築することであり、それによってコンポーネントライブラリおよびコアライブラリは、元のアプリの設計および特性を損なうことなく、異なるアプリのアプリケーション環境において成功裏に稼働することができる。適合レイヤは一般に、サービスレイヤの初期化中に依存関係登録を使用して、プロトコルを異なるアプリの特定の実施態様と結び付ける。サービスレイヤは、適合レイヤによって定義されているインターフェースを呼び出すことによって、アプリの特定の実施態様を間接的に使用する。
【００１６】
アプリケーション環境は、１つまたは複数のアプリを含み、それらの複数のアプリは、同じまたは異なるモバイル端末に、たとえば、異なるアプリが異なるネットワークポート／アドレスおよびユーザ行動検知を有する状態で配置されることが可能である。
【００１７】
サーバは、データをクライアントに提供するために使用される。異なるアプリが、均一のインターフェースを使用してサーバからデータを取得するために、サーバは、適合レイヤを提供される。サーバの適合レイヤは、アプリ要求に応答し、アプリに対応するデータを返す。サーバのデータは、静的なデータ（たとえば、変化しないデータ）、および動的なデータ（たとえば、状況に応じて変化するデータ）へと分類されることが可能である。
【００１８】
コンポーネントがユーザインターフェース（ＵＩ）コンポーネントである場合には、そのコンポーネントは、クライアントのコンポーネントライブラリ内に格納されることが可能である。たとえば、共通のコンポーネントのキー値がＡに設定される場合には、対応するコンポーネント実装クラスがＡに関して設定されることが可能である。共通のコンポーネントのコンポーネント実装クラスがＢによって表される場合には、キー値Ａの具体的なコンテンツ、およびコンポーネント実装クラスＢの具体的なコンテンツがコンポーネントライブラリ内に格納されることが可能であり、キー値Ａとコンポーネント実装クラスＢとの間における関連付けが確立される。特に、キー値Ａとコンポーネント実装クラスＢとの間における関連付けは、コンポーネントライブラリ内のコンポーネントマッピング構成テーブル内に記録されることが可能である。
【００１９】
個々のアプリの別々の開発とは異なり、共通のコンポーネントＡが、異なるアプリによって使用されることが可能であり、したがって反復的な開発およびリソースの浪費が回避される。
【００２０】
ステップ１２において、アプリケーションの機能アイテムが始動させられることになる場合に、アプリケーションに関連した情報および機能アイテムに関連した情報に従って、サーバから特性データが取得される。
【００２１】
特性データは、静的なデータおよび／または動的なデータを含むことができ、異なるアプリが、異なる特性データを有することができる。
【００２２】
特性データは、異なる機能アイテムごとに異なり得る。たとえば、ページコンテンツが表示されることになる場合には、特性データは、表示されることになるページコンテンツに関連付けられているインターフェースデータ、およびページ提示のレイアウトテンプレートデータを含むことができる。表示されることになるページコンテンツが商品詳細である場合には、インターフェースデータは、たとえば、商品画像、商品タイトル、商品価格、商品ロケーション等などの商品詳細に関連した情報を含む。レイアウトテンプレートデータは、たとえば、どのコンポーネントが使用されるべきか、およびコンポーネントの提示順序を含めて、ページ提示のレイアウトについて記述するために使用される。
【００２３】
いくつかの実施形態によれば、アプリケーションの情報および機能アイテムの情報に従ってサーバから特性データを取得するステップは、要求メッセージをサーバの適合レイヤへ送信するステップであって、その要求メッセージは、アプリケーションの情報および機能アイテムの情報を含む、ステップと、サーバによって送信された特性データを受信するステップであって、その特性データは、アプリケーションの情報および機能アイテムの情報に従ってサーバによって取得される、ステップとを含み、サーバの適合レイヤは、異なるアプリケーションによって送信される要求メッセージを受信することができる。
【００２４】
サーバは適合レイヤを提供され、それによって異なるアプリが、クライアントのデータレイヤを通じてサーバの統一された適合レイヤへ要求メッセージを送信することができる。アプリケーションデータ、機能アイテムデータ、および特性データの間における関連付けが、クライアントにおいて事前に構成されて、アプリケーションデータおよび機能アイテムデータに基づいて、対応する特性データを取得することが可能である。アプリケーションに関連した情報は、たとえば、アプリケーションの名前およびバージョン番号を含むことができる。商品詳細ページに関しては、機能アイテムデータは、たとえば、表示されることになる商品のＩＤであることが可能である。
【００２５】
ステップ１３において、必要なコンポーネントが、特性データに従ってコンポーネントライブラリ内で決定される。
【００２６】
たとえば、特性データは、必要なコンポーネントを識別および決定するために使用される必要なコンポーネントに関する情報を含むことができる。
【００２７】
ステップ１４において、必要なコンポーネントを使用して機能アイテムが始動させられる。
【００２８】
必要なコンポーネントを決定した後に、コンポーネントライブラリ内に格納されている特定のコンポーネント実装クラスが使用されて、コンポーネントの機能を実施することが可能である。複数のコンポーネントが使用される必要がある場合には、必要なコンポーネントの機能が組み合わされて、アプリケーションの機能アイテムを始動させ、または実行する。
【００２９】
コンポーネントをコンポーネントライブラリ内に格納することによって、異なるアプリケーションによって使用される同じコンポーネントが、一度作成されることが可能であり、それぞれのアプリケーションごとに別々に開発される必要はない。したがって、アプリケーションの実施効率が改善されることが可能であり、リソースの浪費が低減されることが可能である。
【００３０】
図３は、本出願の実施形態による、事前に生成されたコンポーネントを使用してアプリケーションを処理するための例示的な方法の流れ図である。始動させられることになるアプリケーションの機能アイテムは、たとえば、表示されるアプリケーション内に商品詳細ページを含めることができる。
【００３１】
ステップ３１において、事前に生成されたコンポーネントが、コンポーネントライブラリ内に格納され、それらのコンポーネントは、異なるアプリケーションによって使用されることが可能である。
【００３２】
たとえば、事前に生成されたコンポーネントのキー値がＡであり、そのコンポーネントの実装クラスがＢである場合には、キー値Ａおよびコンポーネント実装クラスＢが、コンポーネントライブラリ内に格納されることが可能であり、キー値Ａとコンポーネント実装クラスＢとの間における関連付けが確立されることが可能である。
【００３３】
ステップ３２において、コンポーネントとビューモデルとの間における関連付けが確立される。
【００３４】
ビューモデルは、グラフィカルレンダリングのために使用され、ＵＩのグラフィカルレンダリングコンポーネントによって必要とされる情報を含む。
【００３５】
特に、コンポーネントとビューモデルとの間における関連付けがデータレイヤにおいて確立されることが可能であり、たとえば、キー値ＡがビューモデルＣに対応することが可能である。
【００３６】
ステップ３３において、データレイヤは、アプリケーションのページローダによって送信された要求メッセージを受信し、その要求メッセージは、アプリケーションに関連した情報、および商品ＩＤを含む。
【００３７】
アプリケーションに関連した情報は、たとえば、アプリケーションの名前およびバージョン番号を含むことができる。
【００３８】
商品ＩＤは、詳細ページ内に表示されることになる商品を識別する。
【００３９】
ステップ３４において、要求メッセージが、サーバの適合レイヤへ送信され、その要求メッセージは、アプリケーションに関連した情報、および商品ＩＤを含む。
【００４０】
ページローダによって送信された要求メッセージがデータレイヤによって受信された際に、始動させられることになるアプリケーションの商品詳細ページが決定されることが可能であり、その要求メッセージは、特性データを取得するためにサーバの適合レイヤへ送信される。
【００４１】
ステップ３５ａにおいて、インターフェースデータおよびレイアウトテンプレートデータがサーバから受信され、そのインターフェースデータおよびレイアウトテンプレートデータは、アプリケーションに関連した情報、および商品ＩＤに従ってサーバによって取得される。
【００４２】
サーバは、商品ＩＤとインターフェースデータとを互いに関連付けて事前に格納することができ、それによって商品ＩＤに基づいて、対応するインターフェースデータが取得されることが可能である。インターフェースデータは、商品タイトル、価格、画像等などの商品詳細に関連した情報を含むことができる。
【００４３】
加えて、サーバは、アプリケーションに関連した情報とレイアウトテンプレートデータとを互いに関連付けて事前に格納することもでき、それによってアプリケーションの情報に基づいて、対応するレイアウトテンプレートデータが取得されることが可能である。
【００４４】
サーバは、事前に格納されているデータ内のインターフェースデータおよびレイアウトテンプレートデータを取得した後に、そのインターフェースデータおよびレイアウトテンプレートデータをクライアントのデータレイヤへ送信することができる。
【００４５】
ステップ３６において、必要なコンポーネントが、クライアントによってレイアウトテンプレートデータに従って決定される。
【００４６】
たとえば、レイアウトテンプレートデータは、どのコンポーネントが使用される必要があるか、およびコンポーネントの配列順序など、必要なコンポーネントに関連した情報を含むことができ、それによって、必要なコンポーネントが決定されることが可能である。
【００４７】
ステップ３７において、初期ビューモデルが、必要なコンポーネントに関して、必要なコンポーネント、およびそのコンポーネントとビューモデルとの間における関連付けに基づいて決定される。
【００４８】
たとえば、使用されることが必要とされるコンポーネントのキー値がＡである場合には、事前に確立されている関連付けにおいてＡに対応しているビューモデルはＣであるので、初期ビューモデルはＣであるということが決定されることが可能である。
【００４９】
ステップ３８において、レイアウトテンプレートデータおよびインターフェースデータに従って初期ビューモデルが更新されて、更新されたビューモデルを入手する。
【００５０】
初期ビューモデルにおける特定の数値がヌルである場合があり、レイアウトテンプレートデータおよびインターフェースデータによる処理の後に、特定の数値が、たとえば、商品価格、商品タイトル、および／または商品画像などを使用して設定されて、更新されたビューモデルを入手することが可能である。
【００５１】
ステップ３９において、更新されたビューモデルを使用してページレンダリングプロセスが実行されて、レンダリングされたページを表示する。
【００５２】
更新されたビューモデルは、ページをレンダリングするために必要とされる情報を含み、商品詳細ページの具体的なコンテンツが入手されて、更新されたビューモデルをレンダリングすることによって表示されることが可能である。
【００５３】
いくつかの実施形態によれば、ネットワーク環境が比較的貧弱であり、それによって、インターフェースデータおよびレイアウトテンプレートデータが取得されることが不可能である場合には、基本情報をユーザが閲覧することを容易にするために、ページのレンダリングは、第１のレンダリングおよび第２のレンダリングに基づくこと、または第１のレンダリングおよび第２のレンダリングから選択されることが可能である。インターフェースデータおよびレイアウトテンプレートデータに基づく更新されたビューモデル、およびその更新されたビューモデルに基づくレンダリングが、第２のレンダリングである。第１のレンダリングは、初期データに従って実行されることが可能である。
【００５４】
下記のステップは、任意選択であり、ステップ３４とステップ３５ａとの間において実行されることが可能である。
【００５５】
ステップ３５ｂにおいて、初期レイアウトテンプレートデータおよび基本情報を使用してページに関して初期レンダリングプロセスが実行され、初期レンダリングを使用してページが表示される。
【００５６】
初期レイアウトテンプレートデータおよび基本情報は、事前に構成されることが可能であり、それによってユーザは、表示される商品のタイトルおよび価格等などの基本的なページコンテンツを見ることができる。
【００５７】
アプリにわたって使用されるモジュール式ソリューションが、異なるアプリケーションからの共通のコンポーネントを通じて実現されることが可能である。単一の開発プロセスに伴って、サービスが、モバイル端末上にインストールされている異なるアプリに容易に適用されることが可能である。これは、開発コストを大幅に低減し、サービスがオンラインで迅速かつ並列にもたらされることが可能である。
【００５８】
図４は、本出願の実施形態による例示的な処理デバイスの図である。デバイス４０は、メモリ４１、取得モジュール４２、決定モジュール４３、および初期化モジュール４４を含む。これらのモジュールは、別々のコンポーネントとして実装されること、またはプロセッサ４８内に含まれることが可能である。プロセッサ４８は、メモリ４１に通信可能に結合されている。メモリ４１は、プロセッサ４８によって処理されたデータを格納するために使用されることが可能であり、たとえば、ＲＡＭ、ＲＯＭ、フラッシュメモリ、または磁気テープもしくはディスクドライブを含むことができる。いくつかの実施形態によれば、メモリ４１は、コンポーネントライブラリを格納するために使用され、プロセッサ４８は、取得モジュール４２、決定モジュール４３、および初期化モジュール４４の機能を実行する。
【００５９】
メモリ４１は、事前に生成されたコンポーネントをコンポーネントライブラリ内に格納するために使用されることが可能であり、そのコンポーネントは、異なるアプリケーションによって使用されることが可能である。
【００６０】
図２を参照すると、アプリケーションシステムは、クライアントプログラム（アプリ）２０５およびサーバプログラム２４５を含むことができ、クライアントプログラムは、サービスパケット２１０、コンポーネントライブラリ２１５、コアライブラリ２２０、データレイヤ２３０、適合レイヤ２３５、およびアプリケーション環境２４０を含むことができる。
【００６１】
サービスパケット２１０は、アプリのプライベートパッケージであり、アプリのサービス特性に対応するアプリの論理処理プログラムを含むことができる。異なるアプリが、異なるサービス特性を伴う異なるサービスパケットを有することができる。異なるサービスパケットを使用することによって、同じコンポーネントが、異なるスタイルおよびレイアウトで表示されることが可能である。
【００６２】
コンポーネントライブラリ２１５、コアライブラリ２２０、およびデータレイヤ２３０は、異なるアプリにとって共通して利用可能である。コンポーネントライブラリ２１５は、個々のアプリにおいて表示される汎用コンポーネントを含む。コアライブラリ２２０は、ベースライブラリ、たとえば、イベントセンター、セマティックライブラリ、テンプレートキャッシュなどを含む。データレイヤ２３０は、インターフェースデータの定義を含み、データ通信のために使用される。図２においては示されていないが、異なるアプリにとって利用可能なモジュールは、フロー管理モジュールおよびライフサイクル管理モジュールなどの他のモジュールを含むこともできる。
【００６３】
適合レイヤ２３５は、コンポーネントライブラリ２１１５、コアライブラリ２２０などからのコードが個々のアプリ環境において成功裏に稼働できることを確実にする。適合レイヤ２３５の主要な機能は、サービスレイヤ（たとえば、サービスパケット、コンポーネントライブラリ、コアライブラリ、データレイヤなど）と、アプリレイヤ（たとえば、アプリケーション環境）との間にブリッジを構築することであり、それによってコンポーネントライブラリおよびコアライブラリは、元のアプリの設計および特性を損なうことなく、異なるアプリのアプリケーション環境において成功裏に稼働することができる。適合レイヤ２３５は、サービスレイヤの初期化中に依存関係登録を使用して、プロトコルを異なるアプリの特定の実施態様と結び付ける。サービスレイヤは、適合レイヤによって定義されているインターフェースを呼び出すことによって、アプリの特定の実施態様を間接的に使用する。
【００６４】
アプリケーション環境２４０は、１つまたは複数のアプリを含み、それらのアプリは、同じまたは別々のモバイル端末に、異なるアプリが異なるネットワークポート／アドレスおよびユーザ行動検知などを有する状態で配置されることが可能である。
【００６５】
サーバ２４５は、データをクライアントに提供するために使用される。サーバの適合レイヤ２６０は、さまざまなアプリに関して均一のインターフェースを使用してサーバからデータが取得されることを可能にする。サーバの適合レイヤ２８０は、個々のアプリの要求に応答することができ、個々のアプリに対応するデータを返す。サーバのデータは、静的なデータ２５０および動的なデータ２５５へと分類されることが可能である。動的なデータは、たとえば、市場データ２８０、アプリデータ２６５、割引データ２０７、および在庫データ２７５を含むことができる。
【００６６】
コンポーネントがユーザインターフェース（ＵＩ）コンポーネントである場合には、そのコンポーネントは、クライアントのコンポーネントライブラリ２１５内に格納されることが可能である。
【００６７】
たとえば、共通のコンポーネントのキー値がＡに設定される場合には、対応するコンポーネント実装クラスがＡに関して設定されることが可能である。コンポーネント実装クラスがＢによって表される場合には、キー値Ａの具体的なコンテンツ、およびコンポーネント実装クラスＢの具体的なコンテンツがコンポーネントライブラリ内に格納されることが可能であり、キー値Ａとコンポーネント実装クラスＢとの間における関連付けが確立される。特に、キー値Ａとコンポーネント実装クラスＢとの間における関連付けは、コンポーネントライブラリ内のコンポーネントマッピング構成テーブル内に記録されることが可能である。
【００６８】
個別のコンポーネントを使用した個々のアプリの開発とは異なり、共通のコンポーネントＡが、異なるアプリによって使用されることが可能であり、反復的な開発およびリソースの浪費が回避されることが可能である。
【００６９】
取得モジュール４２は、アプリケーションの機能アイテムがアクティブ化されることになる場合に、アプリケーションに関連した情報および機能アイテムの情報に従って、サーバから特性データを取得する。特性データは、静的なデータおよび／または動的なデータを含むことができ、異なるアプリが、異なる特性データを有することができる。
【００７０】
特性データは、始動させられることになる機能アイテムに依存する。たとえば、ページコンテンツが表示されることになる場合には、特性データは、表示されることになるページコンテンツに関連付けられているインターフェースデータ、およびページに関するレイアウトテンプレートデータを含むことができる。表示されることになるページコンテンツが商品詳細であるケースにおいては、インターフェースデータは、たとえば、商品画像、商品タイトル、商品価格、商品ロケーション等などの商品詳細に関連した情報を含むことができる。レイアウトテンプレートデータは、表示されるページのレイアウト、たとえば、どのコンポーネントが使用される必要があるか、および必要なコンポーネントの提示順序を定義するために使用される。
【００７１】
いくつかの実施形態によれば、取得モジュール４２は、アプリケーションに関連した情報および機能アイテムに関連した情報に基づいてサーバから特性データを取得するステップを行うために使用される。取得モジュールは、要求メッセージをサーバの適合レイヤへ送信するステップであって、その要求メッセージは、アプリケーションに関連した情報および機能アイテムの情報を含む、ステップと、サーバによって送信された特性データを受信するステップであって、その特性データは、アプリケーションに関連した情報および機能アイテムの情報に従ってサーバによって取得された、ステップとを行うことができる。サーバの適合レイヤは、異なるアプリケーションによって送信される要求メッセージを受信することができる。
【００７２】
たとえば、図２を参照すると、サーバは適合レイヤを提供され、異なるアプリが、クライアントのデータレイヤを使用してサーバの統一された適合レイヤへ要求メッセージを送信することができる。アプリケーションに関連した情報、機能アイテムに関連した情報、および特性データの間における関連付けが、クライアントにおいて事前に構成されて、アプリケーションに関連した情報および機能アイテムに関連した情報を使用して、対応する特性データを取得することが可能である。アプリケーションに関連した情報は、たとえば、アプリケーションの名前およびバージョン番号を含むことができ、商品詳細ページが表示される場合には、機能アイテムに関連した情報は、たとえば、表示されることになる商品のＩＤを含むことができる。
【００７３】
決定モジュール４３は、特性データに基づいてコンポーネントライブラリ内の必要なコンポーネントを決定するステップを行うために使用される。たとえば、特性データは、どのコンポーネントが必要であるかを決定するために使用される必要なコンポーネントに関連した情報を含むことができる。
【００７４】
始動モジュール４４は、必要なコンポーネントに基づいて機能アイテムを始動させ、初期化し、および／または実行するために使用される。
【００７５】
必要なコンポーネントを決定した後に、コンポーネントライブラリ内に格納されている特定のコンポーネント実装クラスが使用されて、コンポーネントの機能を実施することおよび／または可能にすることが可能であり、複数のコンポーネントが使用される必要がある場合には、複数の必要なコンポーネントの機能が組み合わされて、アプリケーションの機能アイテムを始動させることが可能である。
【００７６】
コンポーネントをコンポーネントライブラリ内に格納することによって、それらのコンポーネントは、異なるアプリケーションによって使用されることが可能であり、それぞれのアプリケーションごとに別々のコンポーネントを確立する代わりに、必要なコンポーネントが一度作成／確立されることが可能である。したがって、アプリケーションの効率が改善されることが可能であり、リソースの浪費が低減されることが可能である。
【００７７】
いくつかの実施形態によれば、機能アイテムがページコンテンツを表示する場合には、特性データは、表示されることになるページコンテンツに関連付けられているインターフェースデータ、および表示されるページのレイアウトテンプレートデータを含むことができ、そのレイアウトテンプレートデータは、どのコンポーネントが必要であるかを決定するための必要なコンポーネントに関連した情報を含む。
【００７８】
図５を参照すると、デバイス４０は、コンポーネントとビューモデルとの間における関連付けを確立するステップを行うための確立モジュール４５を含み、初期化モジュール４４は、必要なコンポーネントに対応する初期ビューモデルを、必要なコンポーネント、およびそれらのコンポーネントとビューモデルとの間における関連付けに基づいて決定するステップを行うために特に使用される。初期化モジュール４４はさらに、レイアウトテンプレートデータおよびインターフェースデータに従って初期ビューモデルを更新して、更新されたビューモデルを取得するステップと、その更新されたビューモデルを使用してページレンダリングプロセスを実行するステップと、レンダリングされたページを表示するステップとを行うために使用される。
【００７９】
いくつかの実施形態によれば、確立モジュール４５は、コンポーネントとビューモデルとの間における関連付けをデータレイヤにおいて確立するステップを行うために特に使用され、ビューモデルは、グラフィカルレンダリングのために使用され、ＵＩのグラフィカルレンダリングコンポーネントによって使用される情報を含む。
【００８０】
特に、コンポーネントとビューモデルとの間における関連付けが、データレイヤを使用して確立されることが可能である。たとえば、キー値ＡがビューモデルＣに対応することが可能である。
【００８１】
依然として図５を参照すると、デバイス４０は、アプリケーションのページローダによって送信された要求メッセージを受信するステップであって、その要求メッセージは、始動させられることになるアプリケーションの機能アイテムを決定するために使用される、アプリケーションに関連した情報および機能アイテムに関連した情報を含む、ステップと、アプリケーションに関連した情報および機能アイテムに関連した情報を取得するステップとを行うための受信モジュール４６を含む。
【００８２】
アプリケーションに関連した情報は、たとえば、アプリケーションの名前およびバージョン番号を含むことができる。
【００８３】
機能アイテムに関連した情報は、表示されることになる詳細ページの商品のＩＤを含むことができる。
【００８４】
ページローダによって送信された要求メッセージがデータレイヤによって受信された際に、始動させられることになるアプリケーションの商品詳細ページが決定されることが可能であり、その要求メッセージは、特性データを取得するためにサーバの適合レイヤへ送信される。
【００８５】
いくつかの実施形態によれば、図５を参照すると、デバイス４０は、初期レイアウトテンプレートデータおよび基本情報に従ってページの初期レンダリングを実行し、初期レンダリングの後にページを提示するステップを行うための初期レンダリングモジュール４７をさらに含む。
【００８６】
初期レイアウトテンプレートデータおよび基本情報は、事前に構成されることが可能であり、それによってユーザは、表示される商品のタイトルおよび価格等などの基本的なページコンテンツを見ることができる。
【００８７】
いくつかの実施形態によれば、コンポーネントは、ＵＩコンポーネントであり、コンポーネントライブラリおよびデータレイヤは、クライアントに配置されており、クライアントは、ページローダが内部に配置されているアプリケーションに対応するサービスパケットをさらに含む。
【００８８】
いくつかの実施形態によれば、クライアントは、異なるアプリケーションにとって共通して利用可能な他のモジュールをさらに含み、他のモジュールは、コアライブラリ、フロー管理モジュール、およびライフサイクル管理モジュールというアイテムのうちの１つまたは複数を含む。
【００８９】
いくつかの実施形態によれば、クライアントは、適合レイヤをさらに含み、適合レイヤは、異なるアプリケーションの実施情報を含み、レンダリング中に、データレイヤは、対応するアプリケーションの実施情報に従ってレンダリングプロセスを実行する。
【００９０】
いくつかの実施形態によれば、さまざまなアプリが、共通のコンポーネントへと分割されることが可能であり、単一の開発プロセスに伴って、サービスが、モバイル端末の異なるアプリに迅速に適用されることが可能である。この方法においては、研究コストおよび／または開発コストが大幅に低減され、サービスがオンラインで迅速かつ並列にもたらされることが可能である。
【００９１】
本出願の説明においては、「第１の」および「第２の」等などの用語は、説明の目的で使用されているにすぎず、相対的な重要度の表示または含意として解釈されるものではないということに留意されたい。加えて、本出願の説明においては、別段の記載がない限り、「複数の」という用語は、少なくとも２つを意味する。
【００９２】
フローチャートにおける、または本明細書において他の形で記述されているいかなるプロセスまたは方法の説明も、そのプロセスにおける特定の論理的な機能またはステップを実施するための１つまたは複数の実行可能な命令を含むコードのモジュール、セグメント、または部分を表していると理解されるべきであり、本出願の実施形態の技術分野における技術者によってなら理解されるであろうが、含まれている機能性に応じて、実質的に同時に、または逆の順序でなど、示されているまたは論じられている順序とは異なる順序で機能が実行されることが可能である代替実施態様は、本出願の好ましい実施形態の範囲内に含まれる。
【００９３】
本出願の個々の部分は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの組合せを通じて実施されることが可能であるということを理解されたい。上述の実施形態においては、複数のステップまたは方法が、メモリ内に格納されて適切な命令実行システムによって実行されるソフトウェアまたはファームウェアによって実施されることが可能である。たとえば、それがハードウェアで実施される場合には、他の実施形態と同様に、それは、当技術分野においてよく知られている次のテクノロジー、すなわち、データ信号上で論理機能を実施するための論理ゲートを有するディスクリート論理回路、適切な組合せ論理ゲートを有する特定用途向け集積回路、プログラマブルゲートアレイ（ＰＧＡ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）などのうちの任意の１つまたは組合せとともに実施されることが可能である。
【００９４】
上述の実施形態の方法に含まれているステップのうちのすべてまたはいくつかは、関連するハードウェアに指示するプログラムによって実現されることが可能であり、プログラムは、コンピュータ可読記録媒体内に格納されることが可能であり、実行されるときに、方法実施形態のステップのうちの１つまたは組合せを含むということを当技術分野における標準的な技術者なら理解することができる。さらに、本出願のそれぞれの実施形態における個々の機能ユニットは、処理モジュール内に統合されることが可能であり、または個々のユニットは、物理的に別々に存在することも可能であり、または複数のユニットがモジュール内に統合されることも可能である。上述の統合されたモジュールは、ハードウェアの形態で、またはソフトウェア機能モジュールの形態で実装されることが可能である。統合されたモジュールは、ソフトウェア機能モジュールの形態で実装されて、独立した製品として販売または使用される場合には、コンピュータ可読記録媒体内に格納されることが可能である。
【００９５】
上述の記録媒体は、読み取り専用メモリ、ディスケット、または光ディスクなどであることが可能である。
【００９６】
本明細書の説明においては、「実施形態」、「いくつかの実施形態」、「例」、「特定の例」、または「いくつかの例」などの参照用語の説明は、実施形態または例と併せて記述されている特定の機能、構造、素材、または特徴が、本出願の少なくとも１つの実施形態または例に含まれているということを意味する。本明細書においては、上述の用語の概要表現は、必ずしも同じ実施形態または例を指しているとは限らない。その上、記述されている特定の機能、構造、素材、または特徴は、任意の１つまたは複数の実施形態または例において適切な方法で組み合わされることが可能である。
【００９７】
本出願の実施形態が本明細書において例示および記述されてきたが、上述の実施形態は、例示的なものであり、本出願を限定するものとして解釈されることは不可能であり、当技術分野における標準的な技術者なら、本出願の範囲内で上述の実施形態に対する変更形態、修正形態、置換形態、および変形形態を作成することができるということが理解されるであろう。
【図１】
2018537783.tif 000003
【図２】
2018537783.tif 000004
【図３】
2018537783.tif 000005
【図４】
2018537783.tif 000006
【図５】
2018537783.tif 000007
【国際調査報告】
2018537783.tif 000008