ソフトウェアエンジニアリング

ViewModelの作成（１）¶

日時を保持し、日時を通知する機能を実装する。

通知機能はモデルとビューを分離する設計では必須であり、その手段としてJetPackではDataBindingとLiveDataの2つの仕組みが提供されている。ViewModelはLiveDataと組み合わせるのが定番なようで、そちらで実装する。

import androidx.lifecycle.MutableLiveData
import androidx.lifecycle.ViewModel
import java.time.LocalDateTime

class MainViewModel : ViewModel() {
    val measuredAt: MutableLiveData<LocalDateTime> = MutableLiveData(LocalDateTime.now())
}

• ViewModelを継承
• MVVMのV（View）であるMaintActivityに対応するVM（View Model）とするので命名はVに合わせてMainViewModelとした
• V側からVMのデータを変更するユースケースがあるので、可変のMutableLiveDataを利用

ViewModelを利用するMainActivity側の追加コードは次

    override fun onCreate(savedInstanceState: Bundle?) {
        :
        val measuredAtObserver = Observer<LocalDateTime> {
            binding.textviewMainMeasuredat.text = it.format(DATE_TIME_VIEW_FORMATTER)
        }
        model.measuredAt.observe(this, measuredAtObserver)

変更通知された日時データをTextViewに所定のフォーマットで表示するオブザーバを作成し、ViewModelの日時データ（LiveData）プロパティに登録

Activityが表示されるタイミング（onResume）でViewModelの日時データを現在日時に変更する。変更が入ると上述のオブザーバーが通知を受けるので表示が変更された日時に更新される。

    override fun onResume() {
        super.onResume()
        model.measuredAt.value = LocalDateTime.now()
    }

ボタンを操作するとViewModelの日時データを変更する。

      binding.buttonMainIncminite.setOnClickListener {
            model.measuredAt.value = model.measuredAt.value?.plusMinutes(10)
        }
        binding.buttonMainDecminite.setOnClickListener {
            model.measuredAt.value = model.measuredAt.value?.minusMinutes(10)
        }

ViewModel側に増減メソッドを設けた方がよかったかも。

リポジトリとデータベース¶

JetPackでは、SQLiteデータベースのアクセスをRoomライブラリ（ORM）で行う。

Roomで検温テーブル¶

Entity、Dao、Database の責務を持つクラスをそれぞれ用意する。

まずはEntityを担うクラス。これはSQLiteテーブルのスキーマとのマッピングを表現し、このクラスのインスタンスは1行のレコードを保持する。値を表す型なので、data class としている。

• Entityクラス Temperature.kt
  

  @Entity(tableName = "Temperatures")
  data class Temperature(
      @PrimaryKey(autoGenerate = true)
      @NonNull
      var id: Long = 0L,
  
      @ColumnInfo(name = "measured_at")
      val measuredAt: LocalDateTime,
  
      @ColumnInfo(name = "measurement")
      val measurement: Float
  )
  

タイムスタンプ（日時）は、@TypeConverterメソッドを定義し、java.time.LocalDateTimeとデータベースに格納可能な型（今回はString）との相互変換を用意する。このクラスはDatabaseを担うクラスで使われる。

• LocalDateTimeConverter.kt
  

  class LocalDateTimeConverter {
      @TypeConverter
      fun fromLocalDateTime(dateTime: LocalDateTime): String {
          return dateTime.format(DateTimeFormatter.ISO_LOCAL_DATE_TIME)
      }
      @TypeConverter
      fun toLocalDateTime(dateTimeText: String): LocalDateTime {
          return LocalDateTime.parse(dateTimeText) // Default format is ISO_LOCAL_DATE_TIME
      }
  }
  

Daoインタフェースを定義する。Daoは、テーブルのCRUDインタフェース（メソッド）を表現する。
今回は最低限必要なC（Create）とR（Read）を実装する。

@Dao
interface TemperatureDao {
    @Insert
    fun insert(temperature: Temperature)
    @Query("SELECT * FROM Temperatures ORDER BY id DESC")
    fun getAllTemperatures(): LiveData<List<Temperature>>
}

Databaseの責務のクラスを生成する。RoomDatabaseを継承し、プロパティにDAOを定義すれば最低限の実装となる。
ただし、通常はシングルトンパターンで実装する（インスタンス化にコストがかかるため）。

internal const val DATABASE_FILE_NAME = "temperatures_db" 

@Database(entities = [TemperatureDao::class], version = 1)
@TypeConverters(LocalDateTimeConverter::class)
abstract class TemperatureDatabase : RoomDatabase() {
    abstract val temperatureDao: TemperatureDao

    companion object {
        @Volatile
        private var INSTANCE: TemperatureDatabase? = null

        fun getInstance(context: Context): TemperatureDatabase {
            synchronized(this) {
                var instance = INSTANCE
                if (instance == null) {
                    instance = Room.databaseBuilder(
                        context.applicationContext,
                        TemperatureDatabase::class.java,
                        DATABASE_FILE_NAME
                    ).fallbackToDestructiveMigration()
                        .build()
                    INSTANCE = instance
                }
                return instance
            }
        }
    }
}

ドメインオブジェクト v.s. エンティティクラス¶

View側（ViewModelおよびView）で扱うデータは、Roomへの依存性を持たないドメインオブジェクト（POJO）とするか、Roomのエンティティをそのまま流すか、のトレードオフが発生。

• リポジトリは永続化手段（SQLite、Realm、あるいはリモートに通信を介して）を抽象化するので、永続化手段の具象型（Entity）を扱うのは不適切では？
• ドメインモデルはRoomライブラリに依存性を持つべきでない
• 小さなプログラムでSQLiteがありきであれば、リポジトリを介す必要なくSQLite依存のままとするとコンポーネントが少なくて済む

結論は出ているなぁ。

参考記事は Android Kotlin Fundamentals: Repository
https://codelabs.developers.google.com/codelabs/kotlin-android-training-repository/#0

Android Studio 使用メモ

レイアウトXMLファイルでトップ要素をdata binding用に変更する場合（ALT+Enterで、[Convert to data binding layout]）、予めモジュールのbuild.gradleに次を記述しておく必要あり。

android {
    :
    buildFeatures {
        dataBinding true
    }
}