元々ペーペーのとりあえずメモに記載していたが、量が多くなってきたため、こちらのページに抜き出した。
目次
- バッキングフィールド (backing field)
- set()関数のパラメータの型
- returnとかの後ろに付いてる@
- 非同期処理のjobの管理で、 CoroutineScope.isActiveよりも厳密に状態を管理できる方法
- KotlinのeveryとcoEveryの違い
- when句での比較で使う「is」のイメージ
- 関数定義が1つだけのinterfaceは fun interface で定義できる
- Jetpack Compose、Android View
- remember
- 別な記事に書いたもの
バッキングフィールド (backing field)
- 「setter()を介して、最終的にデータが格納される先」のこと
- 必要な時にkotlinにより自動で宣言され、開発者が自分で宣言することはない
- プロパティの一部としてのみ使用され、メモリ内に値を保持する役割がある
- setter()は、フィールドに
set(value)のvalueの値を代入する
プロパティ
- Javaでいうところのフィールドとgetter()、setter()メソッドに相当する機能
- Javaではクラス内で宣言された変数（フィールド）に対して、getter()とsetter()を宣言するが、これを一度に全てできるのがバッキングプロパティ（の宣言）
set()関数のパラメータの型
- set()関数のパラメータvalueには、変数の型が明示されていない
→set()関数のパラメータの型は、kotlinで予測してくれるため、わざわざプログラマが明示する必要は無い
例）string型のnameのsetter()
→パラメータとして渡してくれるvalueというう変数も当然string型
returnとかの後ろに付いてる@
こうゆうの↓
return @runBlocking
- これはスコープを表している
- アノテーションではない（←最初！アノテーションだと勘違いしてた･･･）
非同期処理のjobの管理で、 CoroutineScope.isActiveよりも厳密に状態を管理できる方法
-
mutex.tryLock()を使う
なぜmutex.tryLockを使った方がいいのか
- jobの以下のような実装の場合「①
coroutineScope.lanch(Dispatchers.IO){処理}の処理を実行する」のと「②Job型の変数に代入する」というのに分かれている。
そのため、タイミングが悪いと①が終わっているのに、②が終わっていなくて、job.isActiveの結果がtrueになる可能性がある。
val job:Job = scope.launch(Dispatchers.IO){
// 非同期処理
println("Hello, world")
}
-
mutex.tryLock()は必ず1つのmutexだけがlockされることが確約されている
また、mutexのlockを解除するときは、mutex.unLock()で実装者が明示的にlockを解除する
必要があるため、lockが解除されるタイミングがコード上で分かりやすい。
以上のことから、mutexを使った方がタイミングのずれによる問題が起きない。
参考
KotlinのeveryとcoEveryの違い
every：通常の関数をモックするために使用
（非同期処理のモックは作れない）
coEvery：suspend関数（コルーチン）をモックするために使用する
（非同期処理のモックを作りたかったらこっち）
when句での比較で使う「is」のイメージ
objectの比較では「is」は不要
classの比較で「is」を付けた場合のイメージ
classの比較で「is」を付けなかった場合のイメージ
関数定義が1つだけのinterfaceは fun interface で定義できる
Jetpack Compose、Android View
- なるべく、親の要素に要素の位置の指定をやらせる
-
pxが、粒の数 -
Dpが、固定の長さ（長さのcmみたいなイメージ）
| Android View | Jetpack Compose |
|---|---|
| ConstraintLayout | Boxみたいなイメージ |
| LinearLayout | Columnみたいなイメージ |
remember
- rememberもComposable関数
-
rememberの()なし＝再評価のタイミングを与えない
↑初期描画時の評価のみ行う - 再評価＝中括弧{}の中の処理
sample1.kt
var isSuccess by remember {
Log.d("ample", "debug") // 初期描画時(初回コンポーズ時)にしかログ出力されない
}
- 何かのタイミングで{}の中の処理を実行させたいときはrememberの()ありにして、再評価のタイミングを与えてあげる必要がある
- ()の中を監視して、もし()の中に動きがあったら、{}の中の処理を実行する
sample2.kt
val eventHoge = remember(event) {
Log.d("sample2", "debug") // eventが変化するたびにログ出力される
}
- LaunchedEffect↑と同じ感じ
- ()の中を監視して、もし()の中に動きがあったら、{}の中の処理を実行する感じ
rememberが値をいつまで保持しているのかのイメージ
参考サイト
別な記事に書いたもの
- kotlinのList.fastZip()ってなんぞ？（個人的な覚書）
- kotlinのUnitTestはrunTestを使うといいかも
- kotlin - 関数の引数がラムダ式の場合のラムダ式の型の見方、関数の使い方
- Kotlinのfactoryってなに？
- Kotlinのinvoke()ってなに？
- KotlinでNULLではない場合に処理をしたい時
- List<>よりも、ImmutableList<>を使った方が、パフォーマンスが上がる
- 監視可能なデータホルダー クラス-LiveDataとStateFlowの覚え書き
Android関連
- Androidアプリの構成
- AndroidのDBのマイグレーションとは
- Androidアプリ開発の個人メモ
- jetbrains ToolBoxを使ったAndroid Studioの導入方法メモ
- Roomが「DatabaseのVersionが違う」とクラッシュしてしまう原因パターン
- Android Studioについての個人メモ
- Android Studio をアップグレードしたら失敗した「AOP 起動トランスフォーマーの開始に失敗しました」