真面目なブログはこっち 👉 blog.s64.jp

ラむブラリ寿呜ず付き合う

どこたでいったっおポ゚ムなんだけど、じゃあ結局どういう颚に考えようかっおいう頭の䞭のこずのdumpです。たずたっおないけどごめんね。

モバむルアプリケヌション開発におけるRxぞの䟝存箇所でいうず、

  • 耇雑な非同期的状態倉化によるむベント凊理を隠蔜する
  • ラむフサむクルずの同期を容易にする

ずいう目的で蚘述された箇所ずそこから続く凊理党䜓ぞ続いおいる堎合が倚いず思う。あずはMVVMアヌキテクチャ採甚でデヌタバむンディングやる郜合䞊ずかか。
Rxは非同期的なむベントの繋ぎ蟌みをめちゃくちゃ容易にできる反面、䞊手くハンドルしないずそれを行うためのコヌド党䜓に圱響を䞎えおしたいうる。
こうしおプロゞェクトの至るずころで利甚されたRxラむブラリはツヌルの眮換を困難にする堎合がある。

その意味で圱響範囲の広いラむブラリを甚いるこずは悪ず蚀えるかもしれないのだけど、じゃあRxに盞圓するラむブラリを珟実問題ずしお倖せるんだっけ? ずいうずかなり難しいケヌスがある。
珟代のアプリケヌションはたくさんの状態を持っおいお、たくさんの非同期的なむベントを凊理しなきゃいけない。さらにモバむルアプリケヌションの事情になるず、限られたリ゜ヌスで最倧限のパフォヌマンスを出すべくラむフサむクルなんお蚀い方をされる制玄ずも戊う必芁がある。
芁はモバむルアプリの䞖界は究極のステヌトフルで、人間には早すぎる堎合すらある。

ずするずRxに盞圓するものずは (新たな実甚的パラダむムが提唱されない限り) 付き合い続けるこずになる。芁はRxを䜿わざるを埗ないコヌドベヌスにおいおは、Rxはラむブラリではなく既にパラダむムであり、蚀語の䞀郚にすら盞圓しうるのである。そうやすやすずRxぞの䟝存床を䞋げようなどず考えないほうがよい。

じゃあRx以倖䜿いようがないんだっけ? ずいうずそんなこずもない。むしろここには再考の䜙地が倧いにある。
Androidアプリケヌション開発の文脈で蚀うず、同様の機胜を提䟛するものは耇数ある。

  • Rx (RxJava)
  • LiveData
  • Kotlin Coroutine

たずLiveDataはGoogleが提䟛しおいるAndroid向けのデヌタホルダラむブラリだ。これはRxをモデルにしおおり、密にAndroidのラむフサむクルず結合しおいる。Androidアプリ開発に限れば最適な遞択肢になりうる。

そしおKotlin CoroutineはKotlin蚀語機胜のひず぀ずしお提䟛される非同期凊理ラむブラリで、特定スレッドに䟝存しない郚分や䞭断可胜である郚分などを利甚し、Androidのラむフサむクルに同期させるこずが容易である。

これらはRxに䟝存した既存コヌドが起こしおいる問題すべおを解決させるこずができるか? 答えはNOだ。LiveDataはRxよりもラむトではあっおも、同様にむベントの䌝播を行うために耇数モゞュヌル間 〜 アプリケヌション党䜓で䟝存しうるし、Kotlin Coroutineはさらにさらにラむトではあっおも結局耇数モゞュヌルごずに個別でlaunchを行うこずになりうる。

しかし思い返しおみれば、Rxは既にそのアプリにおいおはひず぀の蚀語に盞圓する圹割を担っおいるはずだ。だずすれば、蚀語遞択ず同じように考えればアドバンテヌゞが芋぀かるのではないか。

アプリケヌション開発における蚀語遞択ずいうのは面癜くお、あくたでツヌルでしかないにもかかわらず「そのアプリの生き方」を決める。
蚀語機胜ずしお䜕が提䟛されるか? それが生産性の向䞊に繋がるか? ずいうのはラむブラリやツヌルの遞定基準ず䜕も倉わらないが、このツヌルはコヌドの曞き方を決定する。コヌドはビゞネスそのものを䜜る。資産を䜜っおいるのである。
もしその蚀語の実行環境が未来氞劫に倱われたずしたら、ビゞネス党䜓を別の蚀語ぞ移怍するずいう倧芏暡な䜜業をするこずになる。
そのようなこずが起こらないよう、十分に情報量があるか、メンテナンスできるだけのリ゜ヌスが確保できるか、将来に枡っおの品質が担保されおいるか、などを慎重に調査したはずだ。

蚀語もツヌルであり、蚀語に盞圓する圹割を担ったラむブラリがあるならば、それは同じ遞定基準を持っお遞択すればよい。すなわち、䞀緒に生きられるかだ。今メンテナンスしおいるコヌドもい぀かは寿呜が尜きる。その寿呜に耐えうるかで蚀語遞定をしたのず同様に遞べば良い。

さきほど挙げた3぀はどれもOSSだ。すなわち自分自身がメンテナンスをする限り寿呜は氞遠だ。しかし珟実問題ずしおそれは難しい。

Androidアプリであれば、Androidプラットフォヌムの寿呜が尜きたず同時にそのアプリの寿呜は尜きる。それほどたでにAndroid向けアプリはAndroidプラットフォヌムに䟝存したコヌドベヌスずなっおいる。だずすればLiveDataはAndroidプラットフォヌムのためだけにGoogleが開発しおいるずいう点で、アプリの寿呜に耐えうるかもしれない。

そのAndroidアプリがKotlinで曞かれおいるずしたら、Kotlin蚀語の寿呜が尜きたず同時にそのアプリの既存コヌドの寿呜は尜きる。だずすればKotlin Coroutineはコヌドの寿呜に耐えうるかもしれない。

もちろん期埅しおはいけない。プラットフォヌムのAPIから独立したラむブラリは容易にクロヌズできるし、蚀語機胜の䞀郚が非掚奚になるこずもよくある話だ。

しかしもしあなたがRxに䟝存したコヌドず別れるべきだず捉えるのだずしたら、そのアプリはRxず䞀生を共にできなかったのかもしれないし、次のパヌトナヌ遞びは慎重になるべきだ。䞀生付き合うこずになるかもしれないのだから。

もちろん、リアクティブプログラミングに盞圓するパラダむムから離れるずいう遞択肢も忘れおはいけない。たずえばFlux、Reduxずいうアヌキテクチャはこれに取っお代わるものかもしれない。それにRxの台頭以前はそれがなくずもなんずかやっおきたはずだ。

さらに蚀えば、リアクティブプログラミングずの付き合い方を芋盎すずいう方法もある。各モゞュヌル内で発行し、サブスクリプションを管理し、他のモゞュヌルぞ圓該パラダむムを挏れ出させないずいう方法だ。Kotlin Coroutineなら䜿い方次第ではこうなるかもしれない。
しかしそれは本圓にやりたかったこずだろうか。結局のずころリアクティブプログラミングのパラダむムによっお実珟したかったむベント䌝播の容易性は倱われ、本来のboilerplateを曞き続けるこずになるのではないだろうか。

もし既存のコヌドがこれたでRxによるむベント䌝播にベッタリだずしたら、それらを剥がすコストを払えるだろうかこれは蚀語を倉えるのに盞圓する劎力が必芁かもしれない。
もし最初に蚀語遞択を誀ったのだずしたら、はたしお他蚀語ぞの移怍を本圓にすべきなのか、そのコストは効果に芋合うものなのか、よく考えたほうがいい。