Takuji->find;

株式会社はてなでアプリケーションエンジニアやってます、技術的な記事を書いているつもり

Architecture Components ViewModelをAutoDisposeに対応させる。

※ これはtakuji31 Advent Calendar 2018、1日目(相当)の記事です。

adventar.org

ViewModel

ViewModelは我々Androidアプリエンジニアの生活になくてはならないコンポーネントの一つである。

AndroidのActivityのインスタンス単体のライフサイクルは特定の画面のライフサイクルより短く、画面回転やメモリー不足で簡単に消される。

だが通信などの非同期処理は画面を完全に抜け出すまでやっていてほしいし、データも保持されてほしく、そういう時にViewModelを使う。

使い方は公式ドキュメントを見てほしい。

developer.android.com

AutoDispose

AutoDisposeはUberが公開しているRxJava2のDisposableを自動的にdisposeするライブラリーである。

大半の処理は実行を指示したライフサイクルに対応するライフサイクルで処理をキャンセル(createならdestroy、resumeならpause)したいものである。

これをいい感じに自動的にやってくれるライブラリーがAutoDisposeだ。

1.0.0でandroidxにも対応していて安心。

github.com

使い方は簡単でRxJavaのObservableやSingleをsubscribeする前に

observable
  .autoDisposable(scope())
  .subscribe()

などとしてやるだけである。

これだけで現在の状態に対応したライフサイクルイベントが起きた時にdisposeされる。

ViewModelをAutoDisposeに対応させる

AutoDisposeには ScopeProvider というinterfaceがあり、これを使うと今のスコープをAutoDisposeに知らせることができる。

ScopeProvider#requestScopeCompletableSource を返せばこれが完了した時に Disposable がdisposeされる。

FragmentActivity といった LifecycleOwnerScopeProvider を継承した LifecycleScopeProvider (を実装した AndroidLifecycleScopeProvider) によってAndroidのActivityやFragmentのライフサイクルに応じたスコープを返すようになっている。

一方でViewModelはonClearedという単一のライフサイクルメソッドを持っている。

AutoDisposeで管理されるViewModel内のDisposableは全て onCleared が呼ばれた時に破棄されてほしい。

なので ScopeProvider を実装して onCleared が呼ばれた時に完了する CompletableSource を返すようにしてやればよい。

abstract class BaseViewModel : ViewModel(), ScopeProvider {
  private val onClearedSubject = CompletableSubject.create();

  override fun requestScope() : CompletableSource = onClearedSubject

  @CallSuper
  override fun onCleared() {
    onClearedSubject.onComplete()
  }
}

class HogeViewModel: BaseViewModel() {
  init {
    observable
      .autoDisposable(this)
      .subscribe()
  }
}

最後に

明日も何か書きます。

ThreeTen BackportのInstant.plus(long, TemporalUnit)は年を足せない

Androiderならきっとみんな大好きなはずのThreeTen Backportに関しての雑メモ。

今から100年後のInstantが欲しくなって Instant.now().plus(100, ChronoUnit.YEARS) ってやってみたけど UnsupportedTemporalTypeException で死んだ。

コードを読んでみると ChronoUnit.YEARS はサポートされていなくて以下の ChronoUnit しか使えなかった。

  • NANOS
  • MICROS
  • MILLIS
  • SECONDS
  • HOURS
  • HALF_DAYS
  • DAYS

月と年の計算は曖昧な部分(うるう年とか)があるからサポートできないのだろうか。

とりあえず厳格に100年後が欲しかったわけじゃないので plus(36500, ChronoUnit.DAYS) でなんとかすることにした。

問題のコードはこの辺り↓

https://github.com/ThreeTen/threetenbp/blob/9233702f6905c3b172f57fcda3fc278ad1542cac/src/main/java/org/threeten/bp/Instant.java#L710

RecyclerView.ItemDecorationでgetItemOffsetsの値を変えた時、レイアウトはどう動くか

雑なメモ

RecyclerView.ItemDecoration を使ってitemのoffset(bottom)を調整する機会があった。

ある位置を基準にしつつ、offsetを調整+スクロールして基準位置にあったitemが同じ位置に見えている必要があったのだが、なぜかズレる。

