#iOS | #Android Fashion News

Kotlin by JetBrains「Jake Wharton | KotlinConfersations'26」の文字起こし

Last updated : 2026-05-28 20:56

Android開発やKotlinコミュニティのキーパーソンであるジェイク・ウォートン（Jake Wharton）氏へのインタビューです。

🤔 1. 自己紹介とKotlinとの歩み [00:26]

経歴:
長年Androidデベロッパーとして活動。Square（現Block）、Cash Appを経て、現在はSkylightに在籍。

Kotlinとの出会い:
Square時代、Java 7の機能不足やGoogleのツール進化の遅さに悩んでいた「プレ1.0（正式リリース前）」の頃にKotlinに注目。社内向けに導入提案書（プロポーザル）を作成。

反響:
その提案書を公開したところコミュニティで大きな話題となり、SquareでのKotlin導入だけでなく、エコシステム全体の盛り上がりに繋がった。

🤔 2. AndroidにおけるKotlinとコミュニティの力 [01:50]

Googleでの活動:
一時期Googleに籍を置き、AndroidにおけるKotlinの公式サポート（KTXライブラリなどの立ち上げ）を支援。

エコシステムの進化:
KTXライブラリのコード自体は現在通常のライブラリに統合されて役目を終えたが、それは言語が成熟した良い証拠であると語る。

Apple（Swift）とのアプローチの違い:
iOSのSwiftがAppleという中央集権からトップダウンで提供されたのに対し、AndroidにおけるKotlinは「草の根（グラスルーツ）的なコミュニティの熱意」から始まり、最終的にGoogleが公式サポートせざるを得ない流れを作った点がユニークである。

非Androidへの広がり:
「KotlinはGoogle製でも、Android専用でもない」という点が、15年経った今ではAndroid以外の開発者にも広く認知されるようになった。

🤔 3. Kotlin Multiplatform (KMP) の挑戦 [05:35]

これまでのクロスプラットフォーム:
過去のXamarinやPhoneGap、現代のReact NativeやFlutterなどを評価した上で、Cash App時代にKotlin Multiplatform（KMP）とCompose Multiplatformを選択。

アプローチの特徴:
UI層はiOSならUIKit/SwiftUI、WebならHTML DOM、AndroidならCompose UIといった「各プラットフォーム独自のネイティブビュー」を尊重し、バックエンドのビジネスロジックやプレゼンターロジックのみを共通化（シェア）する方針をとった。

KMPの強み:
他のクロスプラットフォーム言語と異なり、WebならJavaScript、iOSならネイティブコード、AndroidならJavaバイトコードと、ターゲットごとに最適な形へコンパイルされるため、メモリ空間の競合や相互運用の壁（Interop layer）が少ない。

エコシステムへの貢献:
5年前に始めた当時はJetBrainsのComposeも初期段階だったため、自分たちで足りないターゲットを作るなどしてエコシステムを強力にプッシュした。

🤔 4. オープンソース（OSS）の重要性 [10:53]

キャリアへの影響:
オープンソースに貢献することで、自身のスキルアップだけでなく、新しい人との出会いや転職の機会など、キャリアの節目で何度も救われた。

企業とOSSの関係:
REST APIとの通信や画像読み込み、依存関係の解決（DI）など、どのアプリでも共通する「ビジネスの知的財産（IP）ではない部分」のコードはオープンにすべき。結果的に会社の採用活動（「OSSを見て応募した」という優秀な人材の獲得）など、数字に表れにくい大きなリターン（無形の資産）をもたらす。

🤔 5. 生成AI（LLM）とライブラリの未来 [15:11]

「AIがコード生成できるならライブラリ投資は不要か？」という問いへの持論:
「コードを書くこと（Writing code）」自体は、ソフトウェア開発において決して最も難しい部分ではない。AIは既存のスキルを加速させる（アクセラレーター）ツールとして使うべきであり、それなしではコードが書けないような依存の仕方はリスクがある（将来的なコスト高騰も含めて）。

