ticktakclockの日記

技術ポエムを綴ったりします。GitHub idも同じです (@ticktakclock)

IntentのresolveActivityを考慮したRobolectricテスト

こんにちは、tkyです。

今日はテストの話です。

画面遷移をテストする時Robolectricを使うと比較的簡単にテストできます。

今回はRobolectric v4.3を使用して

  • 自身のアプリの別Activityに遷移する場合 (=明示的Intent)
  • 外部アプリに遷移する場合 (=暗黙的Intent)

この2つについてこんな感じでできるよ〜というのを紹介したいと思います。

また、Robolectricの説明や導入方法などは記載いたしませんのでご了承願います。

補足ですが、検証にはAssertJを使用しています。

例えば次のような画面遷移をする関数があるとします。

class MainActivity: AppComponentActivity() {

    // 自アプリ内の別Activityへ遷移する
    fun openSubActivity() {
        val intent = SubActivity.createIntent(this)
        startActivity(intent)
    }

    // 別アプリのブラウザアプリを開く
    fun openBrowser() {
        val uri = Uri.parse("https://google.com")
        startActivity(Intent(Intent.ACTION_VIEW, uri))
    }
}

テストコードは次のように書くことができます。

外部ブラウザのように暗黙的インテントによって画面遷移する場合、何が起動するかわからないのでActivityを検証することが難しいです。

そのため、発行したインテントを検証することでコードの正当性を担保します。

class MainActivityTest{

    @Test
    fun `openSubActivityしたらSubActivityに遷移すること`() {
        val activity = Robolectric.buildActivity(MainActivity::class.java)
        activity.openSubActivity() // ここでSubActivityに遷移する
        val shadowActivity = Shadows.shadowOf(activity.get())
        val intent = shadowActivity.peekNextStartedActivity()
        // intentのShadowを作成して次に起動するActivityを検証できるようにする
        val shadowIntent = Shadows.shadowOf(intent)
        val nextActivity = shadowIntent.intentClass
        // 遷移先が正しいこと
        Assertions.assertThat(nextActivity).isEqualTo(SubActivity::class.java)
    }

    @Test
    fun `openBrowser_外部ブラウザへ遷移する`() {
        val activity = Robolectric.buildActivity(RootActivity::class.java)
        activity.openBrowser() // ここで外部ブラウザに遷移する
        val shadowActivity = Shadows.shadowOf(activity.get())
        val intent = shadowActivity.peekNextStartedActivity()
        // urlスキームが正しくパースできること
        Assertions.assertThat(intent.data?.toString()).isEqualTo("https://google.com")
        // 外部ブラウザなので何が起動するか不明。暗黙的インテントのACTIONでassertする
        Assertions.assertThat(intent.action).isEqualTo(Intent.ACTION_VIEW)
    }
}

これで一応テスト可能となりますが、ここで公式のIntent起動ドキュメントを見てみましょう。

developer.android.com

注意:端末に暗黙的インテントを受け取ることができるアプリがない場合、startActivity() を呼び出すとアプリがクラッシュします。まず、インテントを受け取るアプリの存在を確認するために、Intent オブジェクトの resolveActivity() を呼び出してください。結果が null 以外の場合は、インテントを処理できるアプリが少なくとも 1 つあるということなので、startActivity() を安全に呼び出すことができます。結果が null の場合は、そのインテントは使用しないでください。可能であればそのインテントを呼び出す機能を無効にしてください。

要するに以下のようにIntentが起動できるか resolveActivity を使ってチェックしてから起動することを推奨しています。

    if (intent.resolveActivity(packageManager) != null) {
        startActivity(intent)
    }
class MainActivity: AppComponentActivity() {

    // 自アプリ内の別Activityへ遷移する
    fun openSubActivity() {
        val intent = SubActivity.createIntent(this)
        startActivity(intent)
    }

    // 別アプリのブラウザアプリを開く
    fun openBrowser() {
        val uri = Uri.parse("https://google.com")
        val intent = Intent(Intent.ACTION_VIEW, uri)
        // intentを受け取れるアプリがいるか確認してから起動する
        if (intent.resolveActivity(packageManager) != null) {
            startActivity(intent)
        }
    }
}

こうすると何が起こるのかというとRobolectricではresolveActicvity()の戻りがnullになってしまいstartActivityが実行されないことでテストが通らなくなってしまいます。

