Android で MVVM ならぬ“LMVC”

MVC と MVVM（参考：2015年に備えて知っておきたいリアクティブアーキテクチャの潮流）の比較：

やはり、MVC の場合と MVVM の場合で、Model の意味合いが変っており、MVVM の方の M は基本的にもう Model と呼ぶべきものではないものとなっていると思う。

MVVMPattern

基本的にプレゼンテーション層とデータ・ビジネスロジック層を分けるという観点で全体を階層化させているわけだから、MVC のように、入力と出力を分けるという観点とは根本的に異っている。MVC の場合は、入力を抽象化して内部データ化するという処理の部分と、内部データを具象化して出力するという処理の部分を交錯させないで分離するという観点で、その抽象化された内部データの属する部分を Model と呼んでいるわけだ。

なので、MVC と MVVM で名称的に共通するのは View だけであり、Model 部分は紛らわしいので、別のネーミングにすべきではなかったかと思う。むしろ、ViewModel の部分の方が、View にとっての抽象化されたデータの参照元（Model of View となる部分）としての意味で ViewModel と呼ぶのは、まだ理解しうる。Model の方は Model と呼ばずに、Logic などと名付けて LVVM とでもすべきではなかったのだろうか（LVVM では別のタームと被ってしまうから、ViewModel の方をこそ Model と呼んで、LMV (Logic-Model-View) とか LMVC (Logic-Model-ViewControl) でもいいんじゃないかと思う）。

なので以下、敢えて LMVC の用語で行こうと思うが、Logic 層と ViewControl 層の両者の中間に Model 層（俗に言う ViewModel）を設ける意義は、処理の時系列的な連動性を断ち、時間的なバッファを設けることが可能となるからだと思う。ネットワークの非同期処理などを抱える Logic 層、Activity のライフサイクルなどによって頻繁にアプリ外の都合と要因で破棄・再生成されるライフサイクルを持つ ViewControl 層で、それぞれが所属する時間の流れ、ライフサイクルの様相が大きく食い違っており、この異なるフェイズが混じり合うことないように分離するには、中間にこのような Model 層を設けてバッファとするわけである。

例えるならば、コンビニエンスストアーやスーパーストアーでの、バックヤードに相当するのが Model 層である。Logic 層に相当するのはロジスティック（問屋・運送）関係者で、彼らは店頭の事情など気にすることなく、バックヤードに運び込むことだけを考えればいいし、一方、ViewControl 層に相当する店頭に立つ販売員は、バックヤードから適宜店頭の棚に商品を補充すればよい。

LMVC 以前の従来の Logic 層と ViewControl 層が分離されておらず互いに混じり合ってしまっている状況（Activity / Fragment にネットワークロジックなども記述している状態）は、例えるならば、店頭の棚に運送業者が直接納入するので、店頭の棚の事情によって、運送業者がせっかく運んできた品物を持ち帰らされて再配達を余儀なくされたり、運送業者の納入を待って販売員が客の相手をできなかったりといったギクシャクした運営状態で例えられるだろう。

Model 層の存在・設置意義（わざわざ従来の Logic や ViewControl から分離・独立させて設ける意味）はまずはそういったことになる。

そして、一旦 Model 層を設けることについての議論が終ったならば、次は Logic 層や ViewControl 層との関係性についてである。

まず、Model 層と ViewControl 層の間の関係としては、LiveData が登場する。ViewControl 層は Android で言うところの Activity / Fragment に相当するものであり、それ自体は本来、処理としては比較的複雑・大規模なものである。通常の Model のデータを参照して、それを元に ViewControl を再構築するとなると、コードがその分、肥大化する。LiveData の場合は、画面の中の一部の文字列だけ、Model のデータの変化に応じて描き変えたいといったような場合に、関数型プログラミング的なアプローチでコードを記述することが可能になる。関数型プログラミングでは、関数を記述することに主眼があり、「再度変数に代入し直す」という手続処理的な記述（ボイラープレートコード化すること）を回避できる。LiveData によって、このような明示的な再代入手続をコードの記述上、避けることができるのである（API 側が裏側でやってくれる）。

つまり、Model に対する ViewControl の処理は、LiveData によってかなりスッキリと記述できるようになるわけである。Model の該当する変数の変化を ViewControl に暗黙的に反映できるようになる。一旦、ViewControl をそのように定義しておけば、あとは Model のデータを操作することだけにプログラマーの意識が集中できるような記述になるわけである。

また実際、水面下では、コールバックなどを通じて Model 側から Observer である ViewControl へ通知されるという仕組みになっているものと思われるが、コールバックというものが Observe したい側ではなく、Observe される側の Model 側から行うというところがミソで、これが非同期プログラミングの問題の温床となっている。Observe したい側の ViewControl が停止・破棄されてしまうと、Model 側が通知しようとするその通知先である ViewControl へのポインターが null となり、NullPointerException が発生するわけである。なので、ViewControl 側では、ライフサイクルにおける終了時に必ず、Observer 登録を解除する処理を記述せねばならず、これまた典型的なボイラープレートコードとなるわけだ。これらのボイラープレート処理が、LiveData の場合はライフサイクル面を考慮して API 側が面倒を見てくれて記述する必要がなくなるので、大いに助かるわけである。

