連載 アプリケーション・アーキテクチャ・ガイド2.0解説 第6回 典型的なアプリケーションのパターン（後編） 日本ユニシス　猪股 健太郎 2009/12/15
Page1 Page2 Page3 Page4

■モバイル･アプリケーション

　携帯端末向けアプリケーションであるモバイル・アプリケーションも、一般的なアプリケーションと同じく、プレゼンテーション層、ビジネス層、データ・アクセス層の3階層から構成される。

　モバイル・アプリケーションはWebアプリケーションとすることもできるし、リッチ・クライアント・アプリケーションとすることもできる。下の図はモバイル用リッチ・クライアント・アプリケーションの典型的な例を示したものである。

モバイル用リッチ・クライアント・アプリケーションの典型的な構造

　モバイル・アプリケーションのアーキテクチャ・フレームとして、AAGでは下記のものを取り上げている。ここでは、その中から「デバイス」「移植」「電力管理」「データ同期」「UI（ユーザー・インターフェイス）」の5つを説明しよう。

モバイル・アプリケーションのアーキテクチャ・フレーム

認証

承認

キャッシュ化

通信

構成管理

データ・アクセス層

デバイス

例外管理

ログ出力

移植

電力管理

データ同期

テスト

UI

入力値検証

パフォーマンス

配布

●デバイス

　モバイル・デバイス向けのアプリケーション設計・開発は、ハードウェアの特性に依存する部分が大きい。デバイスごとに画面サイズや向き、メモリやストレージの量、ネットワーク帯域が大きく異なることが普通なので、複数のデバイスをサポートしたい場合は、異種環境を意識した設計にしなければならない。

注意点：

• 画面サイズや向き、メモリやストレージの量、ネットワーク帯域、CPU性能といったハードウェア能力を考慮し、アプリケーションをデバイスに最適化する
• GPU、GPS、カメラ、振動、コンパスといったデバイス固有の機能を活用し、アプリケーションの機能を向上させる
• 複数のデバイスで動作するアプリケーションを開発する場合は、最初はどのデバイスでも利用できる機能だけを前提として設計し、次に、デバイス固有の機能を検出した場合のカスタマイズ機能を検討する
• アプリケーション・コードをモジュール化し、実行ファイルから簡単に削除できるようにしておく。これは、デバイスのメモリ量からくる制約として、アプリケーションを複数の実行ファイルに分割しなければならない場合に備えるためである

●移植

　アプリケーションを別の実行環境に移植する場合、修正がまったく不要なことはほとんどないが、その中にも移植しやすいアプリケーションと移植しにくいアプリケーションがある。既存のアプリケーションをモバイル・デバイスに移植する場合は以下の点に注意する。

注意点：

• デスクトップ向けのリッチ・クライアント・アプリケーションを移植する場合は、全体的に書き直すべきである。リッチ・クライアント・アプリケーションが小さな画面サイズと小さなディスク容量に適していることはほとんどない
• Webアプリケーションを移植する場合は、小さな画面サイズ向けにUIを書き直す。また、サーバとの通信を可能な限り少なくする。頻繁に通信すると、バッテリを早く消費してしまう上に、通信費も高くついてしまう
• RIAを移植する場合は、修正なしで移植できるのはどの部分かを事前に調査しておく
• 移植ツールを評価して活用する。例えば、Javaで書かれたコードをC言語に変換するツールなどである。Visual Studioには、スマートフォン用プロジェクトをPocket PC向けに変更する場合や、デスクトップ・アプリケーションをモバイル・アプリケーションに変更する場合に、非互換部分を指摘する機能がある
• カスタム・コントロールをモバイル向けに移植することはあきらめた方がいい。APIや、使用可能なメモリ量や、UIの振る舞いがまったく異なるためである。なるべく早期にコントロールを調査し、コントロールを書き直すか、代替案を検討するべきである

●電力管理

　モバイル・デバイスで一番制限が強いのは電力である。モバイル・アプリケーションを設計する場合、その機能がどのぐらい電力を消費し、バッテリの持ちに影響するかを常に考慮する必要がある。デバイスを選ぶことができる場合は、USBなどから電力をとれるもの選ぶとよい。また、通信方式によってどのぐらい電力消費量が変わるかを調査するとよい。

注意点：