これを解決するためにShadowPackageManagerを使用してresolveActivity()をモックできるようにします。

    @Test
    fun openByUrlScheme_open_browser_外部ブラウザへ遷移する() {
        val activity = Robolectric.buildActivity(RootActivity::class.java)
        // ▼▼▼▼ 追加ここから ▼▼▼▼
        // ダミーでComponentNameを返す。Intentを検証するのでパッケージ名とActivity名は何でも良い
        val componentName = ComponentName(“com.some.other.package”, “MainActivity”)
        val intentFilter = IntentFilter(Intent.ACTION_VIEW).apply {
            addCategory(Intent.CATEGORY_DEFAULT)
            addCategory(Intent.CATEGORY_BROWSABLE)
            addDataScheme(“https”)
        }
        // PackageManagerのShadowを作成してIntentFilterを追加しておく
        Shadows.shadowOf(ApplicationProvider.getApplicationContext<MyApplication>().packageManager).apply {
            addActivityIfNotPresent(componentName)
            addIntentFilterForActivity(componentName, intentFilter)
        }
        // ▲▲▲▲ 追加ここまで ▲▲▲▲
        activity.openBrowser() // ここで外部ブラウザに遷移する
        val shadowActivity = Shadows.shadowOf(activity.get())
        val intent = shadowActivity.peekNextStartedActivity()
        // urlスキームが正しくパースできること
        Assertions.assertThat(intent.data?.toString()).isEqualTo(“https://google.com”)
        // 外部ブラウザなので何が起動するか不明。暗黙的インテントのACTIONでassertする
        Assertions.assertThat(intent.action).isEqualTo(Intent.ACTION_VIEW)
    }

この辺調べても古いバージョンのRobolectricでの対応方法などが出てきて新しいバージョンでの解決方法がなかったので結構ハマりました。

これでGoogleが推奨する外部ブラウザを開くような暗黙的インテントの実装をした状態でテストもできるようになりました。

是非試してみてください。

kotlinで別パッケージの同じクラス名の衝突を回避する

こんにちは、tkyです。

Kotlinの小ネタです。

タイトルのとおりなのですが、こういったことってほとんどないとは思うのでいざというときどうするか迷う系のやつです。

ドメインとしてのクラス名と被ってしまう

例えば イベント情報 を取り扱うドメインがあったとして Event クラスを作ったとします。

package com.hatenablog.ticktakclock.model.Event

data class Event(val id: Int /* その他引数 */) {}

次にFirebaseに送るトラッキングイベントを Event クラスとしてモデル化します

package com.hatenablog.ticktakclock.track.Event

sealed class Event(val name: String) {
    class Favorite(): Event("user_favorite") // お気に入りしたことをトラッキング
}

この2つのクラスを一緒に使おうとしたときにクラス名の衝突が起こってしまい、どちらかはフルパッケージ名で記述する必要が出てきます。

クラス名が衝突した!その前に

まず名前が衝突しないようにクラス名の変更リファクタリングを視野に入れましょう。

この場合、ドメインとしてのEventは共通仕様なので変えることがかなり難しいですが、トラッキングイベントの方は他の領域関係なく考え直すことができます。

package com.hatenablog.ticktakclock.track.TrackingEvent のように変えることで衝突が発生しない平和な世界を作れるはずです。

※個人的にはパッケージ名にtrackが入っているので更にTrackingEventという命名をつけることに多少違和感を覚えますが、名前回避のため・・・・

import にas を使う

外部のライブラリのクラス名と衝突してしまってどうしても平和的な解決ができない場合、 こちらのドキュメントに書いてあるとおり、 as キーワードを使うことでそのファイル内で別の名前を使用することができるようになります。

package com.hatenablog.ticktakclock.model.Event

package com.hatenablog.ticktakclock.track.Event as TrackingEvent // このファイル内でのみTrackingEventとして扱える

dogwood008.github.io

まとめ

あまりこういったことに出会わないため忘れがちですがいざというときに使えるテクニックかなと思います。

とはいえ前提として名前が被らないようにクラス設計するテクニック自体も身につけていきたいところですね。

  • asキーワードで局所的に別名を指定することができる
  • asキーワード使う前にもとのクラス名をリファクタできるか考えること
  • まだまだKotlinの知らない(あまり使っていない)言語機能ありそう

apk容量削減のためにやったこと

こんにちは、tkyです。

アプリ容量が日に日に多くなっていく中、できることを探してみました。

developer.android.com

公式に削減のための方法が乗っていて、そのうちの2つをやってみました。

効果

僕が携わっているアプリプロダクトは長い間運用されているのですが、 過去の画像リソースなど使用しないものや未使用コードなどもいくつかあることを以前から確認していました。

次の公式に乗っている方法を試してみたところ 18%ほど削減できました🎉

(めっちゃ未使用リソースが多かった・・・)

ちょっとしたファイル整理だけですが、apk容量が削減されることでユーザーにもたらす影響も結構あるのでぜひ試してみると良いかもしれません。

未使用コード、未使用リソースの削除

一番着手しやすいかもしれませんね。

menu > Analyze > Inspect code で不要になっているファイルやリソースを洗い出して削除していきます。

pngからベクターDrawableにする

各種リソースを用意するとそれだけで圧迫してしまうのでベクターで書き出したリソースを使用するのが良さそうです。

実際はデザイナーと相談してデザインデータをベクターで書き出せるようにする必要があるかと思います。

material.io

上記から適当なベクター素材をDLします。

f:id:ticktakclock:20210115155924p:plain
material iconのベクター素材をDLする

AndroidStudioでメニューからNew > Vector Assetを選択します

f:id:ticktakclock:20210115160231p:plain
AndroidStudioでvector assetを選択

先程DLしたsvgを選択すると@drawable/ic_favorite_24pxでDrawableで指定することができます。

f:id:ticktakclock:20210115160254p:plain
先程DLした素材を選択

minSdkVersionを19->23にする時に考慮したこと

こんにちは、tkyです。

私が業務で担当しているAndroidのアプリサポートバージョンをAPI19->23に引き上げました。

すでにリリースから数ヶ月経過しましたが、その時にやったことなどをまとめたいと思います。

OSの分布を知る

  • 世界的なOS分布 developer.android.com
  • プロダクトのOS分布

    アナリティクスツールなどで確認

切りたいバージョンのユーザーが何%行っていたら切るか、というのは社内でもそこまで定まっておらず、他の会社で採用している5%や3%などといった数値を参考に踏み切りました。

ちなみに5系以下は全体の6%でした。そこそこいました。

社内に持ちかけ

POと話す機会は何回かあり、以前より

  • 古いOSVerでWebViewの表示不正やクラッシュがある
  • 特定の動画フォーマットが再生できない

などの問題が起こっていたことと、たまたまOSサポートバージョンの話になった時に「やりましょう」という流れになりました。

開発しやすくなるなら、という目線で快く進める方向になったのは一番大きいです。

(正直意思決定権を持つ人が納得してくれるかがサポートバージョンを上げる最難関ポイントだと思っています)

クリティカルな不具合は直しておく

目に見えてわかっている不具合は予め対応しておきましょう。後に修正できても古いOSを持つユーザーにはそれは届きません。

minsdkversionを23に引き上げる

単純にapp.gradleの記述を返るだけです。

- minSdkVersion 19
+ minSdkVersion 23

MultiDexサポートライブリは不要に

minSdkVersion が 21未満の場合、64k制限のためにMultidexオプションを付けることがありますが、

minSdkVersion が 21 以上の場合は multidex がデフォルトで有効のため、multidex サポートライブラリは必要ありません。

ApplicationクラスやGradleにmultidex関連の処理を書いている場合削除しておきましょう。

VERSION分岐コードの精査

例えば以下のようなコードがプロジェクト内に存在するとします。

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
    // lollipop以上でしか使えないAPIを使用するコード
    doSomething()
} else {
   // lollipop未満の場合はこちらを使う
    doSomethingLegacy()
}

