いろいろな場所へ : Windows Mobile 用のアダプタブルアプリケーション

いろいろな場所へ

Windows Mobile 用のアダプタブルアプリケーション

Michael Saffitz

アダプタブルアプリケーション
デザインとアーキテクチャ
表示の違い
ネイティブアプリケーションの解像度認識
マネージアプリケーションの解像度認識
基本的なデバイスの違い
その他のデバイスの違い
テストとさらなる探求

Microsoft が Pocket PC 2000 を最初に出荷したとき、およびその後数年間は、開発者が、すべてのデバイスで正常に実行できる 1 つのアプリケーションを比較的簡単に作成できました。一般には、すべてのデバイスに、タッチサポート、画面解像度、縦長の向き、API セットなど、同じ機能と特性がありました。したがって、ほぼアプリケーションの機能だけに集中できました。このような、デバイスのその他の要素を気にする必要はなく、これらの要素が変更される可能性を考慮する必要はまったくありませんでした。

しかし、変化は避けられません。市場とテクノロジが開発されるにつれて、より多くのデバイスが使用可能になり、これらのデバイスは多様なデザインを持ち始めました。使用可能な Windows Mobile® 電話は 2008 年までに急速に増え、今では 140 種類を超えました。これらの電話は、12 のキーと QWERTY キーボード、キャンディバースタイルと折りたたみ式スタイル、GPS の有無、正方形、縦長、横長の画面、Wi-Fi、Bluetooth、赤外線通信、デバイスごとに異なるその他の機能など、さまざまなオプションをサポートします。Pocket PC 2000 とは異なり、顧客はニーズ、好み、予算に合ったデバイスをはるかに簡単に見つけられるようになっています。

アダプタブルアプリケーション

一方、このような Windows Mobile デバイスの多様性の拡大によって、開発者はこれらの違いを認識し、アプリケーションでこれらの違いを計画することが必要になりました。開発者は、アダプタブルアプリケーション (すべての Windows Mobile デバイスで正常に動作し、優れた外観を持つアプリケーション) と呼ばれる適応性に優れたアプリケーションを構築する必要があります。

さいわい、オペレーティングシステムとして、Windows Mobile は複数のデバイスで使用できる最も一貫性のあるモバイルプラットフォームのコア API セットの 1 つを提供します。Windows Mobile 開発者は、デバイスの携帯電話会社やハードウェアメーカーに関係なく、(デスクトップに見られるものと多くの点で一致するようにデザインされた) 同じコア API セットを見つけることができます。

その結果、アダプタブルアプリケーションを構築するほとんどの開発者は、異なる画面解像度、ドット/インチ (DPI)、および向きへの対処が主要なフォーカス分野となることに気付きます。より少数の開発者にとっては、デバイスの機能 (テレフォニーの存在や GPS など) の違い、Windows Mobile の主要リリース間での API の変更、およびタッチデバイスと非タッチデバイスの両方を対象としたデザインも、考慮が必要な領域になります。

開発者がアダプタブルアプリケーションの作成に使用できるツールと手法をいくつか示します。一般的なデザインとアーキテクチャの原理を説明してから、画面と機能の違いへの適応に関連する詳細を掘り下げます。

確かに、アダプタブルアプリケーションの作成を選択するときにいくつかの追加の注意と考慮が必要ですが、多くの場合、先行投資の利益は、別の方法 (現在および将来のすべてのデバイスに対してアプリケーションのバージョンを開発およびテストすること、またはデバイスをサポートしないことを選択して潜在的なユーザーベースを制限すること) を選んだ場合の利益を大幅に上回ります。

設計とアーキテクチャ

アダプタブルアプリケーションを作成する場合は、実績のある慣行とアーキテクチャパターンに従うことが重要です。実践の観点からは、要件を慎重かつ明示的に識別することで、アプリケーションで必要な最小のデバイスプロファイルを理解し始めることができます。また、存在する場合にはアプリケーションで動的に使用できるオプション機能も識別します。このアプローチをとる場合には、コードを最小の共通部分にする必要なく、アプリケーションを最大数のデバイスで実行できます。

