Kotlin CoroutinesのFlowを使っている場合、UI状態の統合等でFlow.combineを使うことが多いと思います。
Kotlin CoroutinesはOSSになっており、その実装を簡単に読むことができます。
Flow.combineはどうやって実装されているのか気になり、読んでみると、思った以上に細かいところに気を配った丁寧な実装になっていて驚きました。
今回はそのFlow.combineの実装を自分で再現するという流れで、公式のFlow.combineの工夫されている点や、複雑なFlowを自作する方法について学びたいと思います。
この記事はKotlin Advent Calendar 2022の18日目の記事です。
Kotlin Coroutinesを使ったコードのテストを書く場合、Dispatcherを差し替えることで仮想時間を使い、実際より短い時間でテストを実行したり、実行のタイミングを細かく制御することができます。
テスト用のDispatcherとして、 StandardTestDispatcher と UnconfinedTestDispatcher の2つが用意されています。
今回はこの2つの違いと使い分けについて紹介します。
この記事はAndroid Advent Calendar 2022の4日目の記事です。
Jetpack Composeで複雑なレイアウトを組むのに、Box, Row, Columnだけでは表現できずに困ったときはありませんか？
もしかしたらLayout Composableを使うことで実現できるかもしれません。
Layout Composableはかなり自由度高くレイアウトを組める一方、複雑で敬遠しがちです。
今回は例をもとにLayout Composableの使い方について紹介します。
Jetpack Composeの大きな特徴として、再利用可能なコンポーネントを作りやすくなったことがあるでしょう。
細かい単位でComposable関数に切り出すことで、同じUIを共通化できるだけでなく、今後の仕様追加/変更の際にもスムーズにコンポーネントを再利用できるでしょう。
一方で、再利用可能なコンポーネントの実現にはいくつか注意すべき点があります。 今回は公式から述べられている注意事項や、自分が書いていて注意していることについて紹介します。
ユーザが何かをタップしたときにフィードバックを返すことは、正常に入力できたことをユーザに伝えるだけでなく、心地よい操作感やリッチ感を実現するためにも重要です。
MaterialDesignでは、クリック時に波紋状のRippleエフェクトを表示します。
Jetpack ComposeでもMaterialThemeを利用している場合、クリック可能なコンポーネントはRippleエフェクトが表示されます。
今回はJetpack ComposeでRippleエフェクトについて色々深堀りをしていき、Rippleの色を変えたり、そもそもタップ時のエフェクトを変更する方法についても紹介します。
Jetpack Composeがstableになりしばらく経ちますが、利用しているとAndroid Viewにあった様々なものが、まだ用意されていないことに気が付きます。
テキストを入力できる TextField は、まだ最大文字数(maxLength)を設定することができません。
今回は最大文字数を設定するいくつかの方法について紹介を行います。
この記事は Android Advent Calendar 2021 の13日目の記事です。
Jetpack Composeは内部でもKotlin Coroutinesを多く使っており、非常に相性が良いです。
今回はJetpack ComposeとKotlin Coroutinesを組み合わせて使ういくつかの方法について紹介します。
この記事は Kotlin Advent Calendar 2021 の5日目の記事です。
Kotlinは関数をinline化することができます。
inline化によるメリットはいくつかありますが、一つはパフォーマンスの向上でしょう。
関数をパラメータとして受け取る関数については、メモリ割り当てが重複し、実行に多少のコストがかかります。
inline化することで、コンパイル時に展開された形のコードが生成され、実行時のコストが削減されます。
一方、コンパイル時に展開されることにより、出力される実行ファイルのサイズは増えると言われてるため、自分で作成した関数をinline関数化するかどうか悩むこともあるでしょう。
今回は、inline化することによる、実行速度、メモリ使用量の変化と実行ファイルのサイズを確認してみます。
このブログはReactで1から作成しており、CSR (Client Side Rendering) として実行してました。
この度、Next.jsのSSG (Static Site Generation) を導入してみたので、その報告になります。
Androidアプリ開発において、Lifecycleを考慮することでユーザのリソースを有効的に利用することが出来ます。
ユーザのリソースを不要に消費しないようにするためには、必要になったときに必要な処理を行うことが重要です。
バックグラウンド時や他画面を開いているときAPIを叩く必要性が出てきても、LifecycleがSTARTEDになるまで待つべきでしょう。
今回は、Kotlin Coroutinesを用いて、LifecycleがSTARTED、すなわちフォアグラウンドになったときにAPI等を叩くような処理について考えてみます。
Kotlin CoroutinesをUIスレッド(Dispatchers.Main)のみで使っている場合、単一のリソースを複数Coroutinesで扱った場合でも問題が発生することはほとんどありません。
一方で、バックグラウンドスレッドを含めた複数スレッド(Dispatchers.Default, Dispathcers.IO)で単一のリソースを共有した場合は、競合が発生し予期せぬ不具合を引き起こす可能性があります。
今回はその危険性と解決方法について紹介します。
以前「LiveData vs Flow vs RxJava」という記事で紹介したとおり、LiveDataは非常にシンプルで、現在でもベストプラクティスであることは間違いないでしょう。
一方で、既に多くの箇所でCoroutinesを導入していたり、Coroutinesが使いやすいと感じている場合、LiveDataからCoroutinesのFlowに移行することも選択肢の1つでしょう。
CoroutinesはLiveDataより複雑で、様々なオプションを提供してくれているため、利用に戸惑うこともあると思います。
今回は、LiveDataが利用されていたようなケースでCoroutines Flowを使う場合どうしたらいいのか、細かい差分についても紹介をしていきます。
Android 12ではMaterial Youが採用されたり、スクロールのエフェクトが変わったり、スプラッシュ画面がついたりと、UI周りの変更が多く見られました。
その裏で、セキュリティやパフォーマンス等に関する内部的な変更もいくつか存在します。
今回はその中から、ActivityのLifecycleに一部変更があった点について紹介を行い、また開発者が気をつけるべき点について解説します。
Jetpack Composeを使うことで、今までのxmlベースの実装では対応が難しかったいくつかの内容に対して、実装が容易になることがあります。
その1つがレスポンシブ対応です。
タブレット端末も含めると大小様々な画面サイズのデバイスがあり、また分割画面も考慮すると、対応すべき画面サイズは膨大なものになっています。
最近は折りたたみスマートフォンも増えてきましたね。
xmlベースでのUI構築では、xmlを分けるか、ゴリゴリコードを書いて命令的に更新する必要がありました。
Jetpack ComposeはBoxWithConstraintsを使うことで簡単に対応することが出来ます。
今回はその使い方について紹介します。
Jetpack Composeの導入は、アーキテクチャについて再検討する良い機会でしょう。
GoogleはAndroid Architecture Components(AAC)のViewModelとJetpack Composeを結合する方法を解説しており、今まで通りのViewModelが利用できるとしています。一方でTwitter等ではViewModelは不要になるのでは？といった議論もされてきました。
結論から言うと、Jetpack Composeの導入によってViewModelの形や名称は変化する可能性はあるが、関心の分離の観点からUIとロジックの分離は依然として重要であり、今後もViewModelに相当するものは無くならないでしょう。
今回はJetpack Comopseを使う上で、ViewModelをどのように扱うのが良いのか、どのように変化する可能性があるのか、いくつかの考察を行ってみたいと思います。
