アプリケーションの開発

improve this page | report issue

開発の概念および概要

IBM Mobile Foundation ツール・セットを使用してアプリケーションを開発する際、さまざまなコンポーネントおよびエレメントを開発したり構成したりする必要があります。 アプリケーションの開発時に必要になるコンポーネントおよびエレメントについて理解すると、開発を円滑に進める上で役立ちます。

これらの概念に精通することに加え、JSONStore や WLResourceRequest など、ネイティブ、Cordova、および Web のアプリケーション用の MobileFirst 提供の API についても学習します。また、アプリケーションのデバッグ、ダイレクト・アップデートを使用した Web リソースの更新、ライブ・アップデートを使用した userbase のセグメント化の方法を学習し、MobileFirst CLI を使用したアプリケーション、アダプター、およびその他の成果物の処理方法も学習します。

これらのさまざまな MobileFirst コンポーネントについて詳細を学習するには、サイドバー・ナビゲーションから関連トピックにナビゲートすることも、このまま読み続けることもできます。

ジャンプ先

アプリケーション

アプリケーションは、ターゲット MobileFirst Server 用にビルドされ、ターゲット・サーバー上にサーバー・サイドの構成があります。 アプリケーションは、構成する前に MobileFirst Server に登録する必要があります。

アプリケーションは次のエレメントで識別されます。

  • アプリケーション ID
  • バージョン番号
  • ターゲット・デプロイメント・プラットフォーム

注: バージョン番号は、Web アプリケーションには適用されません。 同じ Web アプリケーションについて複数のバージョンを持つことはできません。

これらの ID は、アプリケーションが正しくデプロイされ、アプリケーションに割り当てられたリソースのみを使用することを確実にするために、クライアント・サイドとサーバー・サイドの両方で使用されます。 Mobile Foundation のさまざまな部分が、これらの ID のいろいろな組み合わせを異なる方法で使用します。

アプリケーション ID はターゲット・デプロイメント・プラットフォームにより異なります。

Android
ID はアプリケーション・パッケージ名です。

iOS
ID はアプリケーション・バンドル ID です。

Windows
ID はアプリケーション・アセンブリー名です。

Web
ID は開発者によって割り当てられる固有の ID です。

異なるターゲット・プラットフォームのアプリケーションがすべて同じアプリケーション ID を持つ場合、MobileFirst Server は、これらのすべてのアプリケーションを、異なるプラットフォーム・インスタンスを持つ同じアプリケーションであるとみなします。 例えば、次のアプリケーションは、同じアプリケーション の異なるプラットフォーム・インスタンスであるとみなされます。

  • com.mydomain.mfp というバンドル ID を持つ iOS アプリケーション。
  • com.mydomain.mfp というパッケージ名を持つ Android アプリケーション。
  • com.mydomain.mfp というアセンブリー名を持つ Windows 10 Universal Windows Platform アプリケーション。
  • com.mydomain.mfp という割り当てられた ID を持つ Web アプリケーション。

アプリケーションのターゲット・デプロイメント・プラットフォームは、アプリケーションがネイティブ・アプリケーションとして開発されたか Cordova アプリケーションとして開発されたかに依存しません。 例えば、次のアプリケーションは両方とも Mobile Foundation の iOS アプリケーションとみなされます。

  • Xcode およびネイティブ・コードを使用して開発する iOS アプリケーション
  • Cordova クロスプラットフォーム開発テクノロジーを使用して開発する iOS アプリケーション

注: Xcode 8 を使用する場合、iOS シミュレーターでの iOS アプリケーションの実行中は、キーチェーン共有機能が必須です。Xcode プロジェクトをビルドする前に、この機能を手動で有効にする必要があります。

アプリケーション構成

上述のように、アプリケーションはクライアント・サイドとサーバー・サイドの両方で構成されます。

ネイティブおよび Cordova iOS、Android、および Windows のアプリケーションの場合、クライアント構成はクライアント・プロパティー・ファイル (iOS の場合は mfpclient.plist、Android の場合は mfpclient.properties、Windows の場合は mfpclient.resw) に保管されます。 Web アプリケーションの場合、構成プロパティーは SDK 初期化メソッド にパラメーターとして渡されます。

クライアント構成プロパティーには、アプリケーション ID、およびサーバーにアクセスするために必要な MobileFirst Server ランタイムの URL やセキュリティー・キーなどの情報が含まれます。
アプリケーションのサーバー構成には、アプリケーション管理ステータス、ダイレクト・アップデート用の Web リソース、構成されたセキュリティー・スコープ、ログ構成などの情報が含まれます。

MobileFirst クライアント SDK の追加方法は、『Mobile Foundation SDK の追加』チュートリアルを参照してください。