簡単な例として、単純なパッケージ配信追跡アプリケーションの構築を要求されたとしましょう。要件を調べ、パッケージが正常に配信されたことを示す署名を収集する必要があると判断しました。あると便利な機能として、アプリケーションではオンライン追跡用にパッケージステータスをサーバーにアップロードする必要があります。署名を収集する必要があるので、アプリケーションはタッチデバイス (Windows Mobile Professional および Windows Mobile Classic) に制限されます。これを特定したことで、タッチを必要とする追加機能 (ボタンコントロールなど) を自由に使用できることになります。

同時に、接続コンポーネントの設計も慎重に検討する必要があります。たとえば、アプリケーションが移動体通信データ接続にアクセスする必要があると想定した場合は、電話機能はないが Wi-Fi はある Classic デバイスを除外します。

最後に、クライアントの気が変わって、署名要件を取り除いた場合、その後のボタンコントロールの使用を考えると、必ずしも非タッチデバイス (Window Mobile Standard) をサポートできる必要はありません。

表示の違い

前に述べたように、多くの場合、画面の解像度、DPI、および向きの違いは、アダプタブルアプリケーションの作成時に最も差し迫った問題になります。ここでも、これらの違いを計画し、アーキテクチャについてよく考えることは、ソリューションの実装時に大きな影響を与えます。

現在サポートされている Windows Mobile 6 解像度、DPI、向き、およびアイコンの寸法を、図 1 に示します。これらに加えて、マイクロソフトは、新しい構成、OEM (Original Equipment Manufacturer)、および携帯電話会社を追加することがあります。また、一部のデバイスでは、画面の向きの動的な回転をサポートします。たとえば、縦長の 240×320 で表示するデバイスは、キーボードがスライドアウトされたときに横長の 320×240 の表示に回転されることがあります。

図 1 Windows Mobile 6 の表示オプション

Windows Mobile Professional および Classic (タッチスクリーンあり)
解像度	DPI	向き	小さいアイコン	大きいアイコン
240×240	96	正方形	16×16	32×32
240×320	96	縦長および横長	16×16	32×32
240×400	96	縦長および横長	16×16	32×32
320×320	128	正方形	21×21	43×43
480×480	192	正方形	32×32	64×64
240×240	192	縦長および横長	32×32	64×64
240×240	192	縦長および横長	32×32	64×64
Windows Mobile Standard (タッチスクリーンなし)
解像度	DPI	向き	小さいアイコン	大きいアイコン
176×220	96	縦長	16×16	32×32
240×320	131	縦長および横長	22×22	44×44
320×320	131	正方形	22×22	44×44
240×400	131	縦長および横長	22×22	44×44
440×240	131	横長	22×22	44×44

これまで以上に、アプリケーションで 1 つ以上の画面特性を前提とせずに、すべての解像度、向き、および少なくとも 96 DPI と 131 DPI に動的に適応し、これらをサポートするアプリケーションを作成することが重要になっています (192 DPI も重要ですが、非常に少数のデバイスに限定される傾向にあります。128 DPI は 131 DPI に十分近いので、大きな問題にはなりません)。

このタスクを簡単にし、ネイティブアプリケーションとマネージアプリケーションの両方の開発に使用できるリソースとツールがいくつかあります。これらのうちのいくつかを説明し、解像度を認識するアプリケーションの作成プロセスで使用できる一般的なアプローチとベストプラクティスを確認します。

ネイティブアプリケーションの解像度認識

Windows Mobile 6 SDK は、ネイティブコードで解像度認識アプリケーションを作成するための 2 つの主要リソースを提供しています。それは、UILayout サンプル内の再利用可能な ScreenLib クラスと、DeviceResolutionAware.h ヘッダーです。UILayout サンプルは、Windows Mobile SDK の \Samples\Common\CPP\Win32 ディレクトリにあります。DeviceResolutionAware.h は、Microsoft® Visual Studio® インストールディレクトリの \VC\ce\atlmfc\include ディレクトリにインストールされます。