コードは書かれる回数より、読まれる回数の方が10倍多い（Code is read 10 times more than it's written）。要件は常に変わるため、全体を俯瞰して理解できるコード設計が重要。

ライブラリの役割:
ライブラリの真の価値は「再利用可能なコードの境界線（デリミテーション）」を明確に引き、人間の認知負荷を下げることにある。パレートの法則のように「80〜85%の共通ユースケース」を綺麗にカプセル化することが大切。人間にとって直感的で優れた設計は、言語モデル（AI）にとっても扱いやすいはずである。

🤔 6. 2026年現在のKotlinへの期待 [22:45]

K2コンパイラの恩恵:
長年開発が続けられてきた「K2コンパイラ」への移行（大きな山場）を乗り越えたことで、言語自体の進化スピードが再び加速している。

注目している新機能:
Rich Errors（エラー処理の改善）プロポーザルの刷新
未使用の戻り値チェッカー（Unused return value checker）
when 式のデフォルト網羅性（Exhaustive when by default）

現在の心境:
K2の開発に全力を注いでいた停滞期を抜け出し、標準ライブラリ（datetimeやco-routinesなど）や言語プロポーザルが活発に進化している今の状況は、初期のKotlinのワクワク感を思い出させる。

🤔 7. コミュニティへの参加に気後れしている人へのアドバイス [27:30]

提案書（KEEP）の難しさ:
KEEP（Kotlin Evolution and Enhancement Process）はコンパイラの構文解析や各プラットフォームのバイトコードまで考慮しなければならず、内容が非常に高度で圧倒されるのは当然。

おすすめの関わり方:
Kotlin公式Slack（Kotlinlang Slack）にある language-proposal や language-evolution チャンネルを覗いてみるのがおすすめ。そこでは、より人間的で身近な困りごとや質問が、消化しやすい形で活発に議論されている。

Androidアーキテクチャの現状：GoogleのUDFと現実世界の「MVI風MVVM」の比較

Last updated : 2026-05-28 16:57

現代のAndroid開発においてどのアーキテクチャを採用するかを議論する際、議論はほぼ常にMVVM対MVIのどちらにするかという点に集約されます。

しかし、近年の傾向を見ると、この2つは対立する力ではなく、収束しつつあることは明らかです。

🧑🏻‍💻 Googleの立場：特定のパターン名よりもUDFを優先

Googleの公式「アプリアーキテクチャガイド」を詳しく見てみると、「MVI」という用語はほとんど出てこないことに気づくでしょう。その代わりに、Googleは一貫してUDF（単方向データフロー）という概念を推奨しています。

Googleは、コミュニティに既に馴染みのある「MVI」ではなく、なぜ抽象的な用語である「UDF」を使用するのでしょうか？

その理由は、Googleが柔軟性を重視していることにあり、彼らの哲学は次のようなものと思われます。

「MVIのような厳格な命名規則にとらわれすぎないでください。アーキテクチャの本質である一方向のデータフローが維持されるようにするだけで十分です。」

Reduxのような厳密な状態管理ライブラリを使用する場合でも、シンプルなViewModelで実装する場合でも、Googleが重視するのは「状態は下へ流れ、イベントは上へ流れる」という基本原則に従うことです。

🧑🏻‍💻 現代の標準：MVI風MVVMの実装

現場では、Googleが推奨するUDFに対する最も一般的なアプローチは、私が「MVI風味のMVVM」と呼ぶもので、MVIルールをMVVMコンテナに詰め込むものです。これには、状態、意図、効果という3つのコア要素が含まれます。

実際には以下のようになります。

The State of Android Architecture: Google’s UDF vs. the Real-World “MVI-flavored MVVM” | by chanzmao | ProAndroidDev

When discussing which architecture to adopt in modern Android development, the d

proandroiddev.com

Composeのバケツリレーが限界？ CompositionLocalでスマートに解決