よく見てみたら見えている一番上のitemの位置が動かず、下にズレているのだ。

どうやら今見えている一番上のitemを基準にレイアウトが決定されるようだった。

仕方がないので基準位置より上にあるViewのoffsetを計算してその分だけスクロールすることにした。

lateinitの行儀の良い使い方

以前勉強会で「KotlinのlateinitDelegates.notNull()の使い分けがよく分からない」というお話をいただいた時に"基本的にはDelegates.notNull()を使うべきではないか?" と答えたしそれより前から最近もずっと思っていたのだが、(DroidKaigiの発表を聞くなどする感じ)どうも違うのではないかと思えてきた。

そのため、ここでlateinitの仕様について整理しつつ、そこから導き出される行儀の良い使い方を考察する。

結論

  • kaptを利用してJavaのコードからフィールドを操作したい場合はlateinitを使うべき
    • フィールドが露出すると不都合がある場合はDelegates.notNull()を使うべき
  • lateinitを普通に遅延初期化目的で使うならprivateで使うべき
  • 遅延初期化するが、タイミングは最初にアクセスされた時でよい&変更されないならlazyで十分
  • 小さなオブジェクトが大量に生成されると困るくらいパフォーマンスを気にする部分ではlateinitを使うとよい

lateinitとは

KotlinでNonNullなプロパティーの初期化をconstructorより後に遅らせられる機能。

元々はkaptで(例えば)Dagger2からインスタンスをプロパティーに直接代入できない、みたいなことを解決するアプローチとして追加された。

blog.jetbrains.com

lateinitの使い方

lateinit をプロパティー定義の前に書く。

lateinit var viewModel: HogeViewModel

fun onCreate(savedInstanceState: Bundle?) {
   // DI
   component.inject(this)

   viewModel.fuga // インスタンスにアクセスできる
}

制約

  • valには使えない(以前は使えたが今は使えない)
  • Nullableには使えない
  • プリミティブ型には使えない
  • 使うことでJavaからはそのプロパティーのfieldがプロパティーと同じvisibilityで見える
    • private 以外にすると外から見える可能性がある → 意図しない使い方になる可能性

Delegates.notNull() との違い

  • lateinitDelegateオブジェクトが作られないので、大量に使う場合にパフォーマンス的に有利
  • Delegates.notNull() はプリミティブ型にも使える

lazyとの違い

  • lazyは値をsetできない(1回限りの遅延初期化)
  • lazyはNullableでも使える

最後に

意外とlateinitもっとカジュアルに使ってもいいのかもしれない。

KotlinのSealed Classを使いこなす

こんにちは、三度の飯よりKotlinが好きな id:takuji31 です。

※ これは、はてなエンジニア Advent Calendar 2017 7日目の記事です。6日目は id:hayajo_77 さんの「Webオペレーションエンジニアとし研修して1ヶ月経ちました」でした。

hayajo.hatenablog.jp

今日は私が愛してやまないKotlinのSealed Classの使い方について紹介します。

Sealed Classについて

Sealed Classとは継承を制限して、階層を明確にできるクラスです。

詳しくは公式ドキュメントを参照してください。

Sealed Classes - Kotlin Programming Language

もう少し分かりやすく言うと、1つのファイル内でだけ継承できるクラスです。

Sealed Classを使う利点

普通の(final or open)クラスと比べて

外部からの継承を制限できるので、コンパイル時に子クラスの階層が全て明らかになります。

これで何ができるかというと、when式とis演算子の組み合わせで網羅性のチェックができます。

例えば下のコードのように、通常の A を継承する B/C/D というクラスがある時に

open class A
class B : A()
class C : A()
class D : A()

このAの子クラスのインスタンスがどのクラスか判定して何か値を返す関数は

fun isSomething(obj : A) : Boolean {
  return when (obj) {
    is B -> true
    is C -> true
    is D -> false
  }
}

と書くとコンパイルエラーになる(B/C/D以外の可能性がないことを判別できない)ので、以下のように書くと思います。

fun isSomething(obj : A) : Boolean {
  return when (obj) {
    is B -> true
    is C -> true
    is D -> false
    else -> throw RuntimeException("Not reached!!!!")
  }
}

