Android 12で変わったActivityのLifecycleの話
Android 12ではMaterial Youが採用されたり、スクロールのエフェクトが変わったり、スプラッシュ画面がついたりと、UI周りの変更が多く見られました。
その裏で、セキュリティやパフォーマンス等に関する内部的な変更もいくつか存在します。
今回はその中から、ActivityのLifecycleに一部変更があった点について紹介を行い、また開発者が気をつけるべき点について解説します。
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をどのように扱うのが良いのか、どのように変化する可能性があるのか、いくつかの考察を行ってみたいと思います。
先週、「Jetpack Compose, React, Flutter, SwiftUIを比較する」という記事で宣言的UIの各ツールの比較を行いました。
その中で、Jetpack Compose特有の特徴としてコンポーネントに返り値がないことを紹介しました。
これは、React等で遵守されてきたコンポーネントは純粋関数として扱うというルールから逸脱したものとなります。
その理由について、Jetpack Composeの開発に携わるJim SprochさんからTwitterでリプライを頂きました。
今回はその内容について1つずつ深堀りしていきます。
宣言的UIの考え方はReact、Flutter、SwiftUI、Jetpack Composeと広がり、ほぼ全てのプラットフォームで利用できるようになりました。
今までのHTMLやXMLに対して命令的に処理を書くのに対し、宣言的UIはUIの構築や更新を圧倒的に簡素にしてくれます。
また、差分更新の仕組みを備えているものも多く、パフォーマンスの向上も見込めます。
今回はいくつかある宣言的UIのツール群の中から、代表的なJetpack Compose、React、Flutter、SwiftUIを個人的な見解も含めて比較していきます。
Androidアプリ開発を行う際、公式も推奨しているViewModelを使ったアーキテクチャを採用することが多いと思います。
ViewからViewModelに処理を移動させていくと、Viewに全てを書くよりは幾分かマシになります。
一方、アプリケーションが複雑になっていくと、今度はViewModelが肥大化するという問題に直面するでしょう。
この問題は様々な要因が考えられ、解決は容易ではありません。
私自身、いつも頭を悩ましながら、コードの整理に努めています。
今回は、私が最近試みた中で比較的うまく行っている方法の中から、Modelに処理を寄せる話と、UseCaseレイヤーの話を、コードの例を交えながら紹介します。
この記事はPRです。
@mhidakaさんからお声がけ頂き、先日発売された横幕 圭真さんと釘宮 愼之介さんの本「チームで育てるAndroidアプリ設計」をレビューすることになりました。
私なりに読んで感じたこと、そして自分のアーキテクチャの育成に対する考えを書きたいと思います。
Kotlin Coroutinesの進化はすざましく、とどまるところを知りません。
状態やイベントを扱いやすくなったStateFlowやSharedFlowが登場し、さらには、Lifecycleをより扱いやすくなったLifecycleOwner.addRepeatingJobやLifecycleOwner.repeatOnLifecycle、Flow.flowWithLifecycleが追加されました。
RoomやDataStore等Jetpackの各種ライブラリでもCoroutinesが使われており、Jetpack Composeでも様々なところでCoroutinesが活用されています。
そういった中で、一部LiveDataやRxJavaからCoroutinesに書き直す動きが見られ、多少混乱を招いていると感じています。
結論から言うと、現時点において積極的にCoroutinesに移行する必要性はないと考えています。
今回は、それらを比較しつつ、どういった使い分けをするのが好ましいのか私の視点からまとめます。
Jetpack Composeのβ版が公開され盛り上がりを見せていますが、まだまだAndroidでViewを作成する際はDataBindingが主流でしょう。
DataBindingはxml内でコードを参照することでアプリのデータとUIを同期することができ、MVVMのアーキテクチャでより威力を発揮します。
BindingAdapterを使うことで、独自のプロパティを作成することも可能です。
これらは非常に便利なツールですが、アニメーションを扱う上ことは若干苦手とします。
今回はアニメーション付きのBindingAdapterを作るときの注意点と、その解決方法について紹介をします。
LiveDataは非常に便利ですが、以前も書いたとおり、hotとcoldがわかりにくい、内部がjavaのためnon nullを扱いにくい等、ところどころ不自由な点があります。
また、kotlin coroutines flowを採用している場合、どこまでflowで流して、どこでLiveDataに変換するか、という問題に直面します。
なら、いっそのことLiveDataを使わず、全てflowでMVVMを完結させられるのではないかと思い、今回試してみました。
その際に気をつけた点、気がついたこと等をまとめます。
kotlin coroutines 1.3.6にて、StateFlowというものが導入されました。
状態管理のために用いられる型で、将来的にConflatedBroadcastChannelから置き換わるとも言われています。
今回は、ドキュメントを詳しく見つつ、実際にコードを動かして特徴について見ていきたいと思います。
StateFlowもリリースされ、kotlin coroutines flowがますます存在感を増してきています。
一方、単体テスト等を書こうとした際、こういったストリームをテストするのは比較的難しいです。
今回は、僕が普段実際に使ってるテスト用utilとその使い方について紹介したいと思います。
JetpackでもRoom, Paging 3, DataStore等様々なライブラリがkotlin coroutines flowを使い始め、もはやAndroid開発にはflowが必要不可欠になってきました。
そんな中、以前紹介したStateFlowに加えて、SharedFlowが1.4.0-M1から登場しました。
少し複雑に感じますが、実はかなり整理されており、以前より使いやすくなっていると思っています。
今回は、Flow、SharedFlow、StateFlowの概要に関して紹介し、各々の詳細に関しては別途まとめたいと思います。
SharedFlowはkotlin corouteinsの1.4.0-M1で追加された新しいFlowです。
以前、Flow, SharedFlow, StateFlowの比較を行いました。
今回はSharedFlowの詳細な仕様に関して深堀りしていきたいと思います。
StateFlowはkotlin corouteinsの1.3.6で追加された状態管理用の特別なFlowです。
以前、「StateFlowのドキュメントを読み込む」という記事を書きましたが、その後SharedFlowが追加され、若干実装に変更がありました。
また、新たにstateInというoperatorも追加されています。
今回はそれらを含めたStateFlowの詳細な仕様に関して深堀りしていきたいと思います。
この記事は Kotlin Advent Calendar 2020の15日目の記事です。
非同期処理を書く際に、kotlin coroutinesは使いやすく、非常に強力です。
一方で、単体テスト等を書くのには一定のハードルがあります。
今回は、suspend functionをテストしたり、モックする方法について紹介します。