ビルドバージョンを指定する
一度リリースしたアプリを更新したい場合、バージョン情報を更新してビルドする必要があります。
アプリには2種類のバージョン番号があります。1つは人間が把握するためのバージョンで、もう1つはOS側が判断するためのバージョンです。通常、アプリを新しくリリースする場合にはどちらも更新しますが、どうしてもビルドバージョンのみ変更したい、もしくは、AndroidとiOSでは異なるビルドバージョンを設定したいこともあります。例えば、片方のプラットフォームのみプラグインを更新したい場合や、外部要因で更新が必要になったときなど、バージョン番号を細かく制御したいケースです。その場合はリスト7のようにします。
<widget id="com.coltware.cdv.SampleApp2"
version="1.0" // （1） Android、iOSのバージョン
ios-CFBundleVersion="1.0.3" // （2） iOSのみ適用するビルドバージョン
android-versionCode="10001" // （3） Androidのみ適用するビルドバージョン
（1）はAndroidとiOS共通で利用するバージョンです。（2）や（3）が指定されていない場合は、こちらのバージョン名が利用され、ビルドバージョンも同時に設定されます。そして、（2）がiOSのみ適用されるビルドバージョンで、（3）がAndroidのみ適用されるビルドバージョンです。
AndroidのビルドバージョンはAndroid側が以前指定した値よりも大きな値のほうが新しいアプリと見なします。そのため、新しいバージョンのアプリをリリースする際には、以前指定した値よりも大きくし、また、数値で指定するというルールがあります。どのような数値であっても自由に指定できますが、ビルドバージョンを指定せずにversion属性でのみ指定した場合には、リスト8のようなルールで自動的に計算されて設定されていますので、特にこだわりがなければ、同じルールで指定する事が望ましいと思います。
versionCode = MAJOR * 10000 + MINOR * 100 + PATCH
ブラウザからアプリを起動できるように指定する
ブラウザなどからURLスキームを使ってアプリを立ち上げたいことがあります。例えば、hogeというURLスキームを使う場合、リスト9のようなaタグでブラウザからアプリを起動することができます。具体的には、各プラットフォームの設定ファイルを書き換えて、これまで紹介してきた<config-file />の指定を使って行います。
<a href="hoge://">テストアプリの起動</a>
リスト10のようにconfig.xmlを設定します。
<platform name="android">
<!-- （1） Androidの場合の設定方法 -->
<config-file target="AndroidManifest.xml" parent="./application/activity" mode="add">
<!-- （2） 追記される内容 -->
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE"/>
<data android:scheme="hoge" />
</intent-filter>
</config-file>
</platform>
<platform name="ios">
<!-- （3） iOSの場合の設定方法 -->
<config-file platform="ios" target="*-Info.plist" parent="CFBundleURLTypes">
<!-- （4） 追記される内容 -->
<array>
<dict>
<key>CFBundleURLSchemes</key>
<array>
<string>hoge</string>
</array>
</dict>
</array>
</config-file>
</platform>
Androidは（1）のように設定が可能です。これは、AndroidManifest.xmlのapplication/activity要素の中に（2）の指定した記述を追記するという設定です。<intent-filter />要素以下は、AndroidManifest.xml内のルールに沿った、URLスキームでアプリを起動する方法の記述です。
今まではparent属性やmode属性を使っていませんでしたが、こちらはparent属性で指定したXPathで一致する要素内にmodeで指定できる「add」以外にも、「replace（置き換え）」や「merge（マージ）」などがあり、指定していない場合にはreplaceと同様になります。
iOSの場合は（3）のように指定します。こちらは、ネイティブプロジェクト内にある、[プロジェクト名]-Info.plistの内容の変更方法を指定していて、CFBundleURLTypesという項目に（4）で指定した内容を追記するというものです。
このように、AndroidManifest.xmlや[プロジェクト名]-Info.plistファイルをどのように編集したいかがわかっていれば、かなり自由な記述ができます。
iOSアプリの言語を日本語にする
iOSのアプリでは、デフォルトの言語は英語に設定されています。この言語設定を日本語にするにはリスト11のように設定します。
<config-file platform="ios" target="*-Info.plist" parent="CFBundleDevelopmentRegion">
<string>ja_JP</string>
</config-file>
こちらでは、以前の記事で紹介した、Xcodeでの「Localization native developmet」を"Japan"に設定したケースと同じことをしています。
アイコンやスプラッシュ画像を設定する
アプリのアイコンやスプラッシュ画像は、リスト12のように指定します。1つの画像だけでは見た目も良くないため、それぞれのサイズに合わせた画像を用意して指定することになります。サイズの指定はマニュアルのようにできますが、必要なサイズをキチンと把握するのも、さまざまなサイズを用意することも非常に面倒な作業です。
そこで、それらの画像設定を自動で行うcordova-iconとcordova-splashというツールを最後に紹介します。
<icon src="res/icon.png" /> // 共通での指定
<platform name="android">
<icon src="res/android/ldpi.png" density="ldpi" /> // Androidのサイズごとの指定
: 省略（サイズごとの指定）
<splash src="res/android/splash-land-hdpi.png" density="land-hdpi"/>
: 省略（サイズごとの指定）
</platform>
<platform name="ios">
<icon src="res/ios/icon-60@3x.png" width="180" height="180" /> // iOSのサイズごとの指定
: 省略 （サイズごとに指定）
<splash src="res/screen/ios/Default~iphone.png" width="320" height="480"/>
: 省略（サイズごとに指定）
</platform>
インストールするにはリスト13のコマンドを実行します。ここでは画像を自動でリサイズするツールとして、ImageMagickというツールを使っています。そのため、事前にこのツールをインストールする必要があります。インストール方法は、Macであればbrewなどのツールを使うのが簡単ですが、Windowsの場合は、こちらにバイナリが用意されています。
$sudo npm install cordova-icon -g $sudo npm install cordova-splash -g
アイコンを設定する場合は、プロジェクトの直下にicon.pngファイルを用意します。その際、最低192x192（px）の画像（推奨は512x512（px）の画像）を用意し、スプラッシュ画像の場合は、2208x2208（px）の画像を用意します。
画像の準備ができたら、リスト14のコマンドを実行します。すると、各サイズに対応したアイコンやスプラッシュ画像がプロジェクトに設定されます。手間もかからず、間違いも少なくなります。
$cordova-icon $cordova-splash
また、この設定に限らず、設定した内容が反映されない場合やエラーが発生するようになった際は、リスト15のように対応するプラットフォームをいったん削除してから再度追加してみてください。
$cordova platform rm android $cordova platform add android
最後に
今回、Cordovaのビルド方法のカスタマイズ方法をいろいろと紹介しましたが、このビルド設定ファイルが非常に便利なために、筆者はCordovaでないプロジェクトでもこのビルドシステムを使って管理していることがあります。その場合は、メインのActivityなども書き換えてしまいますし、必要な他のライブラリやフレームワークなどを追加で設定しています。それくらい自由度が高いのです。
今回をもってApache Cordovaの紹介は最終回となりますが、まだまだ紹介できていないプラグインもたくさん用意されています。Apache Cordovaではプラグインが自由に公開できるので、今後はますますプラグインが増えて便利なアプリが作りやすくなると思います。また、自分に合ったプラグインを探すのも楽しみの1つです。ある程度複雑なアプリになると、ネイティブ開発者と連携して自社で作成したプラグインと連携するというケースもあると思います。その際、今回の連載が少しでも皆さまの参考になれば幸いです。