クライアント構成は、アプリケーションをビルドする前に定義する必要があります。 クライアント・アプリケーションの構成プロパティーは、MobileFirst Server ランタイムでこのアプリケーションに対して定義されているプロパティーと一致している必要があります。 例えば、クライアント構成内のセキュリティー・キーは、サーバー上のキーと一致している必要があります。 Web 以外のアプリケーションの場合は、クライアント構成を MobileFirst CLI で変更することができます。

アプリケーションのサーバー構成は、アプリケーション ID、バージョン番号、ターゲット・プラットフォームの組み合わせに関係しています。 アプリケーションのサーバー・サイド構成を追加するには、事前にアプリケーションを MobileFirst Server ランタイムに登録する必要があります。 アプリケーションのサーバー・サイドは、通常は MobileFirst Operations Console を使用して構成されます。 アプリケーションのサーバー・サイドは、以下の方法でも構成することができます。

また、これらの方式を使用して MobileFirst Server の構成を自動化することもできます。

留意点: MobileFirst Server が稼働中でアプリケーションからトラフィックを受信中であっても、サーバー構成を変更することができます。 アプリケーションのサーバー構成を変更するためにサーバーを停止する必要はありません。

実動サーバーでは、アプリケーションのバージョンは通常、アプリケーション・ストアにパブリッシュされたアプリケーションのバージョンに相当します。 アプリケーションの認証性のための構成など、一部のサーバー構成エレメントは、ストアにパブリッシュされたアプリケーションに固有です。

MobileFirst Server

モバイル・アプリケーションのサーバー・サイドは、MobileFirst Server です。 MobileFirst Server により、ユーザーはアプリケーション管理やアプリケーション・セキュリティーなどの機能にアクセスでき、またモバイル・アプリケーションはアダプターを介して他のバックエンド・システムにセキュアにアクセスできます。

MobileFirst Server は、多くの Mobile Foundation 機能を提供するコア・コンポーネントです。機能の例を以下に示します。

  • アプリケーション管理
  • デバイスおよびユーザーの認証やアプリケーション認証性の検査などのアプリケーション・セキュリティー
  • アダプターを介したバックエンド・サービスへのセキュア・アクセス
  • ダイレクト・アップデートを使用した Cordova アプリケーションの Web リソースの更新
  • プッシュ通知およびプッシュ・サブスクリプション
  • アプリケーション分析

開発から、テスト、実動デプロイメント、保守に至るまでのアプリケーションのライフサイクル全体で、MobileFirst Server を使用する必要があります。

アプリケーションを開発する際に使用可能な事前構成済みのサーバーが用意されています。 アプリケーションの開発時に使用する MobileFirst Server については、『MobileFirst 開発環境のセットアップ』を参照してください。

MobileFirst Server は、以下のコンポーネントで構成されます。 これらのすべてのコンポーネントは、MobileFirst Serverにも含まれています。 単純なケースでは、すべて同じアプリケーション・サーバー上で実行されますが、実動環境またはテスト環境では、コンポーネントは異なるアプリケーション・サーバーで実行される可能性があります。 これらの MobileFirst Server コンポーネントの可能なトポロジーについては、『トポロジーおよびネットワーク・フロー (Topologies and network flows)』を参照してください。

MobileFirst および MobileFirst Server 管理サービス

Operations Console は、MobileFirst Server 構成を表示および編集するために使用できる Web インターフェースです。 ここから MobileFirst Analytics Console にアクセスすることもできます。 開発サーバーにおける Operations Console のコンテキスト・ルートは、/mfpconsole です。

管理サービスは、アプリケーションを管理するためのメインエントリー・ポイントです。 MobileFirst Operations Console を使用して Web ベースのインターフェースから管理サービスにアクセスできます。 また、mfpadm コマンド・ライン・ツールまたは管理サービス REST API を使用して管理サービスにアクセスすることもできます。

詳しくは、MobileFirst Operations Console フィーチャーに関する説明を参照してください。

MobileFirst runtime

ランタイムは、MobileFirst クライアント・アプリケーションのメインエントリー・ポイントです。 ランタイムは、Mobile Foundation OAuth 実装のデフォルトの許可サーバーでもあります。

高度でまれなケースですが、単一の MobileFirst Server でデバイス・ランタイムの複数のインスタンスを使用できます。 各インスタンスには、独自のコンテキスト・ルートがあります。 コンテキスト・ルートは、Operations Console でランタイムの名前を表示するために使用されます。 異なるサーバー・レベルの構成 (鍵ストアの秘密鍵など) が必要な場合、複数のインスタンスを使用します。

