LMVC (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> にして渡して戻す必要があるという違いがある。

コメント

コメントを投稿

このブログの人気の投稿

OpenWrt での Wi-Fi 設定

イメージ
OpenWrt をインストールしたら、まず最初に手を付ける作業が Wi-Fi（Network > Wireless で該当デバイスの設定を Edit）。初期状態では Wi-Fi が無効化されているため、Wi-Fi を有効化しておかないと、有線 LAN で直結していないノート PC（Macbook）から作業できない、というのが個人的には決定的な理由。 設定自体は特に難しくはなく、大まかには 2.4G 帯と 5G 帯それぞれについて、暗号化キーを決め、SSID や周波数チャンネル、出力強度をカスタムしたりする程度。最後に Enable して Save & Apply する流れとなる。 以下では、最初に、作業用の古いノート PC（Linux）から有線 LAN でルーターに接続して設定を行い、5G 帯をアクセスポイント・モードで有効化し、Wi-Fi 経由で MacBook が接続できるようにしてから、（Linux マシンと LAN ケーブルを片付けて）残りの作業を行っている。 5G 帯のアクセスポイント設定 WZR-HP-AG300H の場合では radio1 が 5G 帯（802.11an）となっているので、この Wireless 設定を Edit する。 Device 設定（Advanced Settings） 上半分の Device 設定についてはまず Advanced Settings タブの国設定で「JP - Japan」を選ぶ。 Interface 設定（基本設定） 下半分の Interface 設定については上のスクリーンショットのように Mode を「Access Point」、ESSID を適当に設定する（ここでは「OpenWrt」としている）。 Device 設定（基本設定） 国設定を選んだので、基本設定のタブに戻る（下のスクリーンショット）。 チャンネルは auto にすると、PC（受信端末）側のアクセス可能範囲外のチャンネルが選ばれてしまう場合があるので、確実に接続できるであろうチャンネルを手動で選んでおいた方が無難だろう。出力パワーは最強にしておいた。帯域幅はデフォルトの 20 MHz 幅のまま（40 MHz にすると倍化するが、その分、他の Wi-Fi との干渉もし易くなるため）。 ...
続きを読む

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

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

和歌山（？）の女性宮司の霊能力者を特定した

イメージ
昨夜、ニンゲンTVに登場した和歌山（？）の女性宮司の霊能力者の後編が公開された。滅茶苦茶気になったので、全力で我が特定力（？）を駆使したが、今ようやく特定できた。疲れた…… orz 前編を観た段階で、原田龍二が浮遊霊にいつの間にか憑かれていたことが発覚。『神島編』以来の肩の不調の原因だったようだが、だとしたら降魔師・阿部吉宏の立場は……。 まあ、数日前、僕は阿部さんは意外と「討ち漏らし」はあるんじゃないかという説を「 ニンゲンTVのヤバい心霊映像で気分が悪くなった……（その 2） 」という記事でも述べたりしていたので、霊能力者としては「感知能力が戦闘能力よりも劣る」タイプなのかなとは思っていた。 原田のヨイショと、天野ディレクターの良くも悪くも優秀な演出・編集によって、阿部さんが完全無敵の守護神（いわばオリヴァー・カーン）のように扱われているが、世には霊能者は他にも存在し、その中で阿部さんが完全無欠なのかというとそういうわけでないと思うし、本人も結構、そのあたりは謙虚な発言をしている。だが、ニンゲンTVの番組の演出上、これまで阿部さんを他の霊能者と比較するような場面がなく、ただ、非能力者である他のメンバーから唯一絶対的な能力者存在として扱われてしまっていただけだ。 阿部さん加入前に、ニンゲンTVがコラボをしていた凄腕霊能者の山口彩さんが好例だが、阿部さんが自身で謙虚に述べているように「 上には上がいる 」というのが本当のところだと思う。ただ、そういったプロ中のプロとして活躍中の霊能者の人たちだと、廃村・廃墟といった心霊スポット巡りの撮影に参加してくれるようなフィジカル的にもタフな人材は（阿部さんを除いて他に）見つけることは難しいように思われる。 原田の亡き祖母との再会の仕方に関する回答や、霊的な世界に関する見解など、この宮司は、（一霊四魂や言霊など）神道寄りながら、かなり良い指摘の仕方をする方だったと思う。神道なのに、最後は仏教的な輪廻転生観に基いて語っていたのも印象的だった。
続きを読む