• バッテリを無駄に消費しないようにするために、アプリケーションがバックグラウンドに回っているときはUIを更新しない
• ネットワーク速度だけでなく電力消費も考慮して通信方式を選ぶ
• デバイスが外部電源に接続しているのでなければ、不必要な無線通信は避ける
• デバイスが外部電源に接続し、かつバッテリを充電していないときにパフォーマンスを向上できるように、電源プロファイルに対応する
• デバイスの一部機能を使わないときに、その部分への電力供給を止められるような設計にする。よくある例は、画面のバックライトや、ハード・ドライブ、GPS、スピーカー、無線通信である
• 無線通信で転送するデータ量は極力小さくする。それを達成できるように、プロトコルを選んだり、サービス・インターフェイスを設計したり、通信をバッチ化したりする
• 3G通信を使うことを検討するときには、旧世代の通信方式よりも高速である半面、電力消費量も大きいことを意識する。3Gを使うにしても、まとめて一気に送受信し、不要になったら通信を切断するようにしなければならない

●データ同期

　無線通信によるデータ同期や、クレードル接続時のデータ同期の必要性を明確にする。

　データ同期では機密性の高いデータを扱うことも多いため、特に無線通信によるデータ同期では、データの暗号化を検討する。データ同期中に接続が切れる可能性も考慮し、データ同期自体をキャンセルするか、または一時的に中断して再接続時に再開するか、どちらかに対応する。

　SQL Serverを使うことで、マージ・レプリケーション機能を活用することができる。あるいは、さまざまな状況に対応するためにSync Frameworkを使ってもよい。

注意点：

• データ同期が初期化された場合のリカバリ方法や、データ矛盾が発生した場合の対応について設計しておく
• SQL Serverを双方向で同期させたい場合は、マージ・レプリケーション機能を使う。ただし、マージ・レプリケーションではマージする必要があるデータをすべて転送するので、ネットワーク帯域を多く必要とする
• オフィスにいないときにもデータ同期が必要であれば、無線接続による同期を検討する
• オフィスのPCと同期させるだけでよければ、クレードル接続時のデータ同期を検討する
• データをいったん蓄積してからまとめて送る方式をとる場合は、電子メールやSMSではなく、配送保証機能があるWCFを利用する

関連するパターン：

• Data Patterns（英語）

●UI

　モバイル・アプリケーションのUIを設計する場合、デスクトップ・アプリケーションのUIを再利用するべきではない。可能な限りシンプルなUIを設計したうえでペン入力などに対応する。

　モバイル・アプリケーションは通常フルスクリーン・モードで動作するので、処理がブロックされる状況ではユーザーからの入力を受け付けることができなくなることに注意する。

注意点：

• スタイラスや指を使って入力している間は、タッチスクリーンUIは妨害されてしまうことに気を付ける
• 単一ウィンドウでフルスクリーン状態になっていることを前提としたUI設計にする。デバイスが単一ユーザー向けであり、アプリケーションを1つしか動かさないのであれば、キオスク・モードを検討する
• スタイラスや、キーボード、タッチスクリーンといった多様な入力デバイスに対応する。例えばタッチスクリーンのためには、ボタンをある程度大きくしておく必要がある。また、多様な画面サイズに対応する必要もある
• ユーザー操作を受け付けなくなるような処理を実行しているときには、砂時計を表示するなど、それと分かるような表示をする

関連するパターン：

• アプリケーション・コントローラ
• モデル・ビュー・コントローラ
• Model-View-Presenter（英語）
• ページ切り替え（英語）

■

　モバイル・アプリケーションのまとめとして、モバイル・アプリケーションの構築に利用できる実装テクノロジを表にまとめる。

テクノロジ	利用シナリオ
Silverlight for Mobile（*注1）	デスクトップPCとモバイル端末の両方で動作する、リッチメディアをサポートするインタラクティブなアプリケーションを構築する場合。
通常のASP.NET Webアプリケーション	デスクトップPCとモバイル端末の両方で動作するWebアプリケーションを構築する場合。（*注2）
.NET Compact Framework	デスクトップ・アプリケーションとモバイル・アプリケーションを同時に開発する場合。
Windows Mobile Professional	PDAなど、タッチパネルを持った携帯端末の場合。
Windows Mobile Standard	スマートフォンなど、タッチパネルを持たない携帯端末の場合。
モバイル・アプリケーションの構築に利用できる実装テクノロジ
（*注1） 製品として計画はされているが、2009年12月段階でまだリリースされていない。Silverlight 2アプリケーションが動作するようになるといわれている。 （*注2） ASP.NET Mobileコントロールはデバイスごとに異なるHTMLを出力するためテストが困難であることと、Visual Studio 2008には含まれていないことから、推奨しない。

INDEX
	連載：アプリケーション・アーキテクチャ・ガイド2.0解説
	第6回 典型的なアプリケーションのパターン（後編）
	1．サービス
	2．モバイル･アプリケーション
	3．OBA
	4．SharePoint業務アプリケーション

「アプリケーション・アーキテクチャ・ガイド2.0解説」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）