緒論

メイン画面です(美しい単位画面)
メイン画面開発期にはxml 내에 jetpack compose 를 어떻게 쓸 수 있는지を重点的に開発した.
ちなみに、公式ファイルではxmlとjetpackの組み合わせの互換性が良いと言われています.
いくらだったかは覚えていませんが、彼はいいと言っているので、本当かどうか確認してみましょう.

メイン画面の強化

まず、MVPコードをMVVMに変換します.
同時にBindingAdapterを用いて,総単位によって背景やボタン色のコードを改良した.

(ちなみに、写真に表示されている2番目、3番目の関数はxmlにcompositionを追加すると消えてしまいます.)
いずれにしても、当時はこのように尊敬していたが、うまくやったかどうかは分からなかった.
前に一度処理したものを割ってみましたが、あまり変わっていないので、無駄にしたと思います.
右より左の方が厚めに貼られている感じがするのはなぜでしょうか?
いずれにしても、このような過程を経て、コード線は10~20行減少した.

お客様ProgressBar Perfect

まずは名前を変えて
従来はMainProgressBarで統計画面でも使用されていたため、共通の名称変更が必要であった.
次に、既存のJavaコードをKotlinに変換します.
注釈,関数の追加,繰返し論理整理などによりコードを整理する.
だからよくなったように見えますが、これはかえってコードを増やしました.3~40行くらい?
コードを再理解すると、コメントがないので気分が悪くなるので、それらを追加すると、コード線がずいぶん増えているようです.

例を挙げるとこうなるのでしょうか…?
このほか,コードの再表示を容易にするために曖昧な関数名なども変更した.

xmlに合成などを追加しますか?

実はこれが本題です.では,合成はxmlにうまく応用できるだろうか.


驚くべきことに、上記のxmlのように、既存のレイアウトはComposeViewに処理される.onCreateからlayoutId.setContent { ... }までです.
Ramda内でComposable関数を呼び出せば良いだけです.コードから見るとそうです.

binding.clMainInput.setContent {
    MainBottomItemView(viewModel, MAIN_BOTTOM_ITEM_INPUT)
}

binding.clMainStatistic.setContent {
    MainBottomItemView(viewModel, MAIN_BOTTOM_ITEM_STATISTIC)
}

MAIN_BOTTOM_ITEM_INPUT、MAIN_BOTTOM_ITEM_STATISTICは、どのボタンに関するflag値であるか.

また、青色内のボタンは実際には機能が同じです.

をクリックして、別の画面

に切り替えます.

の合計スコアの現状により、画像は

と異なる.
この2つの機能しかないので、これらの機能が統合されています.
したがって、既存の機能を再構成しながら、各ボタンのbindingAdapterロジックを構成可能な関数に入れる.
また,同様の機能,すなわち統合が可能である.
上のsetContentコードでも予想されていましたが
2番目のパラメータ値を区切って、設定可能な関数の画像を書き込み、イベントをクリックします.

val title = arrayOf(
    stringResource(id = R.string.tv_main_input),
    stringResource(id = R.string.tv_main_statistic)
)[position]

val drawables = arrayOf(
    listOf(
        R.drawable.m_input_a,
        R.drawable.m_input_b,
        R.drawable.m_input_c,
        R.drawable.iv_main_input
    ),
    listOf(
        R.drawable.m_statistic_a,
        R.drawable.m_statistic_b,
        R.drawable.m_statistic_c,
        R.drawable.iv_main_statistic
    )
)[position]

val clickEvent = viewModel?.let {
    arrayOf(
        it::clickInputLayout,
        it::clickStatisticLayout,
    )[position]
} ?: { Timber.i("for Preview") }

このように処理するとbindingAdapterに重複コードがあるので,このように残念な内容を改善した.

val mainScore = viewModel?.mainScore?.observeAsState() ?: remember { mutableStateOf(0f) }

Column(
	// 1
    modifier = Modifier.clickable(
        enabled = true,
        onClick = clickEvent,
        indication = rememberRipple(bounded = true),
        interactionSource = remember { MutableInteractionSource() }
    ),
    horizontalAlignment = Alignment.CenterHorizontally,
    verticalArrangement = Arrangement.Center
) {
    Image(
        painter = painterResource(
            id = mainScore.value?.let {
            	// 2
                when {
                    it >= 4 -> drawables[0]
                    it >= 3 && it < 4 -> drawables[1]
                    it >= 2 && it < 3 -> drawables[2]
                    else -> drawables[3]
                }
            } ?: drawables[3]
        ),
        contentDescription = title
    )
    Spacer(modifier = Modifier.height(32.dp))
    Text(
        text = title,
        fontSize = 15.sp,
        color = colorResource(id = R.color.defaultTextColor),
        textAlign = TextAlign.Center
    )
}

実際のビューはこうです.

以前の位置決めではテクスチャ波が除去されたが、ここにテクスチャ波が加わった.
インタラクティブなソースを設定する必要があることを示します.これにより、連鎖反応が発生します.

これは、

で述べた重複論理を統合した内容である.

n/a.結論

思ったほど内容が多くないほど簡単です.
ComposeViewでsetContentを設定し、Composable関数を呼び出します.
xmlに溶け込むComponentが表示されます.
ここまで来るのは簡単です.でも….次の章(単位入力画面)は本当にたくさんやりました.
commitレコードを振り返っても,ここでの最適化過程には2週間程度の時間がかかる.
もちろん完全な100%2週間ではなく、2週間の間でしたが、他の仕事よりもかなり時間がかかりました.

州管理

親TextField

を使用
単位を

焦点でリアルタイムで計算する

次の位置づけでは、これらの内容について議論します.