ちなみに、DataBinding は ViewControl から一部のパラメーター（変数）を抜き出して、Model の変数として連関させて、ViewControl のオブジェクトを意識しないでも、直接各パラメーターにアクセスできるようにする感じでコードを記述できるという、あくまでも「記述上の」便宜に過ぎないと考えるといいだろう。LMVC 的な構成論とは直接関係のない話題（むしろ関数型プログラミング的な話題）と言うことができる。

次に、Logic と Model の関係も、Model と ViewControl の関係と同様に考えることができる。非同期でタイミングを確定できない Logic のデータを、LiveData として定義し、Model 側から Observe する関係として設計する。こうすることによって、例えばアプリケーションの終了と共に Model は ViewControl と共に停止・消滅するがそのライフサイクルによって後に非同期処理が Model へコールバックを試みることで NullPointerException につながるようなことを、LiveData を介在した Observe 設計によって防止できるわけである。

最後に、以上のようにして、Logic-Model-ViewControl で互いのライフサイクルが絡み合うことないように分離したのに、それを台無しにしかねないのが、ライフサイクルのより長い、Model 側で ViewControl (Activity / Fragment) のインスタンスへのポインターを保持したり、Logic 側で Model のインスタンスへのポインターを保持したりするような真似である。これは特に LMVC 的な話題としてではなくとも、Android のライフサイクルの関係する話題で随所に出てくる話である。要するにガーベージコレクションを妨げ、メモリーリークするので、避けなければならない。

また最後に付け加えるならば、Model（Android では ViewModel クラスの派生オブジェクトに相当）に Logic を埋め込んで統合せず、分けることを Google 公式が推奨する理由は、Logic については「concern 毎にクラスを分けるべき」というプログラミングの一般論的なポリシーによる。特に LMVC (MVVM) 固有の次元の話ではない。

以上のように、関数型プログラミング的なコーディング表現を導入することで、ViewControl や Model が「静的に」デザインできるという部分が大きいと思う。「動的（ダイナミック）」な部分、手続的処理を記述する部分や非同期的処理部分を各 Logic として隔離でき、全体を統合する Model や ViewControl の部分は静的に平面的なものとして記述できるようになる。これらの静的な部分と動的な部分を混じり合わないように分離して、かつ橋渡しするためのものが LiveData や DataBinding、ViewModel といった手法というわけだ。

コメント

コメントを投稿

このブログの人気の投稿

清水俊史『上座部仏教における聖典論の研究』

清水俊史さんという仏教学者（佛教大学出身）が、東大教授（花園大学卒→東大編入 or 再入学？）の馬場紀寿氏と論争の末、アカハラ被害に遭い、さらには出版妨害に遭った（参考： 日本テーラワーダ仏教教会 事務局長 佐藤哲朗さんの YouTube 動画 ）という、問題作であるこの本を読んだ。 佐藤さんが紹介している Amazon の書評リンク にもある通り、この清水さんの本は、馬場氏の（今の東大教授としての地位へとつながる博士論文を母体とした）デビュー作『上座部仏教の思想形成――ブッダからブッダゴーサへ』の内容を完全否定するものである。 主に、清水さんの本の 3 部構成のうちの第 1 部がそれ（馬場説の完全否定劇）に該当する。 総括 第 1 部では、ブッダゴーサやダンマパーラに帰せられる著作群を主な材料として、小部の成立を軸とした三蔵の形成過程を考察した。以上をまとめれば、仏滅後からブッダゴーサを経てダンマパーラに至るまでに、三蔵は次のような段階を経て成立したと推定される。 仏滅後に残された様々な教えは、仏弟子たちによって、その内容に応じて律蔵と『長部』『中部』『相応部』『増支部』という経蔵四部とに収められ、僧団内にいる長部誦者や持律師と呼ばれる専門家たちがこれを伝承していった。この律蔵・四部から漏れた様々な種類の経典（主に偈頌経典）は、他の四部に比してより在家的・通俗的な蔵外文献として伝承され、『ジャータカ』と『ダンマパダ』の例外を除いて専門の誦者や伝持者は僧団内に存在しなかった。 これら四部の外側に累積していった蔵外文献（主に偈頌経典）は、 後に経蔵の第五部「小部」として三蔵内に組み込まれるが、経蔵が五部に再編成された後も小部の構成は固定的ではなく流動的であった。そのため、小部のうちには、成立が早いとされる『スッタニパータ』『ダンマパダ』といった韻文経典のみならず、成立が遅いと考えられ る『義釈』『無礙解道』といった教理書も収められている。このような編纂事情ゆえに、上座部における小部の伝持形態は、「小部」というーまとまりのセットで伝持するという意識が希薄であり、各々の文献単位で別個に伝持されていった。 また、小部の成立だけでなく、阿毘達磨蔵七書と律蔵附随の成立も遅いことが考えられるが、これら小部・阿毘達磨蔵・律蔵附随の成立の具体的な先後関係は不明であ
続きを読む

