1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@pe-pe-desu(ペーペー)

kotlinについての個人的メモ

1
Last updated at Posted at 2025-07-01

元々ペーペーのとりあえずメモに記載していたが、量が多くなってきたため、こちらのページに抜き出した。

目次

バッキングフィールド (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

  • これはスコープを表している
  • アノテーションではない（←最初！アノテーションだと勘違いしてた･･･）

OptInアノテーション

コード内で特定のAPI要素を使用する際にオプトイン（承諾・認証）するには@OputIn試験運用版APIマーカーへの参照を含むアノテーションを使用する。
例えば、Jetpack Copmposeのマテリアル3を使用する時に、DateProviderオプトインが必要なクラスを使用する場合に使用する。
（現状ではまだ実験段階で、将来更新される可能性があるAPIとかを使用する場合は、同意（オプトイン）が必要）
↑
ライブラリの作成者が、API宣言時にオプトイン必須と指定している。（@RequiresOptInアノテーションが付けられている）
そのため、使用する場合には、@OptInアノテーションで使用時に同意（オプトイン）をする必要がある。

参考サイト

非同期処理の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」は不要

image.png

classの比較で「is」を付けた場合のイメージ

image.png
image.png
image.png

classの比較で「is」を付けなかった場合のイメージ

image.png
image.png

関数定義が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が値をいつまで保持しているのかのイメージ

2025-06-04_01h27_29.png
2025-06-04_01h27_40.png
2025-06-04_01h33_40.png

参考サイト

[Ｑ]イニシャライザブロックって必要なの？コンストラクタでよくない？

[A]
kotlinのコンストラクタは、Javaのコンストラクタと違って、プロパティ変数の初期化しかできず、初期化の処理の記述ができない。
そのため、コンストラクタが呼ばれた時に、処理を実行したい場合にイニシャライザブロックを使う。

initの{}で囲われた部分を「イニシャライザブロック」と言う

class クラス名 (
    var プロパティ名: 型名 = 値,
    var プロパティ名: 型名 = 値,
) {
  init {
    // イニシャライザブロック内での処理内容
  }
  
  // 処理内容
}

別な記事に書いたもの

Android関連

Java,kotlin共通

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?