elseは(自分達が書いているコード的には)絶対通らないはずだけど、例外を投げるか何らかの値を返す必要があります。

もちろんこのコードがライブラリーにあったとして、利用者がAを継承したEというクラスを作って渡すと、このコードはelseに到達しますね。

Sealed Classにすることで、コンパイラーがこのAの子クラスはB/C/Dしかないことを知られるので、最初のコードでも問題なくなります。

こうすることで、後で自分でAを継承する別のクラスを作ると、ここに選択肢を追加しないとコンパイルが通らなくなり、処理の追加漏れがなくなります。

Enumと比べて

前の項で書いている内容は、Enumでも実現できますね。

Enumと比べてSealed Classを利用する利点は、「Sealed Classを継承するのはobjectでもclassでもよい」ということではないでしょうか。

Sealed Classの子クラスそれぞれをEnumの値のように扱うことで、「Enumの各値に可変の値を持たせるような仕組み」ができます。

SwitftだとAssociated Valueと呼ばれるものですね。

使い方

使い方は簡単で、class宣言の前にsealedと書き、子クラスを全て同じファイル内で宣言するだけです。

sealed class A
class B : A()
class C : A()
class D : A()
object Z : A()

こうすることで、クラスAはこのファイル内でしか継承できなくなります。

また、Aはabstractなクラスかつ、コンストラクターがprivateになるので、直接インスタンス生成はできなくなります。

あとは通常のクラスと同じように使います。

どういう使い方をしている?

私が実際にSealed Classを使うシチュエーションを紹介します。

決まった文字列(全てが定数ではない)を受け取りたい時

これはSealed Classの「ファイル外で継承できない」仕組みを活用する例です。

例えばAndroidアプリでGoogle Analyticsにスクリーン名を送りたい時、スクリーンは定められた値なので、大半が定数で定義可能です。

しかし、完全な定数で済めばいいのですが、ページングをしている時にパラメーターとしてページ数を送りたいかもしれません。

また、普通にStringを送る運用だとミスって意味の分からない文字列を送ってしまうかもしれません。

こういった場合にそれぞれのスクリーン用にSealed Classを継承したobjectやclassを作り、Google Analyticsの送信用のラッパーを用意して、そこで値を分解して送るとこの問題を防ぐことができます。

sealed class GAScreen() {
  abstract val screenName: String

  open class Simple(override val screenName: String) : GAScreen()

  object Top : Simple("top")
  object Settings : Simple("settings")
  object List(private val page: Int) : GAScreen() {
    override val screenName: String = "list[page=$page]"
  }
}

ラッパー側は以下のようになります。

class GoogleAnalyticsWrapper() {
  fun sendScreen(screen: GAScreen) {
    val screenName = screen.screenName
    // ここでスクリーン名を送る
  }
}

こうすることで、うっかり変な文字列を送ることがなくなります。

色々な値を受け取って表示するActivityを起動するIntentに渡すパラメーターオブジェクト

こちらは"すごいEnum"っぽく使う例ですね。

Intentに複数のパラメーターをセットしたい時、全部を別々に手で受け取るのは面倒ですよね。

そのパラメーターの中にNullableなものがあって、別のパラメーターの値によって値が入ってなかったりすると思います。

こういう時にパラメーターオブジェクトを作って、Parcelableにして渡すのが有効と考えられます。

sealed class MainScreen() {
  object Top : MainScreen()
  object Settings : MainScreen()
  class Feed(val skipTutorial: Boolean) : MainScreen()
  class Category(val category: Category) : MainScreen()
  class EntryList(val initialTab: Tab) : MainScreen()
}

これをActivity側で受け取ってwhen式を使うなどして処理してやります。

when(screen) {
  is Top -> {
    openTop()
  }
  is Settings -> {
    openSettings()
  }
  is Feed -> {
    openFeed(screen.skipTutorial)
  }
  is Category -> {
    openCategory(screen.category)
  }
  is EntryList -> {
    openEntryList(screen.initialTab)
  }
}

最後に

KotlinのSealed Classを使って堅牢な設計のアプリを作りましょう。

明日の担当は id:aereal さんです!