Last updated : 2026-05-23 13:19

etpack Composeで階層が深くなると発生する「バケツリレー（Prop Drilling）」。

「自分（中間コンポーネント）は使わないのに、孫に渡すためだけに引数を定義する」という不毛な作業は、CompositionLocal でスマートにショートカットしましょう。

🧑🏻‍💻 1. CompositionLocal の仕組み

通常、データは「親 → 子 → 孫」と引数で手渡ししますが、CompositionLocal はツリー全体にデータを「漂わせる」イメージです。

下の階層にいるコンポーネントは、必要なときにそのデータを「キャッチ」するだけで済みます。

🧑🏻‍💻 2. 実装例：2つのデータ（名前と色）を孫まで飛ばす

「ユーザー名」と「テーマカラー」の2つのデータを、中間の「子」を介さずに「孫」へ届けます。

① データの「鍵」を定義する

まず、共有したいデータの種類ごとに CompositionLocal オブジェクトを作成します。


import androidx.compose.runtime.staticCompositionLocalOf
import androidx.compose.ui.graphics.Color

// 1. 各データの「鍵」を作成（デフォルト値を設定）
val LocalUserName = staticCompositionLocalOf { "ゲスト" }
val LocalUserColor = staticCompositionLocalOf { Color.Black }

② 親・子・孫の実装

中間の ChildView が引数を一つも受け取っていない点に注目してください。


@Composable
fun ParentScreen() {
    val name = "桃太郎"
    val brandColor = Color(0xFFFF5722) // オレンジ

    // 2. CompositionLocalProvider で値を注入（複数一気に指定可能）
    CompositionLocalProvider(
        LocalUserName provides name,
        LocalUserColor provides brandColor
    ) {
        // 子を呼び出す（引数で渡す必要なし！）
        ChildView()
    }
}

// --- 中間のコンポーネント ---
@Composable
fun ChildView() {
    // 自身はデータを使わないので、引数も処理もスッキリ！
    println("ChildView: 私は何も知りません。")
    GrandChildView()
}

// --- データの使い道がある末端（孫） ---
@Composable
fun GrandChildView() {
    // 3. .current を使って必要なデータだけを直接取得
    val name = LocalUserName.current
    val color = LocalUserColor.current

    Column {
        Text(text = "こんにちは、${name}さん！", color = color)
        Text(text = "親から直接データを受け取りました。")
    }
}

🧑🏻‍💻 3. なぜ「2方向」でも楽なのか？

バケツリレーの場合、渡す項目が「名前」「色」「権限」「ID」と増えるたびに、ルートから末端までの全関数の引数を書き直す必要があります。

CompositionLocal なら：
親： provides を追加するだけ

子： 修正不要（ここが最大のメリット！）

孫： .current で取り出すだけ

🧑🏻‍💻 4. 注意点：使いすぎに注意！

魔法のように便利な CompositionLocal ですが、使いすぎると「このコンポーネントは何に依存しているのか？」がコードから読み取りにくくなります。

推奨：アプリ全体のテーマ（色・フォント）、ログインユーザー情報、ロケール設定など。

非推奨：その画面内の特定のボタンでしか使わないような一時的なフラグ。

バケツリレーが3階層を超え、中間コンポーネントが「ただの運び屋」になっていたら、CompositionLocal への切り替え時かもしれません。

object vs compositionLocalOf vs staticCompositionLocalOf : The Ultimate State Sharing Guide | by chanzmao | Stackademic

When building with Jetpack Compose, choosing how to pass data down the UI tree i

blog.stackademic.com

Hiltのナビゲーション引数で SavedStateHandle から卒業する

Last updated : 2026-05-16 15:30

なぜ Hilt 2.49+ と @AssistedInject が、完全な型安全性を備えた引数渡しの「正解」と言えるのか。

🤔 問題点：静的な依存関係と動的なデータの混在

