LVMC (a.k.a. MVVM) サンプル

前日の記事「Android で MVVM ならぬ“LMVC”」のサンプルコード

build.gradle (:app):

plugins {
    id 'com.android.application'
}

android {
    compileSdkVersion 30
    buildToolsVersion '30.0.3'
    defaultConfig {
        applicationId 'com.scaredeer.lvmcsample'
        minSdkVersion 26
        targetSdkVersion 30
        versionCode 1
        versionName '1.0'
    }
    compileOptions {
        sourceCompatibility 1.8
        targetCompatibility 1.8
    }
    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
    }
    buildFeatures {
        dataBinding true
    }
}

dependencies {
    implementation 'androidx.appcompat:appcompat:1.3.0'
    implementation 'com.google.android.material:material:1.4.0'

    // https://developer.android.com/jetpack/androidx/releases/lifecycle#java
    implementation 'androidx.lifecycle:lifecycle-viewmodel:2.3.1' // ViewModel
    implementation 'androidx.lifecycle:lifecycle-livedata:2.3.1' // LiveData
}

特記すべき点は buildFeatures { dataBiding true } の部分と、implementation 'androidx.lifecycle:lifecycle-viewmodel:2.3.1'、implementation 'androidx.lifecycle:lifecycle-livedata:2.3.1' の部分。かつての lifecycle-extentions は今では使えなくなっていて、完全なエラーにはならなくとも妙なバグが発生する場合があるので注意。

minSdkVersion 26 は、タイムスタンプをフォーマットするのに Java8 の新しい機能 Instant.ofEpochSecond を使ってしまっているが故に必要だったが、ViewModel や DataBiding とは何の関係もない。

main_activity.xml:

従来の layout.xml と違っている <data> </data> に注目。ここで、データをバインドするインスタンス名とそのクラスを指定している。Java のソースコードの import 宣言のようなものと考えればよい。

次に、通常のレイアウトにおいては、属性値として静的に記述されるべき場所に @{} の中にバインドしたオブジェクトとそのプロパティ名を指定する形で嵌め込む。こうすることによって、通常は XML レイアウト上に記述された属性値はコンパイル時に静的に確定されるのだが、バインドされた値の変化が動的に反映されるようになる。

従来は動的に変化させるには Java コードによって属性値にアクセスするしかなかったのが、データバインディングにより、XML レイアウト上に静的に記述した上で、Java コードによって直接属性値にアクセスすることなく、動的な変化に対応できるようになるわけである。ビューモデル内でバインドされた元の値を操作するだけでよい。

<data> </data> は実質、import 宣言のようなものだから、一旦記述してしまえば、以後は意識する必要はない。重要なのはやはり @{} の中にバインドしたオブジェクトとそのプロパティ名の部分であり、ここだけ、蛍光ペンでハイライトされた感じでコードを見る感覚がお勧め。

MainActivity.java:

package com.scaredeer.lmvcsample;

import android.os.Bundle;

import androidx.appcompat.app.AppCompatActivity;
import androidx.databinding.DataBindingUtil;
import androidx.lifecycle.ViewModelProvider;

import com.scaredeer.lmvcsample.databinding.MainActivityBinding;

public class MainActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        MainViewModel viewModel = new ViewModelProvider(this).get(MainViewModel.class);

        MainActivityBinding binding = DataBindingUtil.setContentView(this, R.layout.main_activity);
        binding.setLifecycleOwner(this);
        binding.setViewModel(viewModel);
    }
}

MainActivity でやっていることは

  1. ViewModelProvider 経由（ViewModelProvider を経由しないと、毎回 ViewModel が Activity と連動して新生されてしまい、画面回転による Activity の再生成に巻き込まれたりして、ライフサイクルの独立性を得ることができなくなる）で入手した ViewModel を用意
  2. レイアウトファイルからバインディングを生成
  3. バインディングのライフサイクルはこの MainActivity に従って（消滅・再生成等）されることを設定
  4. 用意した ViewModel をバインディングの一方の端として結び付ける

ということである（公式ガイド）。

従来の setContentView(R.layout.main_activity) はもはや不要となっていることにも注目。

Activity の記述で行うことは以上で、以上までは主に DataBinding の話である。あとは、ViewModel 側で、バインドされた各値に対してピンポイントで操作を行うコーディングスタイルとなる。ViewModel の方は、LiveData が話の主役となる。

MainViewModel.java (1/3):

package com.scaredeer.lmvcsample;