Androidアプリの非同期なテストを書く時の悩みをEspresso Idling Resourceで解決する #関モバ

こんにちは、最近TDDに回帰している id:takuji31 です。

最近 Espresso Idling Resource を使い始めたので紹介します。

なお、この記事の一部は本日開催の関西モバイルアプリ研究会#24で発表された内容です。

UIテストを書く時の悩み

  • 何かが切り替わる時にUIのアニメーションが発生して、その後表示が切り替わるようなものをテストしたい
  • APIからデーターを非同期に取得して、画面に表示される値が正しいかテストしたい

↑のようなテストをする時、 “テストが可能になるまで待つ” という動作を実装するのは結構面倒です。

雑な解決方法

面倒なのでよくやるのは Thread.sleep(1000) みたいな感じで十分な時間待つことですね。

ですがこの対処方法には「待ったところで実は終わってないかもしれない = テストがたまにコケる」 という問題があります。

ちょっと賢い方法

われわれはかしこいので、RxJavaなんかを使って完了を待つObservableを作ったり、完了を待ち受けるListenerを作ったりするかもしれません。

これは確実に完了まで待つことができますが

  • 複数のコンポーネントの完了を全て待つ時の実装が複雑になりがち
  • そもそもテストのためにそんなものを手で時間をかけて実装するのは本質からそれているのではないか

といった問題があります。

Espresso Idling Resource

↑のような問題を解決するのが Espresso Idling Resource です。

これはEspressoのプラグインのようなもので、アイドリングの仕組みを提供してくれます。

このライブラリーで用意されている IdlingRegistry に自前の IdlingResource を登録すれば、そのリソースがアイドリング状態になるまで、テストが先に進むのを止めてくれます。

使い方

セットアップ

build.gradleに設定

compile 'com.android.support.test.espresso:espresso-idling-resource:3.0.0'

IdlingResource

まずは IdlingResource を作ります。

fun getName(): String

このIdlingResourceの名前を返します。この名前はロギングや二重登録のチェックに使われるようです。

fun isIdleNow(): Boolean

このリソースがアイドル状態かどうかを返します。

fun registerIdleTransitionCallback(callback: IdlingResource.ResourceCallback?)

アイドル状態になった時に実行するCallbackを登録します。

callbackはnullableのようです。

実装

ここではめちゃくちゃ簡単にしたいので、propertyにBooleanの値をセットするだけのものにします。

class SimpleIdlingResource(private val name: String) : IdlingResource {

    private var callback: IdlingResource.ResourceCallback? = null
    var isIdle: Boolean = false
        set(value) {
            field = value
            if (value) {
                callback?.run { onTransitionToIdle() }
            }
        }

    override fun getName(): String = this.name

    override fun isIdleNow(): Boolean = isIdle

    override fun registerIdleTransitionCallback(callback: IdlingResource.ResourceCallback?) {
        this.callback = callback
    }
}

使う

アプリ側

アプリ側で SimpleIdlingResource を使うコードを書きましょう

class ViewModel {

    var artists: List<Artist> = emptyList()

    var loadingDisposable: Disposable? = null

    @VisibleForTesting(otherwise = VisibleForTesting.PRIVATE)
    val loadingIdlingResource : SimpleIdlingResource = SimpleIdlingResource("IdlingResourceViewModelLoading")

    fun onCreate() {
        // fake API request
        fakeReload()
    }

    private fun fakeReload() {
        loadingDisposable = Single
                .timer(3, TimeUnit.SECONDS)
                .doOnSubscribe { loadingIdlingResource.isIdle = false }
                .doFinally { loadingIdlingResource.isIdle = true }
                .subscribe { _, _ -> artists = Artist.list }
    }

    fun onDestroy() {
        loadingDisposable?.run {
            dispose()
            loadingDisposable = null
        }
    }
}

APIを叩いてデーターを取得したような感じで3秒待ってリストを更新する処理を書きました。

処理の開始と終了時に loadingIdlingResource.isIdle の値を更新しています。

テストコード

テストでActivityを起動する前に IdlingRegistryIdlingResource を登録します。

@Before なメソッドでやってやるのがよいでしょう。