ScreenLib は、画面に要素を配置するためのヘルパ関数のセットを提供します。たとえば、DockControl 関数を使用して、特定のコントロールを画面の端にドッキングしたり、4 辺にドッキングしてクライアント領域を充填したりできます。OptimizeWidth および OptimizeHeight 関数は、1 つのコントロール (OptimizeWidth の場合は複数のコントロール) を画面で配置およびサイズ変更し、左右と上下にそれぞれ小さな余白を残します。コントロールを配置するため、およびコントロールのセットを同じサイズに変更するための追加関数があります。これらの関数によって、ScreenLib は、フォームベースアプリケーションを大量に処理するときに最も役立つ傾向にあります。

DeviceResolutionAware.h は、ScreenLib で省かれた場所を取り上げ、より複雑なアダプタブルアプリケーションの作成を支援する 20 を超える関数とマクロを提供します。これらは、GetDisplayMode (ディスプレイの特性と機能を提供します) などの適応性の高いユーザーインターフェイスの構成要素を提供する基本的な関数とマクロから開始します。

現在の解像度に合わせて値を拡大縮小する SCALEX、SCALEY、SCALERECT、および SCALEPT があります。次に、StretchIcon や ImageList_StretchBitmap など、現在のディスプレイ特性に合わせてイメージを拡大縮小するのに役立つ関数があります。また、RelayoutDialog などの関数を使用して、向きが変更されたときにダイアログのレイアウトを自動的に調整できます。

ScreenLib と DeviceResolutionAware.h は、ネイティブの解像度認識アプリケーションを作成するための強力な基盤を提供します。ただし同時に、表示バッファとの直接対話や複雑な UI の作成時には特に、状況に固有のデザインとソリューションの代わりにはならないことに注意することが重要です。

マネージアプリケーションの解像度認識

マネージコードアプリケーションの場合、Microsoft .NET Compact Framework は、解像度を認識するアプリケーションの作成時に役立つ表示プロパティのセットを提供します。ScreenLib 内の機能と同様に、.NET Compact Framework は、指定されたコントロールを親の端にバインドする Control.Dock プロパティを提供します。Control.Anchor は、親の端からの固定距離にコントロールをバインドすることで、同様の機能を提供します。Control.AutoScroll プロパティを使用すると、フォーム内のコントロールが画面に治まらない場合にスクロールバーが自動的に追加されます。さらに、Control.AutoScale は、フォームがデザインされた解像度を追跡し、DPI または解像度が変更された場合にフォームを動的に拡大縮小します。想像どおり、Control.AutoScale プロパティは単純なフォームに対しては適切に動作しますが、フォームが複雑になると、実行できる機能は制限されます。

より複雑なフォームに対して、これらのプロパティは開始点を提供しますが、向きの変更に対する動的な調整の点では特に、必ずしも完全なソリューションにはなりません。1 つのアプローチは、Microsoft patterns & practices グループが Mobile Client Software Factory (msdn2.microsoft.com/library/aa480471) の一部としてリリースした Orientation Aware Control (OAC) を使用することです。OAC は、フォームベースのアプリケーションでは特に、複数の向きを対象とする簡単な方法を提供します。

OAC がインストールされると、Visual Studio のマネージフォームデザイナを使用して、縦長モードで UI をレイアウトし、OAC を使用して横長に回転できます。この新しい向きでは、横長に合わせて UI を調整できます。OAC は、エンドユーザーが縦長または横長モードのときに、適切なレイアウトが実行時に使用されるように変更を追跡します。