MobileFirst Server に含まれているデバイス・ランタイムのインスタンスが 1 つだけの場合、通常、ランタイムのコンテキスト・ルートを知る必要はありません。 例えば、MobileFirst Server にランタイムが 1 つだけ含まれている場合に mfpdev app register コマンドを使用してランタイムにアプリケーションを登録すると、そのアプリケーションはそのランタイムに自動的に登録されます。

MobileFirst Server プッシュ・サービス

プッシュ・サービスは、プッシュ通知やプッシュ・サブスクリプションなどのプッシュ関連操作のメインアクセス・ポイントです。 プッシュ・サービスに接続するために、クライアント・アプリケーションはランタイムの URL を使用しますが、コンテキスト・ルートを /mfppush に置き換えます。 MobileFirst Operations Console またはプッシュ・サービス REST API を使用してプッシュ・サービスを構成および管理できます。

MobileFirst ランタイムとは異なるアプリケーション・サーバーでプッシュ・サービスを実行する場合、HTTP サーバーでプッシュ・サービス・トラフィックを正しいアプリケーション・サーバーに経路指定する必要があります。

MobileFirst Analytics および MobileFirst Analytics Console

IBM MobileFirst Foundation Operational Analytics Receiver は、モバイル・アプリが分析ログとロガー・ログを IBM MobileFirst Foundation Operational Analytics に転送するために使用できる、分析ログとロガー・ログの転送機能を提供するオプション・コンポーネントです。 このサービスを使用すると、MobileFirst Server で実行されるログ処理が解放されます。

MobileFirst Analytics および MobileFirst Analytics Console

IBM MobileFirst Foundation Operational Analytics は、MobileFirst Operations Console からアクセスできる拡張が容易な分析機能を提供するオプションのコンポーネントです。 この分析機能により、デバイス、アプリケーション、およびサーバーから収集されたログおよびイベント全体でパターン、問題、およびプラットフォーム使用統計を検索できます。

MobileFirst Operations Console で、分析サービスへのデータの転送を有効または無効にするフィルターを定義できます。 また、送信される情報のタイプをフィルターに掛けることもできます。 クライアント・サイドでは、クライアント・サイド・ログ・キャプチャー API を使用して、イベントおよびデータを分析サーバーに送信できます。

目的のトポロジーに MobileFirst Server をインストールして構成した後には、以下の方法のいずれかを使用して、MobileFirst Server およびそのアプリケーションの追加構成をすべて行えます。

  • MobileFirst Operations Console
  • MobileFirst Server 管理サービス REST API
  • mfpadm コマンド・ライン・ツール

初期インストールおよび構成が終わると、Mobile Foundation を構成する場合に、アプリケーション・サーバー・コンソールやインターフェースにアクセスする必要はありません。
アプリケーションを実動にデプロイする場合、アプリケーションを以下の MobileFirst Server 実稼働環境にデプロイできます。

オンプレミス

オンプレミス環境での MobileFirst Server のインストールおよび構成については、IBM MobileFirst Server のインストールを参照してください。

クラウド

アダプター

Mobile Foundation のアダプターは、クライアント・アプリケーションとクラウド・サービスにバックエンド・システムをセキュアに接続します。

アダプターは、JavaScript または Java で作成することができ、Maven プロジェクトとしてビルドおよびデプロイすることができます。
アダプターは、MobileFirst Server の MobileFirst ランタイムにデプロイされます。

実動システムでは、アダプターは通常、アプリケーション・サーバーのクラスターで実行されます。 サーバーでセッション情報をローカルに保管せずに、アダプターを REST サービスとして実装し、アダプターがクラスター環境で正常に機能するようにします。

アダプターには、ユーザー定義のプロパティーを指定することができます。 これらのプロパティーは、アダプターを再デプロイせずにサーバー・サイドで構成することができます。 例えば、テストから実動に移行する際に、アダプターがリソースにアクセスするために使用する URL を変更できます。

アダプターを MobileFirst ランタイムにデプロイするには、mfpdev adapter deploy コマンドを使用して MobileFirst Operations Console からデプロイするか、または Maven から直接デプロイすることができます。

アダプターについて、および JavaScript アダプターおよび Java アダプターの開発方法についての詳細は、アダプターのカテゴリーを参照してください。

次に使用するクライアント・サイドのチュートリアル

▲
Inclusive terminology note: The Mobile First Platform team is making changes to support the IBM® initiative to replace racially biased and other discriminatory language in our code and content with more inclusive language. While IBM values the use of inclusive language, terms that are outside of IBM's direct influence are sometimes required for the sake of maintaining user understanding. As other industry leaders join IBM in embracing the use of inclusive language, IBM will continue to update the documentation to reflect those changes.
Last modified on June 17, 2020