シークエンスパパともの先見の明

イメージ
先日、シンクロニシティ的に、故・シークエンスパパともが 2 年前に行った未解決事件に対する霊視が、ギャル霊媒師飯塚唯氏が最近行った霊視と、互いに補完し合うような内容であるということを ブログに 認 したた めた ばかりである。 ところで、さらにもう一つの、パパともの霊能力に関する（僕にとって）シンクロニシティ的なタイミングで到来した情報が発生した。 シークエンスはやとものチャンネルの動画などを観るようになったのがきっかけで、YouTube のお勧めに、オカルト系のチャンネルが多数表示されるようになってきたのだが、その一つに「都市ボーイズ」という都市伝説を中心としたオカルト系チャンネルがあった。こういうものを観だしたらキリがないので、基本はスルーしていたのだが、その都市ボーイズ（放送作家の岸本誠と早瀬康広のコンビ）がチャンネルにはやともがゲストで出演して生霊鑑定を行っていたのを観たので、そこから芋蔓式に都市ボーイズのチャンネルの動画も何本か観たりするようになった。 都市ボーイズはやせの黒魔術 当初は、はやせ（早瀬康広）に「黒い呪いのようなものがまとわりついている」という、はやともの生霊鑑定の結果を深掘りすべく、関連する動画を追った。はやせは、呪物コレクターであり、その上、最近（約 10 ヶ月前に公開された動画）、「呪いを飼い馴らして、黒魔術的な力を自分のものにする」という修行というか通過儀礼を行っていたというのである。 儀式を無事に終えて台湾系の呪術師に合格が認められたはやせは、「数年以内に自動的に能力が開花し、自分で自覚するだろう」と言われたという。 都市ボーイズはやせを怒らせた霊能者 そのようなはやせを擁する都市ボーイズだが、先日、「【テレビの闇】インチキ霊能力者にテレビ出演邪魔されました！【インチキ霊能者】」という刺激的なタイトルの動画が、たまたま僕が暇だった時、公開されたばかりのタイミングで見つけてしまったので、早速その動画を観た。 約 1 年前、とある霊能者の霊的な〝脅迫〟によって、はやせはテレビ出演を直前で降板させられてしまったそうである。 僕は、テレビは観なくなって久しい人間で、それこそ霊能者というとシークエンスはやともの言う「心霊第 3 世代」の宜保愛子で止まっていて、江原啓之ですら雑誌の見出しで名前を知っ
続きを読む

シークエンスパパとも 本物の霊能力

イメージ
シークエンスはやともを知ったきっかけ TV を見ない僕がシークエンスはやとも（YouTuber。吉本興業所属）の存在を知ったのは、今年の春（3 月か 4 月）の頃だったと思うが、YouTube でふと宜保愛子の動画を探していて、彼が宜保愛子を称賛するものを見つけて以来だったと思う。 それ以来いくつかの彼の動画をちょくちょく観るようになって、彼の霊能力が父親（シークエンスパパとも）譲りであり、パパともも息子のはやともに勧められて（癌闘病の傍ら）YouTuber として活躍していたのだが、残念ながら今年 1 月末に逝去していた、ということなどを知るようになった。 シークエンスパパともを知ったきっかけ はやとも流れでパパともの動画を観るきっかけになったのは、画面脇のお勧めに出ていた親子対談の動画を見たのが切っ掛けだった。 そこでのパパともの宮本武蔵に関するコメント（「晩年の宮本武蔵は一生懸命仏像を彫ったりしていたが、（若い頃）子供の道場主を殺したりしていたことによる怨霊は除霊できなかった」）に少しシビれた。息子のはやともが、まだ若いせいもあって、ちょっと話がマクロな（思想論や社会論的な）方向に行くと、厨二病的な傾向があるのには食傷気味な感じがあった。一方で、パパともの宗教・倫理観的な考えの方がその点、人間的な深さを感じるものがあったので、それがパパともに興味を引かれたきっかけだった。 パパともの霊能力に衝撃を受けた理由 そこで、初めて、パパとものチャンネルの動画もいくつか観たりしたのだが、「未解決事件を霊視する」という中々に攻めた企画を初期にやっていて興味深かったのだが、中に、上野の不忍池での事件（僕自身はこの 2006 年の事件については知らなかった）を扱ったものがあった： 「あっ！」と思ったのが、奇しくも前日（2023-06-28）、全く別のチャンネルの別の動画で、霊媒師が同じ事件を霊視するという企画のものを観ていたのだった： 千原せいじの YouTube チャンネルで、彼がコラボをしている飯島唯という通称・ギャル霊媒師の方が霊視をしている。 パパともの動画は 2021-05-12 と 2021-05-15 に公開されたものであるのに対し、ギャル霊媒師の動画は 2023-06-28 公開であり、僕はたまたま公開
続きを読む