ハイブリッドアプリを作ってみる（4）〜CordovaとCapacitorの違い〜
ハイブリッドアプリに関してのメモ第4回。
第3回でWebアプリの状態から、ネイティブアプリに変換したり、ネイティブの機能へアクセスするために「Cordova」や「Capacitor」を使う必要があるというのをしりました。
今回は、「Cordova」や「Capacitor」について違いがどういった観点であるのかを調べていきます。
違いについて、Capacitorの公式ページに触れられているところがあります。
Capacitorは、各プラットフォーム・プロジェクトを build time asset ではなく source asset と見なします。つまり、XcodeとAndroid Studioプロジェクトをソース・コントロールに導入し、プラットフォーム固有の構成や実行/テストに必要な場合にはこれらのIDEを使用します。
すでに先行して、Ionic/React + Capacitor, Cordova でプロジェクトを作っては壊し、作っては壊しをしているのですが、不思議に感じた点がここで明記されていました。
CapacitorでiOSプロジェクトやAndroidプロジェクトを作成する手順があるのですが、その際に、 /ios /android というディレクトリが自動で生成されます。
これらは一見すると、「Webアプリから生成されたもの」＝「ビルドファイル」として、プロジェクトとしては管理しなくてよいものとも取れるのですが、
このファイルをカスタマイズする必要が出てくる事があるということもあり、きちんと管理すべき対象＝source assetとなるという事と理解しました。
実際に、starterに含まれる .gitignore に、/ios や /android は対象に入っていませんでした。
Cordovaでは、 $ cordova emulate ios というようなコマンドでデバイスをエミュレートできたそうですが、Capacitorにはないようです。
これは、一見するとデメリットのように見えるのですが、コマンドラインからiOSアプリを実行することは、Appleによって公式にはサポートされていないので、Xcodeの方が好ましいとのことです。
一応、Ionic側で、同一Wi-fiネットワークであればアプリにアクセスできる手段を用意しているようなので、Live reload的な開発ができる（・・・かもしれない）
CapacitorはCordovaとは異なる方法でプラグインを管理します。
Cordovaを触った事がないので、あまりピンとこないのですが、プラグインがソースコードに変更を加えるような影響がCordovaでは発生するという事なのかなと読み取りました。
Pluginの責務を必要最低限にする事で、設定ファイルなどは個別で対応する必要が出てくるようですが、エラーが発生しにくい・エラーの原因が特定しやすいというメリットがあるようです。
Pluginまわりは他にもお作法が違う点があるようです。
Cordovaだけで開発をやってみると実際に違いに気付けるのかもしれませんが、Capacitorから入ってしまったので、一旦上記だけ認識しておけばよいかなと思ったので、一旦仕組み的なところの調査はここまでにして、次からは実際に作ってみたときのメモを書いて行こうと思います。