minSdkVersionが23になる場合、lollipop未満の条件に当てはまることが無いので

doSomething()

だけで問題ないことになります。条件が if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) であっても同様ですね。

このように VERSION_CODESGrepをかけて削除できそうな箇所を探してリファクタリングしていきました。 Marshmallowでランタイムパーミッションなどが入っているでこういった条件分岐を書いたりしている箇所があるかもしれません。自身のプロジェクト内を探してみてください。

動作確認で何をしたか

特に何もしていませんが、検証端末に5系端末を使っていたので念の為インストール出来ないよね、という確認はしました。

次回からはこの端末もお役御免という形になりました。ありがとう。

ユーザーに事前に通知すること

運用面で考慮したことですが、事前にOSのサポートが終了となる旨をユーザーにお伝えしなければびっくりしてしまいますよね。

そのため直前のバージョンを以てサポートを終了とする旨をお知らせページなどで通知するようにしました。

ユーザーはアプデできないということを意識する

当たり前ですが、5系を切ると5系を使っているユーザーは最新Verにアプデができなくなります。

サーバーレベルでサポートを切るかどうかは別の話で、今回はアプリをアプデできないもののサービスは引き続き利用できる状態としました。

アプリ起動時「新しいバージョンのアプリがあります。アップデートしてください」というようなアプデを促すダイアログを出しているアプリは多いでしょう。

