以前ベータ版としてリリースしていた 避難所検索@伊勢 ですが、オフラインマップ回りの問題などが解決できたので、若干手を入れて 1.0 としてリリースしました。
v1.0 リリースに関する作業で、気に合ったところをメモしておきます。
β版からの修正点
機能的な変更はほとんどありません。主な修正点としては、
- 経路検索時に現在位置が地図の中心に来るように変更
- 各種ライブラリを更新
- オフラインマップの更新確認をメニューに追加
というあたりになります。
ライブラリの更新について
今回、v1.0としてリリースするにあたり、各種ライブラリを更新しています。
Android support Library
ご存知の方も多いと思いますが、サポートライブラリはすでに非推奨になっていて、 AndroidX を使うことが推奨されています。
なので、この機に、AndroidXに移行しました。
AndroidX への移行 | Android デベロッパー | Android Developers
移行作業はトラブルもなく、上記のURLの説明通りに AndroidStudio の機能を使って作業すれば、すぐに完了しました。
Graphhopper
こちらのオフラインマップサーバーの記事でも触れたように、オフラインマップ生成時に作成する graphhopper 用ファイル(経路データ)が v1.0 から新しいものになりました。
それに伴い、クライアント側の経路検索時の処理も若干変更になっています(詳しくは graphhopper のドキュメントなどを調べてみてください)。
最初にgrahhopperを初期化する部分ですが、このアプリの場合 com.mori_soft.escape.model.GraphHopperWrapper クラスにて、初期化していますが、
0.13.0 の時は
private static GraphHopper prepareGraphHopper(Context context) { Log.d(TAG, "prepareGraphHopper"); try { GraphHopper tmp = new GraphHopper().forMobile(); tmp.load(getGraphHopperFolder(context)); return tmp; } catch (Exception e) { Log.e(TAG, "Graphhopper file load failed" , e); // 読み込みに失敗した場合は、ファイルを消去する clearGhzFiles(context); return null; } }
としていたのを 1.0 では、
// graphhopper ファイルを作成した際に config.yaml で指定した情報 // ファイルから読み込んだだけでは設定されない public static final String GH_PROFILE = "escape_by_foot"; private static final String GH_PROFILE_VEHICLE = "foot"; private static final String GH_PROFILE_WEIGHTING = "fastest"; (略) private static GraphHopper prepareGraphHopper(Context context) { Log.d(TAG, "prepareGraphHopper"); try { GraphHopper tmp = new GraphHopper().forMobile(); tmp.setProfiles(new Profile(GH_PROFILE).setVehicle(GH_PROFILE_VEHICLE).setWeighting(GH_PROFILE_WEIGHTING)); tmp.getCHPreparationHandler().setCHProfiles(new CHProfile(GH_PROFILE)); tmp.load(getGraphHopperFolder(context)); return tmp; } catch (Exception e) { Log.e(TAG, "Graphhopper file load failed" , e); // 読み込みに失敗した場合は、ファイルを消去する clearGhzFiles(context); return null; } }
のように、プロファイルを指定する必要があります。コメントにも書いてありますが、ここで指定する profile 名は graphhopper の経路データを作成する際に config.yaml に設定した profile 名になります。
また、経路検索時も 0.13.0 の時は
private PathWrapper calcPath(double lat1, double lon1, double lat2, double lon2) { GHRequest req = new GHRequest(lat1, lon1, lat2, lon2).setAlgorithm(Parameters.Algorithms.DIJKSTRA_BI); // TODO アルゴリズム req.getHints().put(Parameters.Routing.INSTRUCTIONS, "false");
のように呼び出していたところが、
private ResponsePath calcPath(double lat1, double lon1, double lat2, double lon2) { GHRequest req = new GHRequest(lat1, lon1, lat2, lon2).setProfile(GraphHopperWrapper.GH_PROFILE); req.getHints().putObject(Parameters.Routing.INSTRUCTIONS, "false");
のように、profile 名を追加で指定する必要がありました。
これは勝手な推測なのですが、たぶん、経路データ作成時は、いくつかのパターンで経路データ(それらを区別するために profile 名を与えます)を作成し、初期化時および経路検索時に、どれを使うか指定するような使い方になったように思えます。
また、そのほかに、経路検索結果を扱っていた PathWrapper クラスの名前が、 ResponsePath に代わっていたりします。
そのあたりを修正することで v1.0 で動作するようになりました。
Play App Signing
ライブラリではありませんが、今回のリリースに合わせて、 Play App Signing を使うようにしました。
ポイントになるのは、今までは単にアプリに署名して Google Play にアップロードしていたものが、Play App Signing では、
- アプリを公開する際の署名鍵(アプリ署名鍵)
- アプリを Google Play にアップロードする際に署名する鍵(アップロード鍵)
の2つの鍵が必要になるという点です。
で、既存アプリの場合は、開発者の手元にあるキーストアを使って署名して公開している(はずな)ので、これを Play App Signing のアプリ署名鍵として登録してやる必要がある、というのがポイントになります(アプリ公開時の鍵は変更できませんからね)。
そのうえで、別途、アップロード鍵を用意して、それで署名したアプリを Google Play にアップロードする、という形になります。なお、このアップロード鍵はアプリ署名鍵と同一でもよいらしいのですが、せっかく Play App Signing を使うなら分けたほうが無難かと思います。
Google への連絡が必要ですが、アップロード鍵は交換することも可能ですからね。
上記の点だけ理解しておけば、実際の作業は詳しいドキュメントも公開されているので、それに従って作業するだけです。
最後に
最初のβ版リリースからずいぶんと時間が経ちましたが、ある程度形になったかと思います。 まだ、避難所情報の更新がおこなえないので、その機能だけおいおい追加したいと思います。
その他、気になる点などありましたら、ご意見いただければと思います。