class IdlingResourceActivityTest {
    @JvmField
    @Rule
    val rule : IntentsTestRule<IdlingResourceActivity> = IntentsTestRule(IdlingResourceActivity::class.java, true, true)

    var initializeIdlingResource : IdlingResource? = null

    @Before
    fun setUp() {
        initializeIdlingResource = rule.activity.viewModel.loadingIdlingResource
        IdlingRegistry.getInstance().register(initializeIdlingResource)
    }
    // ...
}

テスト後には IdlingRegistry から IdlingResource を削除してやります。

@After なメソッドでやってやるのがよいでしょう。

class IdlingResourceActivityTest {
    // ...
    @After
    fun tearDown() {
        initializeIdlingResource?.run {
            IdlingRegistry.getInstance().unregister(this)
            initializeIdlingResource = null
        }
    }
}

テストは普通にEspressoで書きます。

class IdlingResourceActivityTest {
    @Test
    fun testReload() {

        // remove 3 items
        repeat(3) {
            openActionBarOverflowOrOptionsMenu(rule.activity)
            onView(withText("Remove first")).perform(click())
        }

        onView(withId(R.id.swipeRefreshLayout)).perform(swipeDown())

        onView(withId(R.id.recyclerView)).check { view, _ ->
            val recyclerView = view as RecyclerView
            assertEquals(recyclerView.childCount, Artist.list.size)
            assertEquals(recyclerView.adapter.itemCount, Artist.list.size)

        }
    }
}

用意されているMatcherやViewActionを使わない場合は Espresso.onIdle() を呼ぶとアイドル状態になるまで同期的に待ってくれます。

デフォルトで用意されているIdlingResource

CountingIdlingResource

セマフォっぽいやつ、 increment()/decrement() を呼んでカウントが増減し、0ならアイドルになる、1以上ならアイドルじゃないとなるようです。

CountingIdlingResource | Android Developers

IdlingScheduledThreadPoolExecutor / IdlingThreadPoolExecutor

ThreadPoolExecutor、IdlingScheduledThreadPoolExecutorは遅延実行できる。

IdlingScheduledThreadPoolExecutor | Android Developers

UriIdlingResource

UriをキーにできるIdlingResource、ドキュメントを見た感じWebViewと使うことを想定してるっぽい?

UriIdlingResource | Android Developers

ハマりどころ

Proguardを有効にした状態でテストを実行すると、IdlingRegistryがなくてコケる。

Proguardの設定を書きましょう。

-keep class android.support.test.espresso.** {
    public *;
}

最後に

割と簡単に実装できるので、Thread.sleepやめてIdlingResource使いましょう。

KotlinでJavaの予約語をメソッド名に使うとstubでメソッドが生成されない

ここで言うstubとは、Kotlinのstub生成機能で、Pluggable Annotation ProcessingでKotlinのクラスを処理するために必要になってくるもの。コンパイル時にJavaコンパイル前にKotlinのファイルからJavaソースコードを生成してstubとして利用する。

当たり前といえば当たり前なんだけど、Kotlin側ではメソッドが作れてしまうのでうっかり作ってしまってハマりそう

@Module
object SharedPreferencesModule {
  @Provides @JvmStatic fun default(context: Context) : SharedPreferences = PreferenceManager.getDefaultSharedPreferences(context)
}

これのstubはこうなる(一部省略)

@dagger.Module()
public final class SharedPreferencesModule {
    public static final com.github.takuji31.di.SharedPreferencesModule INSTANCE = null;
    private SharedPreferencesModule() {
        super();
    }
}

何もない😇

↓のようにするとよい

@Module
object SharedPreferencesModule {
  @Provides @JvmStatic fun defaultSharedPreferences(context: Context) : SharedPreferences = PreferenceManager.getDefaultSharedPreferences(context)
}

こうなる

@dagger.Module()
public final class SharedPreferencesModule {
    public static final com.github.takuji31.di.SharedPreferencesModule INSTANCE = null;
    
    @org.jetbrains.annotations.NotNull()
    @dagger.Provides()
    public static final android.content.SharedPreferences defaultSharedPreferences(@org.jetbrains.annotations.NotNull()
    android.content.Context context) {
        return null;
    }
    
    private SharedPreferencesModule() {
        super();
    }
}