ただし5系ユーザーにこのダイアログを出すとPlay Storeに行っても勿論最新アプリはないので混乱を招いてしまいます。

実際にアプデが入ったときのユーザーの行動を事前に予測しておくことが大事だと思いました。

リリース後に起こった問題について

  • 間違ったAPIを消していた

WebViewのとあるメソッドで、TARGETがLOLLIPOPのメソッドがあったのでそもそも使われることが無いだろうというので消したコードが実はMASHMALLOW以下のメソッドだった。。

WebViewに手を入れるときは全OSバージョンチェックしたほうが良いな・・・と改めて反省・・・

まとめ

  • OSサポートバージョンを23に引き上げた
  • これでWebView関連の不具合に当たることも少なくなるといいな
  • 他にもこんなことを考慮した、みたいなのがあればぜひ教えていただきたい

Go言語でgit checkoutを補助するコマンドを作った

こんにちは、tkyです。

Go勉強してコマンドを作ってみました。

github.com

git checkout をサポートする gith というコマンドです。

f:id:ticktakclock:20201123102923p:plain
デモ1

こんな感じにブランチが選択式で表示されるので選べばそのブランチに移動できるようなものです。

リモートブランチをチェックアウトするときはチェックアウトするブランチ名を決めることができます。

f:id:ticktakclock:20201123103223p:plain
デモ2

※例えばorigin/developブランチからfeature/XXXXのようなことをできるように

主要モジュール

これがすべてです。対話式のコマンドを完成させるのに一番ラクな方法かと思います。

サンプルも結構あって実際に見て使い方の理解も深まりました。

github.com

また今回はコマンドに引数とか細かいことは何もやらないでいたために urfave/cli 使用はしませんでした。

作った経緯など

僕はSourceTreeやGitKrakenなどのGUIツールは使っておらず、CUIでブランチの移動とかcommit, pushなどをしています。

gitでブランチを切り替えながら作業している時に

「あれ〜?あのブランチ名なんだったけ〜??」

となることがよくあります。

例えば「ホーム画面のレイアウトを修正」で

  • feature/home_layout
  • feature/home_screen_layout
  • feature/update_home_layout

なんだったかな〜と・・・ブランチ名をノリで付けている弊害であとで困る典型的なパターンに陥っています。

一応運用回避としてGitHubのIssueで管理している場合、

feature/#{IssueMumber}_your_task_name

という感じでIssue番号をプレフィックスにつけておくと判別できますね。

とはいえやっぱりブランチ名調べて git checkout する必要があるのでもう少し楽にしたいな〜というところからコマンド作成に至りました。

Goを選んだ理由は「Goだとコマンドが作りやすい」「Goやったことないからやってみたい」です。

Goの勉強方法

Tour of Goやってました。基本ここで学びます。

tour.golang.org

あとはこちらのスライドで並行で理解していく感じでした。

docs.google.com

ざっくりとこの辺を理解してからコマンド作成をはじめました。

  • 変数の定義方法
  • 関数の定義方法
  • for文, if文の定義方法
  • ポインタ
  • 配列、スライス
  • 構造体

※ポインタについてはもともとC言語やってたので何も困ることはありませんでした

おまけ

.bash_profile とかにこんな感じのことを書いておくと検索文字列に引っかかった一番最初のブランチをチェックアウトする事ができます。

コマンドを作る方法は色々ありますね!

fun gitissue() {
  git branch | grep $1 -m1 | xargs git checkout 
}
$gitissue #123

みなさんも自作コマンドで開発を楽にしていきましょう!

GitHubActionsとCircleCIを使い分ける

こんにちは、tkyです。

今私が携わっているAndroidプロジェクトのCIは基本的にCircleCIを採用しています。

そんな中、同時にGitHubActionsも採用した経緯とどんなことをしているのか、ちょっとハマったことを書き留めておこうと思います。

また、本記事は「こうしたら良い」というわけではなく、「とある課題から解決策を模索した」結果なだけなので

皆さんのプロジェクトに合わせて最適な形を模索するための材料の1つとなれば幸いです。

