Criteriaに指定できる条件

Criteriaに指定できる条件

前のページで述べたとおり、Criteriaは、LocationManagerのgetBestProviderメソッドに指定する引数に指定する、取得するロケーション・プロバイダの条件を格納するオブジェクトです。

Criteriaに指定できる条件は、以下の6つです。

• 位置情報の精密さ（Accuracy）
• 消費電力（PowerRequirement）
• 高度情報の要不要（AltitudeRequired）
• 速度情報の要不要（SpeedRequired）
• 方向情報の要不要（BearingRequired）
• 費用を許可するか（CostAllowed）

例えば、取得する位置情報に精密さを求めないのであれば、Criteria.ACCURACY_COARSEを指定します。すると、大まかな位置を返すロケーション・プロバイダが返ります（これは、一般的なAndroid携帯電話では、基地局情報を元に位置を計測するNETWORK_PROVIDERとなります）。

さらに、高度の情報が必要であれば、setAltitudeRequiredをtrueに設定すると、高度情報も返すロケーション・プロバイダが自動的に選択されます。

この場合は、一般的なAndroid携帯電話では、GPS衛星の情報を元に位置情報を計測するGPS_PROVIDERが選択されます。

しかし将来、GPS_PROVIDER以外で最適なロケーション・プロバイダが、もし追加された場合は、コードを変更しなくとも自動的にそちらが選択されます。

将来的な話をする上で興味深いのは、「CostAllowed」のような条件が用意されていることです。

この条件は、今のところ、true/falseのどちらであっても、得られるロケーション・プロバイダは変わりません。

　しかし、CostAllowedという選択肢が用意されていることで、将来的には、ある程度のコストを払うことでより精密な位置情報を得られるロケーション・プロバイダを、Googleやその他のサード・パーティが提供する可能性があります。

総括

いかがだったでしょうか。これまで４回にわたり、端末に依存しないアプリの開発手法を見てきました。

複数端末に対応する上で発生するであろう問題の多くが、リソース・マネージャによるリソースの自動切り替えで解決できることをお分かりいただけたかと思います。

リソース修飾子の一覧を見て、厳密に設定するのは面倒だと思う人もいるかもしれません。その意見には筆者も同感です。

リソースによる複数端末へ対応する上で肝心なのは、最初からすべての端末に対応しようとは決して考えないことです。

もちろん、ターゲット端末で正常に動作することは最低条件です。しかし、販売されているすべてのAndroid端末に対応するまでリリースしないというのは、決して上策とは言えません。

ましてや、今後発売されるであろう端末を想定して、あらゆるリソースを用意するとなると、開発をしている間にAndroidのバージョンが変わってしまう可能性もあります。

リリースの後、端末の特性に合わせたリソースを適宜追加しても、決して遅くはありません。

リソース・マネージャの仕組みは、あくまでも複数端末対応の「負荷を減らす」ためにあるのだと言うことを、決して忘れないでください。

その他の要素については、第1回の繰り返しになりますが、端末の特性や機能が「同じこと、有ること」を前提に考えるのではなく、「違うこと・無いこと」を前提に考え、それぞれのケースに対応できるようにしておきましょう。

アプリは、1度作ったら終わりではありません。常に出続ける新しい端末に適応するために、メンテナンスを重ねることになります。

アプリの複数端末への対応は、地味ですが、しかし非常に大切な作業なのです。

ここまで読んでくださった皆さま、本当にありがとうございました。

またどこかでお会いしましょう。