Android開発において、ViewModelにランタイム引数（実行時引数）を注入することは、常に議論の的となってきました。

その本質は、「静的依存関係」（DIによって管理されるリポジトリなど）と、「動的データ」（画面遷移時に渡されるナビゲーション引数など）の対立にあります。

適切なDIパターンを適用せずにこの問題に対処しようとすると、高確率でアンチパターンに陥ります。たとえば、一時的な状態をシングルトン（Singleton）内に保持してしまうと、状態の汚染や画面間でのデータ漏洩といった致命的なバグを引き起こす危険性があります。

🤔 解決策：ハイブリッド注入を実現する @AssistedInject

この「静的」と「動的」のギャップを埋めるための最適なツールが、@AssistedInject です。これを使用することで、DI（Hilt）が管理するオブジェクトと、実行時に受け取るランタイムパラメータをスマートに組み合わせた「ハイブリッド注入」が可能になります。

通常の @Inject は不要 :
@AssistedInject を使用する場合、コンストラクタに通常の @Inject を付ける必要はありません（というか、付けてはいけません）。

関心の分離 :
リポジトリなどの依存関係は Hilt が自動で供給し、ナビゲーション引数などの動的なデータだけを手動で安全に渡す、という明確な役割分担（関心の分離）が実現します。

クリーンなコードへ :
これにより、バグの温床になりがちだった危険な lateinit var による後からの初期化コードとは、完全におさらばできます。


// ViewModel 実装

@HiltViewModel(assistedFactory = RouteBViewModel.Factory::class) 
class  RouteBViewModel  @AssistedInject constructor( 
    private val repository: MyRepository,
    @Assisted val navKey: RouteB,
) : ViewModel() { 

    @AssistedFactory
    interface Factory { 
        fun create (navKey: RouteB) : RouteBViewModel 
    } 
}

🤔 実装：assistedFactory と hiltViewModel の組み合わせ

公式の nav3-recipes リポジトリでは、Hilt 2.49 以降で導入された最新の標準的な実装パターンが示されています。

nav3-recipes/app/src/main/java/com/example/nav3recipes/passingarguments/viewmodels/hilt at main · android/nav3-recipes

Implement common use cases with Jetpack Navigation 3 - android/nav3-recipes

github.com

ファクトリの宣言 :
@HiltViewModel(assistedFactory = ...) を使用して、Assisted Factory を ViewModel に直接リンクさせます。

2つの型パラメータ: Compose 側では、hiltViewModel() のように両方の型を明示的に指定して呼び出します。

安全なライフサイクル管理 :
creationCallback を利用することで、ナビゲーションのバックスタック管理（Lifecycle）を壊すことなく、安全にランタイム引数を渡すことができます。


// UI（ナビゲーション定義）

 entry<RouteB> { key -> 
    val viewModel = hiltViewModel<RouteBViewModel, RouteBViewModel.Factory>( 
        creationCallback = { factory -> 
            factory.create(key) 
        } 
    ) 
    ScreenB(viewModel = viewModel) 
}

🤔 メリット：100%の型安全性を実現し、SavedStateHandle のボイラープレートを完全に排除

このアーキテクチャ（Navigation 3 + @AssistedInject）に移行することで、コードベースの品質は大幅に向上します。

完全な型安全性（100% Type-Safe）:
かつての文字列ベースのキー（string のキー指定）は過去のものです。ナビゲーション引数は、Route（Serializable等で定義された型）として、厳密に型指定されたオブジェクトのまま直接安全に渡されます。

SavedStateHandle からの解放 :
単に次の画面へ引数を渡すだけのために、SavedStateHandle を使ってごにょごにょと値を書き出したり読み出したりする定型文（ボイラープレート）はもう一切不要になります。

圧倒的なリファクタリングのしやすさ :
すべてがコンパイル時にチェックされるため、引数の追加・削除・変更といったリファクタリングが、一瞬かつ確実に（ランタイムエラーの心配なく）行えるようになります。