今までのCIの運用

コードはGitHubで管理しており、PullRequestをトリガーにCIが回るようになってます。

※コミット単位にするとCIの作動回数が多くなるので節約の目的があります。

  • UnitTest
  • Lint
  • DangerでTestとLint結果を報告
  • DeoloyGateのdebug apkアップロード

[課題]developブランチとapkが一致しない

pull requestごとにdebug apkが作られるため最新Developブランチとapkが一致せず、debug用のapkはPRの動作確認用になっていました。

しかも実際はブランチをチェックアウトして自分でビルドして動作確認しており現状のapkは事実上形骸化していました。

チームメンバーと会話して「develop最新と紐付いているapkを常に確認できる状況作っておきたいよね」ということで

DeoloyGateのdebug apkアップロード のワークフローのトリガーを developブランチにマージされた時(developにコミットされた時)に変更します。

Circle CIの設定見直し

現在CircleCIの管理画面ではこの2がONになっています。

developブランチにマージされた時にしたい場合 Only build pull requests をOFFにしてfilterでdevelopのみ動作するワークフローを作ればよいのですが

そうするとPR以外のリモートへのコミットでもCIが回るのでそれもなぁ・・・という感じです。

上記をを許容できるならGitHubActions使う必要ないのでこの話は終わりですw

もう少し頑張りたいよね、というところでdevelopブランチにコミットされた時のトリガーだけをGitHubActionで切り出すことにしました。

実際に検討で使った図です

f:id:ticktakclock:20201121141635p:plain:w400
検討図

そんなこんなで以下のように話をまとめて現在のプロジェクトで2つのCIツールを運用している、という話でした。

  • CircleCI: PRした時に処理したい場合
  • GitHubActions: (特定ブランチに)コミットされた時に処理したい場合

なぜGitHubActionsにすべて移動しないのか?

GitHubの各トリガーに柔軟に対応できるGitHubActionsを使えばやりたいことは全部できるでしょう。

しかしながら後述するskip-buildの機能やSSHデバッグなどCircleCIがデフォでできる機能は各々でアクションを定義する必要があります。

ローカルCLIもないため実際にPR上げてtry&errorで動作確認になるのでコストも高いです。(一応CLI実行できるnodeプロジェクトがあったような気がする)

仮に私がaction全部作れたとして、ほかメンバーがそれを管理運用できるか、という問題も浮上してきます。

そういう部分もあり、いきなり全てをGitHubActionsにして逆にコストがかかることを考慮して一部だけ切り出しただけなので、今後の状況によってはありえるかなと思っています。(当分先になりそうですが・・・)

GitHubActions導入してみた

こんな感じのymlを作成します。これがDeploygateにアップロードする(gradleタスクを実行する)ワークフローとなります。

色んな人がAndroidのビルドしていたりするのでコピペで色々貼り付けてます。

.github/workflows/upload_apk.yml

name: upload_apk
# CIツールの使い分け
# ・CircleCI: PRした時に処理したい場合
# ・GitHubActions: (特定ブランチに)コミットされた時に処理したい場合
on:
  push:
    branches:
      - develop

jobs:
  build_canceller:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: stop old workflow
        uses: yellowmegaman/gh-build-canceller@master
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          workflows_filter: "upload_apk"
  deploygate-develop:
    name: Upload apk to deploygate for developDebug
    runs-on: ubuntu-latest
    needs: build_canceller
    steps:
      - name: Check out
        uses: actions/checkout@v2
      - name: set up JDK 1.8
        uses: actions/setup-java@v1
        with:
          java-version: 1.8
      - name: NDK cache
        id: cache-primes
        uses: actions/cache@v2
        with:
          path: ${ANDROID_HOME}
          # GithubActionsコンテナに入っているNDKバージョンとプロジェクトの必要NDKバージョンが異なるため
          # コンテナに必要NDKバージョンをインストールする
          # ビルドエラーが出た場合cacheステップとInstallステップに記述のバージョンを更新してください
          key: ${ANDROID_HOME}/ndk/21.0.6113669
          restore-keys: |
            ${{ runner.os }}-ndk-
      - name: Install NDK
        run: echo "y" | sudo $ANDROID_HOME/tools/bin/sdkmanager --install "ndk;21.0.6113669" --sdk_root=${ANDROID_SDK_ROOT}
      - name: Gradle cache
        uses: actions/cache@v2
        with:
          path: ~/.gradle
          key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle') }}
          restore-keys: |
            ${{ runner.os }}-gradle-
      - name: Upload DeployGateDevelopDebug
        run: |
          ./gradlew uploadDeployGateDevelopDebug

