ただいま、Xamarin

色々考えた結果、Xamarinに戻ってきました。

なんだかんだ言って、良いバランスですね。やっぱり。デメリットもそれなりに目立つものの、最近は随分と改善もされてきているのをVisual Studio 2019で確認できました。

MicrosoftがReact NativeをOffice 365で使っているのが少し気に食いませんが、まぁそういう雰囲気なんでしょうな。

実際問題、盛り上がりには欠けてましたし。

ただ、新しく発表されたMobile Blazor Bindingsでは結局Xamarinなプロジェクトを生成するようになったり、徐々に本流に戻そうとしている感じもありますし、まだまだ捨てたもんじゃないかもしれませんね。

Mobile Blazor Bindingsははっきり言ってBlazor自体が極端な取り組みなので、面白くWatchしていくべきかな。とか思ってます。

なので、もう少しXamarinと戯れてみよう、と。

好きだしね。

取り組んだこととか

最近、Flutterを少しやって、次はReact Nativeをやって、と少しずつ色々作ってきました。

どちらも、実用最小限製品として動くものを完成させて、書き心地、改修の簡単さ、動作の軽快度を比べていました。

遠回りもしました。Xamarin版ではLiteDBというこれまた便利な組み込みDBを使用しているのですが、React NativeでPouchDBを使う際に、色んな事が少しずつ気に食わずSQLiteを直で使ったりしたり。

Flutterでも、SQLiteそのまま使ってます。

そのあたりはすでに公開されているプラグインを使ったりして対応出来たのですが、いくつかのどうしてもネイティブを書かざるを得ない部分が見つかり、少しばかりネイティブを書いたりしました。

というのも、私が作っているQuick Logbookは現在地の住所を表示してるんですね。

これ、AndroidのPlayのライブラリの、逆ジオコーディングAPIを直接呼んでいて、Flutter版、React Native版両方ともにネイティブのプラグインを書いたりフォークしたりしました。

クロスプラットフォーム前提のライブラリだと、Androidでのみ提供される「宛先として使用できる文字列表現にした現地語での住所」に手が回ってないんですよね。

かといって、プラットフォーム依存の返値を返却するのはクロスプラットフォームのライブラリでは好ましくないですし。

とりあえずPoCで私家版Fork作ったりしましたが、僕はこういうForkをMeanでSelfishな行為だと思ってるので、どん詰まりですね。

クロスに対応するためだけにGoogle Maps APIを呼ぶのも無駄なのと、よほど呼ばれない限り課金はされないものの、そのおそれがあるということで、出来れば避けたい。

クロスプラットフォームの宿命ですが、どうしても小回りが利かないところはあきらめるか、個別に書かざるを得ない。

作ったら作ったで今度は、活発なFlutterやReact Nativeのバージョンアップに追随しないといけなくなることは目に見えてました。

再検討

僕が本当に望んでいたものは何だったんだろう、と再度考察してみることにすると、意外でもなく、なんとまぁ無難なところに行き着きました。

・Androidに対応していれば良い

　Mac持ってない。

・コーディングをVS Codeで行いたい

　これは大きかったですが、VS 2019で少し見直したので、IDEも良いかもと思っています。

・アプリサイズを小さくしたい

　2020年、もはや誤差ですね、10Mぐらい。

・UIを簡単に作りたい

　これが一番強力な望みです。

　これを実現するために、かつてはCordova、最近はFlutterやReact Nativeを使ってみてました。

　実際問題、強力なツールとなるのですが、その分失うものもそれなりに多い事には気づいていませんでした。

　また、色々やってみたところ、CSSとSVGでエイヤと出来るWebより楽な部分はあんまり無いです。

　Xamarin.Formsよりは軽くて楽、ぐらいでしょうか。

・ネイティブAPIを気軽に呼びたい

　Cordova,Flutter,React Nativeには、気軽に呼ぶ機能はありません。

　全体的にPluginを書かないといけなくて、しかも、ネイティブ言語とJavaScript両方を用意しないといけません。

　考え方も何もかも違うインピーダンス比の高い部分なので、基本的には避けたいですね。

　このあたりから不便なところが目についてきます。

・Androidで言うホーム画面に置くWidget等を作りたい

　プラットフォームによっては、作れない、が正しい場合もあります。

総合すると

このあたりを総合して考えると、以下のような発想になりました。

画面のコントロールを抽象化するのは良いが、突き詰めるとプラットフォームの利点がほぼ全て失われる。

画面のコントロールの抽象化は、極端に難しいデザインで無い限りWebViewで良いのではないだろうか、最強の抽象化である。

また、基本的にネイティブ機能とはインピーダンスミスマッチになりがち。

どうせ乖離があるならば、いっそそういうものであると割り切って、RESTなAPIを呼ぶかの如くWebViewから、軽いラッパーを経てC#を呼び出し、AndroidのAPIを呼べば良いのではなかろうか、と。

ちなみに、Xamarin.Formsも少し考えましたが、魔窟に落ちそうだったのでもう少し様子を見ます。

逆に言うと、もう少ししたらXamarin.Formsをするかも。

そんなこと言うんなら、Kotlinで良いんじゃないの？

仰るとおりです。でも、C#で書くと、色々資産が使えるんですよね。

.netの文化圏は意外に広いのです。

ということで、しばらくはXamarinに戻ってきて、色々してみようと思います。

React Nativeを諦めた訳ではなく、適材適所で行ってみようかと。

ちなみに、ハイパーJSON色つけ係になる類いの仕事(自虐)はReact Nativeの圧勝です。