日本語 JIS キーボードが馴染めない場合とか
ストレスすぎますよね。
逆もしかり。
様々なキーボードマッピングカスタマイズアプリなどありますが、
強引にレイアウトを変更したとて、
そもそもキーそれぞれ一つ一つのサイズが違う。
この方法がベストだと思われます。
少し高いですが。
👉 Magic Keyboard - 英語（US） - Apple（日本）
これを買うなりして手に入れるのが一番操作感は一番近いです。
日本語 JIS と 英語 US。
指紋センサー付きとなし。
Mac Bookのキーボード。
すべてサイズ同じです。
上に乗せればそれが一番良い感じです。
以上です。
知らなかったわ。
「手動マッピング（命令型）」か、「DSLマッピング（宣言型・型安全）か」
ということなります。
これまで:
when 式などを使って、ルートごとに手動でインスタンスを生成・紐付けするスタイル。自由度は高いですが、記述量が増えやすく、型の不整合も起きがちです。
DSL形式:
entry
entryProvider = { key ->
when (key) {
is RouteA -> NavEntry(key) { ... }
is RouteB -> NavEntry(key) { ... }
else -> error()
}
}
entryProvider = entryProvider {
entry<RouteA> { ... }
entry<RouteB> { key ->
Text(key.id)
}
}
NavDisplay
└ entryProvider (lambda)
└ when(key)
├ RouteA → NavEntry + UI
├ RouteB → NavEntry + UI
└ else → error
NavDisplay
└ entryProvider (DSL)
├ entry<RouteA> { UI }
└ entry<RouteB> { key -> UI(key.id) }
DSLは便利だが、抽象化が増えるため「内部の仕組み」が見えにくい感じに思います。
Jetpack Compose で開発をしていると、必ず直面する問いがあります。
「これは State として保持すべきか、それとも Effect（副作用）として処理すべきか？」
という問題です。
Compose の宣言的 UI パラダイムにおいて、この境界線を曖昧にすると、画面回転時の二重トーストや、意図しない画面遷移といったバグを招きます。
本記事では、その明確な使い分けと、イベント制御における Kotlin Channel の有効性について解説します。
使い分けの基準はシンプルです。
「そのデータは、UI のスナップショットの一部か？」
と自問してください。
State は、再構成（Recomposition）によって何度読み込まれても同じ結果を示すべきものです。
Effect は、Compose のレンダリングサイクルとは独立して実行される処理です。
ここで問題になるのが、トースト表示や画面遷移のような「一度だけ実行したいアクション」です。
これらを StateFlow で管理しようとすると、Android 特有のライフサイクル問題にぶつかります。
StateFlow は常に「最新の状態」を保持します。
1. エラーが発生し、State を ErrorMessage("Failed") に更新。
2. UI がそれを検知してトーストを表示。
3. ここで画面を回転させる。
4. 新しい Activity が StateFlow を購読し、最新の "Failed" を再び受け取ってしまう。
5. トーストが二重に表示される。
これを防ぐために「フラグを戻す」処理を挟むのは、シンプルではありません。
そこで登場するのが Channel です。Channel は、「土管」のような振る舞いをします。
私のプロジェクトでは、以下のような棲み分けを徹底しています。
// ViewModel
// UI の状態（表示データ）
private val _uiState = MutableStateFlow(UiState())
val uiState = _uiState.asStateFlow()
// UI へのイベント（ワンショット）
private val _eventChannel = Channel<UiEvent>(Channel.BUFFERED)
val events = _eventChannel.receiveAsFlow()
// UI (Compose)
LaunchedEffect(Unit) {
viewModel.events.collect { event ->
when (event) {
is UiEvent.ShowSnackbar -> snackbarHostState.showSnackbar(event.message)
is UiEvent.NavigateToDetail -> navController.navigate("detail")
}
}
}
複雑なフラグ管理でコードを汚す前に、ツールが持つ「自然な性質」を利用しましょう。
Channel を使うことは、Compose におけるイベントハンドリングを最もシンプルにする考え方の一つです。
@Composable
public fun rememberNavBackStack(vararg elements: NavKey): NavBackStack<NavKey> {
return rememberSerializable(
serializer = NavBackStackSerializer(elementSerializer = NavKeySerializer())
) {
NavBackStack(*elements)
}
}
@Serializable(with = NavBackStackSerializer::class)
public class NavBackStack<T : NavKey> public constructor(internal val base: SnapshotStateList<T>) :
MutableList<T> by base, StateObject by base, RandomAccess by base {
public constructor() : this(base = mutableStateListOf())
public constructor(vararg elements: T) : this(base = mutableStateListOf(*elements))
}
RememberNavBackStack.kt - Android Code Search
NavBackStack.kt - Android Code Search
👉️ rememberNavBackStack() は、rememberSerializavle + Serializer で rememberSerializable に渡している。
@Composable
public fun <T : Any> rememberSerializable(
vararg inputs: Any?,
serializer: KSerializer<T>,
configuration: SavedStateConfiguration = DEFAULT,
init: () -> T,
): T {
val saver = serializableSaver(serializer, configuration)
@Suppress("DEPRECATION")
return rememberSaveable(*inputs, saver = saver, key = null, init = init)
}
RememberSerializable.kt - Android Code Search
👉️ rememberSeriarizable() は、@Serializable を rememberSavable + Saver で保存できるようにしている。
ということで、
UI (@Composable) にナビゲーションのスタック状態の保持を任すのなら
rememberNavBackStack()
を使うと便利。
ということのようです。
画面回転やライフサイクルなどありますしね。
JavaエンジニアがKotlinに移行する際、最も危険なのは「Kotlinの文法でJava5の頃の思考で書く」ことです。
RxJava（リアクティブプログラミング）という高い壁を飛び越えようとして、逆に20年前の古典的手法に着地してしまうケースが後を絶ちません。
fun loadUser(callback: (User?) -> Unit) {
api.getUser { user ->
if (user != null) {
database.save(user) {
cache.update(user) {
analytics.track(user) {
callback(user)
}
}
}
} else {
callback(null)
}
}
}
interface OnUserLoadedListener {
fun onLoaded(user: User)
}
fun loadUser(listener: OnUserLoadedListener) {
api.getUser(object : ApiCallback {
override fun onSuccess(user: User) {
database.save(user, object : SaveCallback {
override fun onSaved() {
listener.onLoaded(user)
}
})
}
override fun onError() {
}
})
}
RxJavaすら導入されていない現場、あるいは「Rxは難しいから」と避けた結果、以下のような絶滅危惧種がKotlinの皮を被って出現します。
① 独自インターフェースによる「バケツリレー」
interface MyCallback を定義し、それを Activity から Presenter（あるいは ViewModel）、さらに Repository へと引数で渡していくスタイルです。
地獄のポイント: 1つの処理を追うのに3つ以上のファイルを跨ぐ必要があり、デバッグ中に「今どこにいるのか」を見失います。
② AsyncTask の「自力再実装」
Googleが非推奨にした AsyncTask ですら、中身はスレッド管理とコールバックの塊でした。これをKotlinの Thread { ... } と Handler(Looper.getMainLooper()) で自作再現してしまうパターンです。
地獄のポイント: isDestroyed のチェックを忘れ、画面を閉じた後にクラッシュ（NullPointerException）させる「爆弾」を量産します。
③ MutableList を使った共有メモリの恐怖
非同期の戻り値を待てず、外部の MutableList に値を詰め込ませ、別の場所で Timer や Thread.sleep を使って「値が入ったか監視する」という、スレッドセーフを無視した力技です。
それは、Javaエンジニアが長年培ってきた「命令型プログラミング」の呪縛です。
「待つ」という概念の欠如: 「処理を止めたらスレッドが死ぬ（UIが固まる）」という恐怖心から、すべてを「終わったらこれを呼べ」という受動的な構造（ハリウッド原則）にしてしまいます。
状態管理の煩雑さ: 古いJavaでは、状態の変化を「通知」する仕組みが乏しかったため、泥臭いフラグ管理やコールバックに頼らざるを得ませんでした。
今のAndroid開発者が知っておくべき、技術の「地層」は以下の通りです。
Javaエンジニアの皆さんが持つ「堅牢なクラス設計」の知識は宝です。しかし、「非同期処理の書き方」だけは、一度全て忘れてください。
Kotlinにおける suspend は、ただのキーワードではありません。それは、私たちが10年以上苦しめられてきた「コールバック地獄」という名の迷宮から脱出するための、唯一の出口なのです。