[ハマったこと]古いビルドはキャンセルされない

CircleCIのskip-buildと同じような機能はGitHubActionsにはないので自力でなんとかする必要があります。

そういうActionがあるのでありがたく使わせていただくことにします。

GitHubActionsを無料稼働枠内で使うための節約テクニックみたいな感じです・・・

※2020/11/21現在最新は

  build_canceller:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: stop old workflow
        uses: yellowmegaman/gh-build-canceller@master
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          workflows_filter: "upload_apk"

以上です。

Kotlin applyから理解するレシーバー付きラムダ

こんにちは、tkyです。

『レシーバー付きラムダ』という用語をご存知でしょうか。Kotlinインアクションとかで使われている表現です。

英語では Function literals with receiver と言われています。

今回は apply{} がどのように動作するのか確認しながら『レシーバー付きラムダ』何なのかというものを理解して行きたいと思います。

ラムダ式とは、スコープ関数、拡張関数といった用語の説明はしません。

apply

まず apply をおさらいします。こんな感じでインスタンスを生成したあとにプロパティに値を設定したりとかそんな使い方をするのが一般的ですね。

class User(val name: String) {
    var age: Int = 0
    var email: String = ""
}

val user = User("ticktakclock").apply {
    age = 10
    email = "example@example.com"
}

apply の実装を見てみるとこの様になっています。

public inline fun <T> T.apply(block: T.() -> Unit): T {
    contract {
        callsInPlace(block, InvocationKind.EXACTLY_ONCE)
    }
    block()
    return this
}

注目していただきたいのは関数の引数である block: T.() -> Unit です。 引数にラムダを渡しているわけなのですが、 T.() というように Tの拡張関数のような表現になっていますね。

ここで拡張関数のドキュメントを見に行きます。

kotlinlang.org

以下抜粋

拡張関数を宣言するには レシーバータイプ (receiver type) を関数名の前に付ける必要があります。 次の例では、 swap 関数を MutableList<Int> に追加しています:

fun MutableList<Int>.swap(index1: Int, index2: Int) {
  val tmp = this[index1] // 'this' がリストに対応する
  this[index1] = this[index2]
  this[index2] = tmp
}
拡張関数内での this キーワードは、レシーバオブジェクト(ドットの前に渡されたもの)に対応しています。これで、この関数を任意の MutableList<Int> からでも呼べるようになりました:

はいでました!レシーバー!

この関数を実行(受ける)ときのthisの型またはオブジェクトを レシーバー というのですね。

swap関数をレシーバーはMutableListと理解できます。

block: T.() -> Unit は拡張関数で定義しようとすると次のようになりますが、このときのthisはTですね。別の視点からみてもこの理解でおおよそあってそうです。

fun T.block() {
    // thisはT
}

ラムダ式におけるthisはあくまでそのラムダ式を実行するオブジェクトとなりますが、 レシーバータイプを指定するとことでthisの型を指定することができるということです。

いったん apply のドキュメントを見に行ってみましょう。

kotlinlang.org

コンテキストオブジェクトは、レシーバー(this)として使用できます。

ここでもちゃんとレシーバーが出てきました。

新しい単語(コンテキストオブジェクト)も出てきました。関数のスコープ内で使用する特定のオブジェクトのことを指しているのであっていると思いますが、その特定のオブジェクトにthisでアクセスできるということですね。

続いてラムダ式のリファレンスも見に行ってみましょう。きっと何かが書いてありそうな予感。

kotlinlang.org

ありました。関数型はレシーバーを使用することで関数型のインスタンスを呼び出す事ができる、というようなことが書いてあります。

applyに戻ります。

class User(val name: String) {
    var age: Int = 0
    var email: String = ""
}

val user = User("ticktakclock").apply {
    // applyを呼んだUserインスタンスをレシーバーとしてラムダ式を実行する
    age = 10
    // thisはUserインスタンスなのでthis.age =10 と同じ
    email = "example@example.com"
}

おお〜理解できるかも〜!

まとめ

  • レシーバー付きラムダというのは拡張関数をラムダ式で記述したもののこと
  • レシーバーというのはこの関数を実行(受ける)ときのthisの型またはオブジェクトのこと
  • ドキュメントって何でも書いてあるんだなぁ

理解の仕方や調べ方の助けになったら幸いです。