ただし、OAC の使用には弱点があります。まず、OAC では基本的に特定の向きと解像度の組み合わせをデザインできますが、サポートされる向きと解像度は将来的に変更される可能性があるので、このアプローチはお勧めできません。さらに、さまざまな DPI、または Windows Mobile Standard ベースのスマートフォンデバイスで最近普及してきた正方形の画面に対して明示的にデザインできません。最後に、OAC が画面ごとに複数のレイアウトを作成および管理すると、フォームと複雑さが追加されるので、パフォーマンスが大幅に低下します (極端な例では、アプリケーションの起動時間が著しく長くなることがあります)。

これらの弱点により、Windows Mobile チームは開発者に OAC からの移行を推奨してきました。そのグループは、Windows Mobile Line of Business Accelerator (go.microsoft.com/fwlink/?LinkId=115317) の新しいバージョンをリリースしています。このバージョンには、単一の UI を持ち、ドッキング、アンカー、およびその他の手法を利用する解像度認識アプリケーションの作成に役立つコンポーネントが含まれています。

基本的なデバイスの違い

さまざまなツールがあり、新しいアクセラレータがあるにもかかわらず、アダプタブルアプリケーションの作成に対する万能薬はありません。各アプローチには、ニーズと状況に対して評価する必要のある利点と欠点があります。しかし、採用するアプローチに関係なく、役に立つ可能性のある一般的なガイドラインがいくつかあります。

正方形、縦長、横長の 3 つの基本的な向きから開始し、それぞれに UI をレイアウトする方法について考えます。これが完了したら、UI がさまざまな解像度と DPI に適切にスケーリングされることの確認に集中できます。複雑な UI の場合は、デザインを調整してそれを複数のフォームに広げる方が、単一フォームに保持して向きが変更されたときに再配置するよりも簡単な場合があります。

ビジュアルアダプテーション用のアプリケーションを実装するときには、UI とアプリケーションロジックの間を明確に分離することがさらに重要になります。UI を対話のポイントと考え、フォームベースの考え方を避けることで、これらの要素が個々のフォームにマップされる方法の詳細を集中化および抽象化する管理クラスに UI 要素をカプセル化できます。

正方形画面専用にデザインすること、コントロールを上と左にドッキングすること、縦長および横長の向きを正方形に効果的に縮小して、ある種の適応性を提供することも考えられます。しかし、これを行う場合は、アプリケーションとユーザーから潜在的な画面スペースの 1/3 ～ 2/3 が奪われます。さらに、最初は開発時間を短縮するように見えたものが、結局より多くの時間を消費する場合があります。画面スペースが小さくなると、UI のデザインを制限したり、追加の画面を組み込んだりする必要が生じます。

その他のデバイスの違い

多くの場合、ディスプレイ特性の違いへの対処は、アダプタブルアプリケーションの作成の最大部分ですが、他の側面もあります。API は何年にもわたって導入、変更、および廃止されるので、Windows Mobile のバージョンが重要です。利用できるなら採用したいデバイス固有の機能もあるでしょう。

このような状況およびその他の状況でも、すべてのデバイスで実行できるようにアプリケーションを作成できます。基本機能を定義し、デバイス固有の実装を持つインターフェイスとの組み合わせでは特に、検討する 1 つの手法としてファクトリパターンがあります。

前に説明した収集作業のデザインと要件の一部を含む単純な例を見てみましょう。レストランのレビューを含むシティガイドの作成を求められました。コア要件は、レストランとレビューのディレクトリを含めることと、特定のレストランを選択して表示し、そのレビューを読む機能です。アプリケーションは Windows Mobile 2003 以降のバージョンで実行する必要があります。最後に、テレフォニーを提供するデバイスを使用するときに、レビュー画面からレストランに直接電話をかけられることという要件があります。

この例では C# を使用しますが、提示されている概念は Visual Basic® と C++ にも適用できます。マネージテレフォニー API は、最初に Windows Mobile 5.0 に導入されました。その結果、筆者のアプリケーションでは、アプリケーションが実行される Windows Mobile のバージョンを認識し、適切な実装を使用する必要があります。

まず、デバイスや特定の実装に関係なく、必要な共通機能を定義するテレフォニーインターフェイスを作成します。