import android.view.View;

import androidx.lifecycle.LiveData;
import androidx.lifecycle.MutableLiveData;
import androidx.lifecycle.ViewModel;

import java.time.Instant;
import java.time.ZoneId;
import java.time.format.DateTimeFormatter;

public class MainViewModel extends ViewModel {
    private final MutableLiveData<String> mDatetime;
    public LiveData<String> getDatetime() {
        return mDatetime;
    }

    public MainViewModel() {
        mDatetime = new MutableLiveData<>(currentDatetime());
    }

    public void onClick(View view) {
        mDatetime.setValue(currentDatetime());
    }

    private String currentDatetime() {
        return Instant.ofEpochSecond(System.currentTimeMillis() / 1000L)
                .atZone(ZoneId.of("JST"))
                .format(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss"));
    }
}

一番素直な形が、このように getter を通じてバインドするやり方だろう。DataBiding ライブラリーが getDatetime を layout における datetime というプロパティ名と結びつけてくれる。

MainViewModel.java (2/3):

package com.scaredeer.lmvcsample;

import android.view.View;

import androidx.lifecycle.LiveData;
import androidx.lifecycle.MutableLiveData;
import androidx.lifecycle.Transformations;
import androidx.lifecycle.ViewModel;

import java.time.Instant;
import java.time.ZoneId;
import java.time.format.DateTimeFormatter;

public class MainViewModel extends ViewModel {
    private final MutableLiveData<Long> mTime;
    public LiveData<String> datetime;

    public MainViewModel() {
        mTime = new MutableLiveData<>(System.currentTimeMillis());
        datetime = Transformations.map(
                mTime,
                time -> Instant
                        .ofEpochSecond(time / 1000L)
                        .atZone(ZoneId.of("JST"))
                        .format(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss"))
        );
    }

    public void onClick(View view) {
        mTime.setValue(System.currentTimeMillis());
    }
}

ViewModel の内部では MutableLiveData として保持・操作しているが、外部公開用の LiveData と区別するため、Transformations.map を使ってこのような構成にしてみた。上流側の mTime に対する変更が Transformations.map によって下流の datetime に連動し、datetime を参照している View 側に反映される。

getter を定義せず、メンバー変数の LiveData を直接公開するスタイルにしてみると、こういう形になった。メンバー変数を直接アクセスするという点では直感的だが、反面、プライベートな MutableLiveData と公開用の LiveData の 2 本立てになるので、却ってコードが汚なくなる。冗長なだけかもしれない。しかし、ここではサンプルとして単純化した例で示しているのでこうなっているが、実用において、純粋なモデルと ViewModel との目的の違いから言って、LiveData<Long> time を Model 側で保持し、その time を ViewModel 側で LiveData<String> datetime が参照する、という 2 段構成の場合には、Transformation を使う方が実用的になることが十分に考えられる。

MainViewModel.java (3/3):

package com.scaredeer.lmvcsample;

import android.view.View;

import androidx.lifecycle.LiveData;
import androidx.lifecycle.MutableLiveData;
import androidx.lifecycle.Transformations;
import androidx.lifecycle.ViewModel;

import java.time.Instant;
import java.time.ZoneId;
import java.time.format.DateTimeFormatter;

public class MainViewModel extends ViewModel {
    private final MutableLiveData<Long> mTime;
    public LiveData<String> datetime;

    public MainViewModel() {
        mTime = new MutableLiveData<>(System.currentTimeMillis());
        datetime = Transformations.switchMap(
                mTime,
                time -> toTimestamp(time)
        );
    }

    private LiveData<String> toTimestamp(Long time) {
        String string = Instant
                .ofEpochSecond(time / 1000L)
                .atZone(ZoneId.of("JST"))
                .format(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss"));
        return new MutableLiveData<>(string);
    }

    public void onClick(View view) {
        mTime.setValue(System.currentTimeMillis());
    }
}

さらに、Transformations.map() でやったのと同じことを比較のため、Transformations.switchMap() でやるとこうなる。要するに、戻り値を LiveData<T> の中身の Type で渡せば LiveData<T> にラップされて戻される .map() に対し、.switchMap() はラップ済の LiveData<T> にして渡して戻す必要があるという違いがある。

コメント

コメントを投稿

このブログの人気の投稿

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

清水俊史さんという仏教学者（佛教大学出身）が、東大教授（花園大学卒→東大編入 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 公開であり、僕はたまたま公開
続きを読む