2012年 春期 応用情報技術者試験 問8
スマートフォンで利用するアプリケーションの設計
X社は、国内旅行を取り扱う旅行代理店である。X社では、旅行者が旅先で利用できる新たなサービスとして、スマートフォン用のアプリケーション(以下、旅先案内アプリという)と、旅先案内アプリが利用するAPIを開発することにした。
旅行者は、X社が旅行の案件ごとに割り振った案件番号を旅先案内アプリに設定することで、旅行の日程情報と近隣情報を入手し、スマートフォン上に表示させることができる。近隣情報とは、旅行先の付近にあるレストランと観光地に関する情報である。近隣情報には、リスト表示と地図表示の2種類の表示方法が用意されている。旅行者は、当日行きたい場所の近隣情報に、事前にチェックを付けておくことができる。
旅行の日程情報表示の例を図1に、近隣情報のリスト表示と地図表示の例をそれぞれ図2と図3に示す。
日程1日目 | 近隣情報 1日目 ●●県×××市△△町 |
---|---|
10:00 ○○県△△市□□町 K駅からL線で出発 | ☑ レストラン 名称:○○亭 住所:××市△△町1-2-3 電話:00-0000-0000 分類:和食、定食 |
12:00 ●●県×××市△△町 M駅で降りて近くで昼食 その後自由時間 | □ 観光地 名称:○○神社 住所:××市△△町4-5-6 電話:00-0000-1111 分類:神社 |
17:00 ●●県×××市△△町 ホテルチェックイン | |
日程2日目 | |
10:00 ●●県×××市△△町 ホテルチェックアウト |
日程情報表示では、時刻、場所及び行動予定を、旅程順にリスト形式で表示する。リストの項目をタッチすると、その項目の場所に関する近隣情報を検索してリスト表示する。
リスト表示では、各項目についてレストランか観光地かの種別、名称、住所、電話番号、分類、及びチェックの有無を示すチェックボックスが表示される。一つの近隣情報が複数の分類に当てはまる場合、分類は","で区切って並べて表示される。チェックボックスをタッチすることで、チェックの有無の状態を切り替えることができる。
リストの項目のチェックボックス以外の部分をタッチすると、地図表示に遷移する。地図表示では、リスト表示でタッチした項目と、チェックボックスにチェックのある項目に関する情報が、地図上に吹出しを使って表示される。吹出しの部分をタッチするとWebブラウザが開き、関連するWebページを参照することができる。
ネットワークへのアクセスを最小限に抑えるために、リスト表示のときに検索して入手した近隣情報は地図表示にも引き渡され、吹出しの表示に利用される。
[旅先案内アプリの開発方針]
旅先案内アプリの開発では、複数の提供元によるAPIを組み合わせることで新しいサービスを構築する、aと呼ばれる手法を用いることにした。
旅先案内アプリは、複数の情報にアクセスし、それらを組み合わせて表示する。旅先案内アプリが利用する情報と、それぞれの情報へのアクセス方法を表1に示す。
日程情報と観光地情報はX社のデータベースに保存されている。これらの情報にアクセスするAPIを新規に開発する。旅先案内アプリは、このAPIを利用して、X社のデータベースに保存されている日程情報と観光地情報を取得する。地図情報は、近隣情報の地図表示の際に、背景となる地図を表示するために用いる。Y社はレストラン情報のポータルサイトを運営する広告代理店、Z社はスマートフォン向けの地図情報ライブラリを提供するソフトウェアメーカである。
情報 | アクセス方法 |
---|---|
日程情報 | X社のAPIを用いる。 |
近隣情報 | X社のAPIを用いる。 |
Y社が一般に公開しているAPIを用いる。 | |
スマートフォンの不揮発性メモリを用いる。 | |
地図情報 | Z社が一般に公開しているAPIを用いる。 |
[レストラン情報検索のAPI]
レストラン情報の検索に用いるY社のAPIの概要を図4に示す。
(1) サービスの概要 Y社に利用者登録をすると、登録者専用のアクセスキーが発行される。発行されたアクセスキーと検索条件を指定してAPIを呼び出すと、検索結果を得ることができる。 |
(2) APIの仕様 アクセスキー、緯度、経度、及び検索半径が指定されると、その指定の範囲内にあるレストラン情報を検索し、結果を返す。検索結果には、店舗ID、店舗名称、分類、住所、電話番号、緯度、経度、及び店舗のWebページのURLが含まれる。店舗IDとは、店舗を一意に識別する文字列である。 |
(3) サービスの利用規約(抜粋) ・アクセスキーを、他の利用者に貸与したり譲渡したりしてはならない。アクセスキーを含んだいかなる形式の情報についても同じである。 ・APIを利用して作成するサービスでは、APIの実行結果を、できるだけリアルタイムに表示しなければならない。APIの実行結果をリアルタイムに表示できない場合は、APIの実行時刻を画面に表示する必要がある。 ・APIの仕様が変更された場合は、API利用者側で対応を取る必要がある。 |
[近隣情報を取得するAPIの設計]
当初は、旅先案内アプリがX社、Y社及びZ社のAPIにアクセスし、結果を組み合わせて表示する方式を考えた。しかし、レビュー時の指摘によって、旅先案内アプリはX社とZ社のAPIにだけアクセスし、Y社のAPIにはX社のAPIの内部処理からアクセスする方式に変更した。
この変更を受けて、新規に開発するX社のAPIは、X社のデータベースから検索した観光地情報と、Y社のAPIから得られたレストラン情報とを組み合わせて近隣情報を作り、結果をXML形式で返すことにした。
X社のAPIのリクエストパラメタを表2に、応答内容を表3に、応答の例を図5に示す。
なお、X社のAPIでは、位置情報は全て緯度・経度で表す。また、Y社のAPI利用時に用いるbの値はX社のAPIの内部の定数として定義しており、常にその値を用いることにする。
パラメタ | 説明 |
---|---|
id | 案件番号 |
day | 日程 1日目なら1, 2日目なら2, n日目ならn |
latitude | 近隣情報を検索する際の中心の緯度 |
longitude | 近隣情報を検索する際の中心の経度 |
radius | 近隣情報を検索する際の検索半径。単位はm。 |
要素名 | 出現回数 | 説明 |
---|---|---|
(@付きは属性名) | ||
Response | 1 | 応答結果全体を示す。 |
ViewPoint | 0以上 | 近隣情報 |
@Category | 1 | 近隣情報の種別。レストランなら0、観光地なら1 |
id | 1 | レストランなら店舗ID、観光地なら観光地ID |
name | 1 | 名称 |
property0 | 1以上 | c |
property1 | 1 | d |
property2 | 1 | e |
address | 1 | 住所 |
tel | 1 | 電話番号 |
url | 1 | WebページのURL |
<?xml version="1.0" encoding="UTF-8"?> <Response> <ViewPoint Category="0"> <id>A208</id> <name>○○亭</name> (中略) <url>http://www.example.com/index.html</url> </ViewPoint> (中略) </Response>
[プログラムの改修]
電波が届かないところでも、近隣情報のリスト表示までは操作ができるようにするために、スマートフォン内部に検索結果のコピーを保存することにした。電波が届かないところでも、検索結果のコピーがあるときにはコピーを参照して画面に表示する。
この変更に伴い、近隣情報の表示項目に変更を加えることにした。