interface ITelephony { 
  bool HasPhone {
    get;
  }
  void MakeCall(string phoneNumber);
}

次に、図 2 に 2 つの実装を示します。Windows Mobile 5.0 より前のデバイス用と、Windows Mobile 5.0 以降を実行しているデバイス用です。簡潔にするため、Windows Mobile 5.0 より前のデバイスで必要な P/Invoke は省略しました。

図 2 ITelephony の実装

class PreWindowsMobile5 : ITelephony {
  public bool supportsTelephony {
    get { return File.Exists(@"\Windows\Phone.dll"); }
  }

  public void MakeCall(string phoneNumber) {
    // call Native Phone API
  }
}

class PostWindowsMobile5 : ITelephony {
  public bool supportsTelephony   {
    get { return SystemState.PhoneRadioPresent; }
  }

  public void MakeCall(string phoneNumber) {
    Phone thePhone = new Phone();
    thePhone.Talk(phoneNumber);
  }
}

最後に、アプリケーションのコアロジックからさまざまな実装を集中化および分離する TelephonyFactory クラスを作成します (図 3 を参照)。この例では、デバイスがテレフォニーをサポートしているかどうかを認識し、サポートされていない場合には例外をスローする機能を TelephonyFactory クラスに含めることを選択しました。これで、アプリケーション内でテレフォニーを使用する場合は、単純に次のコードを実行できます。

try {
    ITelephony myTelephony = 
      TelephonyFactory.GetTelephony();
    myTelephony.MakeCall(phoneNumber);
  }
  ...

図 3 TelephoneFactory

class TelephonyFactory {
  static ITelephony _myTelephony = null;        

  public static ITelephony GetTelephony() {
    if (_myTelephony == null) {
      if (Environment.OSVersion.Version.Major >= 5)
        myTelephony = new PostWindowsMobile5();
      else
        myTelephony = new PreWindowsMobile5();
    }
    if ( ! myTelephony.supportsTelephony)
      throw(new NotImplementedException());

    return _myTelephony;
  }
}

このパターンを使用して、適応性を提供し、アプリケーションがすべての Windows Mobile デバイスで稼働することを保証する一方で、デバイス間に発生する差異を特定し、アプリケーションの更新と保守を簡単にしました。

テストとさらなる探求

優れたデザインと注意深いコーディングは、アダプタブルアプリケーション作成の 3 つの側面のうちの 2 つです。さいわい、最後の側面であるテストは、Windows Mobile SDK の一部として、またスタンドアロンパッケージで提供されているエミュレータイメージの多様性によって簡単になっています。エミュレータイメージによって、動的な回転を含め、ほとんどすべてのディスプレイ特性に対してアプリケーションをテストできます。

SDK にある追加のツールは、GPS 機能のシミュレーション、複数の種類の移動体通信ネットワーク、およびさまざまなセキュリティ構成にも対応しており、動的な機能検出と使用をテストできます。最後に、エミュレータ環境の多くは、Device Emulator Manager Automation API と Core Connectivity Framework を通じてプログラム可能なので、複数のデバイス構成のテストを自動化できます。

単一のアプリケーションが多様なデバイスをターゲットにできるプラットフォームの提供は、現在 Windows Mobile が最善のモバイル開発プラットフォームを提供している方法の 1 つにすぎません。経験豊かなベテランであるか、プラットフォームを初めて使用するかにかかわらず、Windows Mobile 開発者 Web サイト (msdn.microsoft.com/windowsmobile) に、ドキュメント、チュートリアル、およびツールが用意されています。これらは、幅広い API や高度なテクノロジと連動して、Windows Mobile 上で制限のない開発を可能にします。このコラムで説明した適応性の問題に関する追加資料と最新情報は、msdn.microsoft.com/windowsmobile/adaptyourapp で入手できます。

このコラムを着想させ、寄稿資料となった「Adapt Your App」の著者、Jim Wilson 氏 (pluralsight.com/blogs/jimw) に感謝します。