agri-note inside

ウォーターセル株式会社 スマート農業システム開発部のブログです。

データバインディングの観点からiOSアプリ開発にReact Nativeを選択する

モバイルチームの中川@Nkznです。

弊社では、小さなプロジェクトから、少しずつReact Nativeのプロダクション投入を試しています。

watercelldev.hatenablog.jp

DroidKaigi 2017では、2016年2Q頃にReact Nativeを選択した経緯や成果についてのお話をしました。2017年2Qのタイミングでもそれは変わらず、「できる範囲でWrite Once, Run Anywhereしたいなー」といったモチベーションで採用しています。

一方で、異なる観点からも採用のモチベーションがチーム内に生まれていることに気がついたので、紹介しようと思います。

免責事項

この観点は、チームの歴史と密接したものなので、技術の話というよりは思い出話やポエムの類になってしまうことをご了承ください*1

Androider meets ReactJS

ウォーターセルのモバイルチームは、なかなかiOSエンジニアに恵まれない時期が長かったことなどから、アグリノートのiOS版をCordovaで開発することを選択しました*2

当初はIonicでAngularによる開発を想定していたのですが、WebフロントエンドのチームがReact+Reduxを採用しているため、テクノロジを合わせたほうがノウハウを共有しやすいだろうということで、React+Reduxにmaterial-uiを組み合わせる形になりました*3

堅牢なJavaに守られながら生きてきたメンバーたちは、最初こそおっかなびっくりといった様子で慣れないES201x(Babel)に触っていましたが、ふと気づけば皆、ラムダやLodashやPromiseがないと生きていけない近代JSerな身体になっていました*4。後述しますがこれが嬉しい誤算を生み出しました。

また、当時は気づかなかったのですが、Reactの特徴のひとつである「レイアウトを表すXML(JSX)とそこに埋め込んだ変数が相互に作用する」というデータバインディングの世界観も、着々とチームに浸透していきました。

Androider meets DataBinding

さて、Cordova製iOSアプリの開発が一段落付いたら、Androidアプリのメンテにも人を戻していかないといけません。

各メンバーの中で自然と、JSやReactでの開発で出会ったパラダイムをAndroidアプリ開発にも取り入れたいという意識が高まっていました。RetrolambdaLightweight Stream APIRxJavaなどを採用する際に心理的な障壁が非常に低くなっていたのは嬉しい誤算です。この頃にはAndroidにもデータバインディングライブラリが登場しており、早い段階で採用されていました。

「複雑に状態が変わる画面を、以前はデータバインディング(React含む)無しでどうやって開発していたのか思い出せない」

こんなセリフが聞こえるようになるまで、そう長くはかかりませんでした。

iOSには(俺たちの求める)データバインディングがない

さて、そんなこんなをしているうちに、iOSネイティブ開発ができる人材の都合が付きはじめまして、新規事業のアプリを、AndroidはJava、iOSはSwift3で作ることになりました。

しかしここでつらいことが。iOSには、レイアウトに変数を埋め込むタイプのデータバインディングがないのです。React脳になっていたメンバーがアサインされていたため、非常につらそうでした。

結局、RxSwiftを使って、 myTextField.rx.text のようなObservableを起点にしたRxのストリームで連鎖的にビューを更新する方式を取りました。「違うんだ……俺が欲しかったデータバインディングはこれじゃないんだ……」という怨嗟の声が聞こえました。

iOS meets React

そして2017年春。DroidKaigiでの筆者の発表を見たり、実際に触ってみたメンバーから、こんな意見が聞こえてきました。

「iOSアプリだけでもReact Nativeで開発するのもアリなんじゃないか」

そのときは「それだと結局AndroidとiOSのUI仕様を合わせる手間がかかって、React Nativeの旨みが減るじゃないか」と突っぱねたのですが、一ヶ月ほど経って、これが実は面白い観点を含んでいたことに気がついたのです。

それは、「俺たちがやりたかったデータバインディングをiOSアプリ開発でやれる」というものでした。

どうせReact NativeでiOSアプリを開発していれば、なんだかんだとObjective-CやSwiftを書くことになります。iOS SDKを触ることになります。それはもう仕方ないのです。書くべきところはObjective-CだろうとSwiftだろうと書くしかないです。

ただ、UIだけはデータバインディングが使えるフレームワークで書かせてほしい。そういう理由だけでiOSアプリ開発に使うのも、技術選択のひとつの選択肢として、アリなのかもしれないと思いました。

まとめ

Androider上がりのエンジニアが、どうしてもInterface BuilderやStoryboardがどうしても気に食わない、レイアウトに変数を埋め込むタイプのデータバインディングを扱いたい、というモチベーションを持ってiOSアプリを開発するときには、選択肢のひとつにReact Nativeがあってもいいのでは、という提案でした。

*1:これが理由でQiitaに書くのを断念しました

*2:「素直にiOS SDK覚えなさいよ」と思われてしまいそうですが、当時は「最近はWebViewもパフォーマンス悪くないし、全部Webに寄せたら効率いいんじゃないか」というチャレンジをしてみたかったのです

*3:CSSフレームワークの美しさやTypeScriptという観点ではIonic2を使う案もあったのですが、2015年末のIonic2はプロダクションで使っていいものではなかったため、断念しました

*4:実は堅牢さについても、ESLintを厳しくしすぎてJavaより構文に厳しい環境になっていました