🤔 まとめ

Hilt と最新の Jetpack Navigation の相乗効果により、画面間の引数の受け渡しは驚くほどスムーズかつ洗練されたものになりました。もはや、型安全性を犠牲にしたり、不自然なアーキテクチャで回避策（ワークアラウンド）を講じたりする必要はありません。

@AssistedInject と、進化した hiltViewModel() API を組み合わせることで、「完璧な型安全性」と「クリーンなハイブリッド依存性注入（DI）」を今すぐあなたのプロジェクトに導入できます。

Stop Passing ViewModels to Your Composables? | by chanzmao | May, 2026 | ProAndroidDev

Rethinking Screen Design in Jetpack Compose Navigation 3

proandroiddev.com

【Jetpack Compose Navigation3】EntryDecorator と ViewModel の「key」の深い関係

Last updated : 2026-05-01 16:35

Jetpack Compose の Navigation3 では、画面遷移の引数として RouteB(val id: String) のようなデータクラスを渡します。

このとき、同じ RouteB でも id が違えば「別の画面（別の ViewModel）」として扱いたいですよね。

ここで重要になるのが EntryDecorator と viewModel(key = ...) の関係です。

🤔 結論：Decorator が「鍵」を管理してくれるか否か

一言でいうと、こうなります。

Decorator を使わない場合：
手動で viewModel(key = "unique_id") を指定する必要がある。

Decorator を使えば：
viewModel() の引数は不要。
Decorator が自動で各エントリに個別の ViewModelStore を割り当ててくれる。

🤔 1. Decorator を使わないパターン（手動管理）

Navigation3 の基本機能 NavDisplay を使う場合、ViewModel の生存期間はデフォルトの「Activity 全体」に紐づきます。

同じ RouteB でも id ごとに ViewModel を作り分けたい場合、以下のように手動で key を渡して、内部のキャッシュを分ける必要があります。


entry<RouteB> { key ->
    // key（RouteBのインスタンス）の id を使って、ViewModelを区別する
    val vm = viewModel(
        key = key.id, // ← これが必要！
        factory = RouteBViewModel.Factory(key)
    )
    ScreenB(vm)
}

これを忘れると、id = "1" の画面から id = "2" の画面へ遷移しても、同じ ViewModel インスタンスが使い回されてしまい、表示内容が更新されない というバグに繋がります。

🤔 2. Decorator を使うパターン（Navigation3 の推奨）

サンプルの BasicViewModelsActivity で採用されている方法です。

nav3-recipes/app/src/main/java/com/example/nav3recipes/passingarguments/viewmodels/basic at bcba753d0dca783eb8c7c5680a22d181cfd74eed · android/nav3-recipes

Implement common use cases with Jetpack Navigation 3 - android/nav3-recipes

github.com

NavDisplay の設定に rememberViewModelStoreNavEntryDecorator() を追加します。


NavDisplay(
    backStack = backStack,
    entryDecorators = listOf(
        rememberSaveableStateHolderNavEntryDecorator(),
        rememberViewModelStoreNavEntryDecorator() // ← これが魔法のスパイス
    ),
    entryProvider = entryProvider {
        entry<RouteB> { key ->
            // key 指定が不要になる！
            val vm = viewModel(factory = RouteBViewModel.Factory(key))
            ScreenB(vm)
        }
    }
)

なぜ key が不要になるのか？

ViewModelStoreNavEntryDecorator は、バックスタックにある 「各エントリ（NavEntry）」ごとに独立した ViewModelStore を生成してくれます。

RouteB("1") のエントリ ➔ 専用の ViewModelStore A が用意される

RouteB("2") のエントリ ➔ 専用の ViewModelStore B が用意される

viewModel() 関数は、その時点の LocalViewModelStoreOwner（Decorator が提供するエントリごとのストア）を参照します。そのため、わざわざ key を指定しなくても、エントリが違えば自動的に別の ViewModel が作られる仕組みです。