Kong-droid

[Android] SharedPreferences 대신 DataStore #2

콩드로이드 — Thu, 25 Dec 2025 20:59:56 +0900

DataStore는 암호화를 자동으로 제공 X

DataStore를 사용할 때 가장 주의해야 할 부분인 거 같습니다

토큰
사용자 식별 정보
개인정보

만약 위와 같은 값들을 그대로 저장하면 루팅된 기기나 백업 파일을 통해 노출될 가능성이 있습니다,,

그래서 암호화 작업이 필요해요

EncryptedSharedPreferences Deprecated

원래는 EncryptedSharedPreference가 공식 대안이었지만, 현재는 Deprecated 되었습니다

대신 Jetpack Security (Crypto API)와 DataStore의 조합이 권장되었습니다!

Crypto API를 사용해서 DataStore를 암호화해서 사용하는 방법에 대해 알아보겠습니다

Crypto API

코드는 단순 예시라서 사용 플로우만 확인하면 좋을 거 같습니다..!

라이브러리 추가

implementation("androidx.security:security-crypto:1.1.0-alpha06")

Master Key 생성

MasterKey는 암호화/복호화에 직접 사용되는 키라기보다는, Android Keystore에 저장되는 최상위 키 역할입니다

즉, MasterKey를 통해 Android Keystore에 위임되기 때문에 키가 코드나 저장소에 노출되는 것을 방지할 수 있습니다

private fun getMasterKey(context: Context): MasterKey {
    return MasterKey.Builder(context)
        .setKeyScheme(MasterKey.KeyScheme.AES256_GCM)
        .build()
}

암호화/복호화

암호화

fun encrypt(
    context: Context,
    plainText: String
): String {
    val masterKey = getMasterKey(context)

    val keyStore = KeyStore.getInstance("AndroidKeyStore").apply {
        load(null)
    }

    //MasterKey가 관리하는 실제 SecretKey 가져오기,,
    val secretKey = keyStore.getKey(masterKey.keyAlias, null) as SecretKey

    val cipher = Cipher.getInstance("AES/GCM/NoPadding")
    cipher.init(Cipher.ENCRYPT_MODE, secretKey)

    val iv = cipher.iv
    val encryptedBytes = cipher.doFinal(plainText.toByteArray(Charsets.UTF_8))

    val combined = ByteArray(iv.size + encryptedBytes.size)
    System.arraycopy(iv, 0, combined, 0, iv.size)
    System.arraycopy(encryptedBytes, 0, combined, iv.size, encryptedBytes.size)

    return Base64.encodeToString(combined, Base64.DEFAULT)
}

복호화

fun decrypt(
    context: Context,
    encryptedText: String
): String {
    val masterKey = getMasterKey(context)

    val keyStore = KeyStore.getInstance("AndroidKeyStore").apply {
        load(null)
    }

    val secretKey = keyStore.getKey(masterKey.keyAlias, null) as SecretKey

    val combined = Base64.decode(encryptedText, Base64.DEFAULT)

    val iv = combined.copyOfRange(0, 12)
    val encryptedBytes = combined.copyOfRange(12, combined.size)

    val cipher = Cipher.getInstance("AES/GCM/NoPadding")
    val spec = GCMParameterSpec(128, iv)
    cipher.init(Cipher.DECRYPT_MODE, secretKey, spec)

    val decryptedBytes = cipher.doFinal(encryptedBytes)
    return String(decryptedBytes, Charsets.UTF_8)
}

DataStore에 암호화 적용하기

저장

suspend fun saveEncryptedToken(
    context: Context,
    token: String
) {
    val encrypted = encrypt(context, token)
	
    context.dataStore.edit { prefs ->
        prefs[stringPreferencesKey("저장할 때 쓸 키 값")] = encrypted
    }
}

불러오기

fun getDecryptedToken(
    context: Context
): Flow<String?> {
    return context.dataStore.data.map { prefs ->
        prefs[stringPreferencesKey("저장할 때 썼던 키 값")]
            ?.let { decrypt(context, it) }
    }
}

암호화를 사용해서 어떻게 저장하는지 간단한 예시로 알아봤어요 ..!

DataStore에 저장하고 불러오는 모든 값을 암호화할 필요는 없지만, 아래와 같은 노출되면 안 되는 정보들은 암호화가 필수입니다

Access Token / Refresh Token
사용자 식별 정보
이메일, 전화번호 등 개인정보

[Android] SharedPreferences 대신 DataStore #1

콩드로이드 — Sun, 23 Nov 2025 16:54:13 +0900

DataStore를 이번에 처음 제대로 써봤습니다..!

SharedPreferences → EncryptedSharedPreferences → DataStore로 왜 넘어가야 하는지 궁금해서 정리해봤어요!

SharedPreferences가 왜 더 이상 추천되지 않을까 ?

1. 동기 방식이므로 ANR 위험성이 존재

: commit() / apply() 모두 파일 I/O 기반

commit() → 동기(blocking), 완료될 때까지 UI Thread 멈춤
apply() → 비동기처럼 보이지만 디스크 I/O는 백그라운드에서 처리

사실 자주 발생하진 않을 것 같은데, 저장량이 많거나 여러 쓰기 요청이 한 번에 몰리면 영향이 있을 수 있습니다

2. 앱 내부 저장소에 XML 파일 형태로 저장되므로 값이 그대로 노출

: 이를 해결하기 위해 공식으로 지원되는 EncryptedSharedPreferences 가 있었는데 Deprecated됨

-> 이러한 이유들로 현재 구글에서 공식적으로 권장하는 방법은 DataStore를 사용하는 것입니다

DataStore란 ?

SharedPreferences의 XML 기반·동기 저장 방식을 개선한 Jetpack 기반 비동기 Key-Value 저장소입니다 (Binary 포맷으로 저장)

사용법은 아래와 같습니다

1️⃣ library 연동

//toml 파일에 선언
datastore = { group = "androidx.datastore", name = "datastore-preferences", 
	version.ref = "datastore"} // 1.1.1 사용
    
//build.gradle(app) 선언
implementation(libs.datastore)

2️⃣ Context기반으로 접근가능한 datastore 생성

val Context.dataStore by preferencesDataStore(
    name = "test_datastore" // datastore 명칭
)

3️⃣ 비동기 형태로 save, get 함수 생성

DataStore는 기본적으로 비동기 + 코루틴 기반이라, 값을 저장할 때도 suspend, 가져올 때는 Flow로 동작

suspend fun <T> save(
    context: Context,
    key: Preferences.Key<T>,
    value: T
) {
    context.dataStore.edit { prefs ->
        prefs[key] = value
    }
}


fun <T> get(
    context: Context,
    key: Preferences.Key<T>
): Flow<T?> {
   return context.dataStore.data.map { prefs ->
       prefs[key]
   }
}

4️⃣ 저장, 불러오기

//위에서 생성한 함수 사용
/
save(context, stringPreferencesKey("token"), "토큰값")

get(context, stringPreferencesKey("token"))

사용법은 생각보다 꽤 간단했어요!

정리해보자면, SharedPreference와 DataStore의 차이는 아래와 같습니다

	SharedPreference	DataStore
구조	XML 파일	Binary file
I/O 방식	동기	완전 비동기(Coroutine + Flow)
스레드 안전성	완벽히 안전하지 않음	철저히 스레드-safe
대용량 처리	비효율적	Stream 기반으로 안전하게 처리
타입 안정성	key-string 기반 , 비교적 느슨	키 자체에 타입 존재

여기서 각각 타입 안정성만 좀 확인해보자면,

[SharePreference] : 다른 타입 가져오려고 하면 런타임에서 오류 발생

val prefs = context.getSharedPreferences("test", Context.MODE_PRIVATE)

prefs.edit()
    .putString("age", "20")   // age에 스트링 저장 
    .apply()


//값을 가져올 때 
val age: Int = prefs.getInt("age", 0)  //런타임에서 ClassCastException

[DataStore] : 타입 미일치 시 컴파일에서 오류 발생

왜냐하면, DataStore는 키가 타입을 정의하기 때문에, 저장할 때도, 읽을 때도 컴파일 단계에서 오류를 잡아줍니다!

object PrefKeys {
    val AGE = intPreferencesKey("age")
    val NICKNAME = stringPreferencesKey("nickname")
}

prefs[PrefKeys.AGE] = "20"  //int에 string 넣으려고 해서 컴파일타임에서 오류

하지만, DataStore도 암호화가 자동으로 지원되진 않기 때문에 민감 정보 저장 시 권장사항은 Crypto API 와 DataStore를 같이 쓰는 것입니다

모든 정보를 암호화할 필욘 없지만 토큰과 같은 민감정보들, 그리고 개인정보들은 암호화를 사용해야겠죠..!

암호화 방법에 대해서는 2탄 포스팅으로 돌아오겠습니다!

[Android] ForegroundService - SecurityException

콩드로이드 — Fri, 24 Oct 2025 20:28:43 +0900

Caused by: java.lang.SecurityException: Starting FGS with type microphone

service 실행 중 SecurityException이 발생했었는데, 원인을 살펴보면 Android 14부터 강화된 Foreground Service(이하 FGS) 정책과 관련된 경우였습니다

우선 Android 14와 무관하게, 서비스 실행 시점이 foreground 상태가 아닐 경우 FGS 관련 SecurityException이 발생합니다.

(이 포스팅에서는 이 부분은 제외하고, Android 14 변경사항 위주로 정리해볼게요..!)

Android 14부터는 아래의 특정 FGS 유형(Foreground Service Type) 에 대해 추가적인 조건이 요구됩니다

camera, connectedDevice, dataSync, health, location, mediaPlayback, mediaProjection

microphone, phoneCall, remoteMessaging, shortService, specialUse, systemExempted

1. android:foregroundServiceType 지정 (AndroidManifest.xml)

Android10에서는 service를 사용할 때 manifest에서 android:foregroundServiceType을 지정할 수 있었다면,

Android14에서는 특정 권한들은 아래와 같이 android:foregroundServiceType 지정이 필수가 되었습니다

  <service android:name="서비스 클래스명"
           android:foregroundServiceType="dataSync"/>

Manifest에서 특정 서비스의 유형을 정의하지 않으면 시스템은 해당 서비스의 startForeground() 호출 시 MissingForegroundServiceTypeException을 발생할 수 있습니다,,

2. startForeground()호출 시 타입 명시

startForeground(NOTIFICATION_ID, notification, ServiceInfo.FOREGROUND_SERVICE_TYPE_CAMERA)

Manifest에 정의된 타입과 startForeground() 호출 시 지정한 타입이 일치해야 시스템이 서비스 목적을 명확히 인식하고 권한 검사를 올바르게 수행합니다

3. Runtime 권한(Prerequisites) 확인

Android 14에서는 포그라운드 서비스 유형(Foreground Service Type)에 따라 런타임에서 반드시 충족해야 하는 권한 조건이 추가되었습니다.

예를 들어,

FOREGROUND_SERVICE_TYPE_LOCATION → ACCESS_COARSE_LOCATION 또는 ACCESS_FINE_LOCATION
FOREGROUND_SERVICE_TYPE_CAMERA → CAMERA
FOREGROUND_SERVICE_TYPE_MICROPHONE → RECORD_AUDIO

startForeground() 호출 시, 해당 서비스 유형에 맞는 런타임 권한이 이미 허용되어 있는지를 검사합니다.

즉, 앱이 아직 권한을 요청하거나 승인받기 전 상태에서 startForeground()를 호출하면 SecurityException이 발생합니다.

정리하자면 Android 14에서는 포그라운드 서비스의 유형 선언, 권한 요청 시점이 모두 명확해야 합니다
Manifest, startForeground(), 권한 요청 시점 — 이 세 개가 맞물리지 않으면 SecurityException이 발생할 수 있어요

공식 문서를 살펴보면 아래와 같이 각각 어떤 값을 설정해줘야하는지 나와있습니다

특정 FGS 유형를 사용하시는 경우엔 공식문서에서 요건들을 확인하면 될 거 같습니다

[Android] AudioManager와 isSpeakerPhoneOn Deprecated

콩드로이드 — Sat, 18 Oct 2025 08:51:30 +0900

AudioManager란?

AudioManager는 안드로이드에서 오디오 장치 제어, 상태 관리를 하는 시스템 서비스입니다

보통 이럴 때 사용합니다

블루투스, 이어폰, 수화기, 스피커 등 오디오 출력 장치 전환
마이크 음소거, 볼륨 제어
오디오 모드 설정 (MODE_NORMAL, MODE_IN_CALL, MODE_IN_COMMUNICATION 등)

⚠️ isSpeakerphoneOn의 deprecated

Android 14 (API 34, UpsideDownCake)부터 audioManager.isSpeakerphoneOn과 audioManager.setSpeakerphoneOn()이 deprecated 됐습니다..

이전 방식은 스피커폰이 켜져 있다는 단일 상태만 다뤘지만, 다양한 오디오 장치가 나온 만큼, 어떤 장치로 출력 시킬지 정하는 방식이 되었어요

이제는 availableCommunicationDevices 리스트를 통해 사용 가능한 오디오 장치들을 가져와서 직접 설정을 해줘야해요

아래 예시는 스피커 모드 on / off 입니다

private fun toggleSpeakerMode(turnOn: Boolean) {
    val audioManager = requireContext().getSystemService(Context.AUDIO_SERVICE) as AudioManager
    audioManager.mode = AudioManager.MODE_IN_COMMUNICATION

    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.UPSIDE_DOWN_CAKE) {
        var speakerDevice: AudioDeviceInfo? = null
        val devices = audioManager.availableCommunicationDevices
        for (device in devices) {
            if (device.type == AudioDeviceInfo.TYPE_BUILTIN_SPEAKER) {
                speakerDevice = device
                break
            }
        }
        if (speakerDevice != null) {
            if (turnOn) {
                audioManager.setCommunicationDevice(speakerDevice)
                //특정 오디오 장치로 통화 음성을 출력
            } else {
                audioManager.clearCommunicationDevice()
            }
        }
    } else {
        // 구버전 호환
        audioManager.isSpeakerphoneOn = turnOn
    }
}

이제 출력장치를 정할 수 있는데, 단말기로 볼륨을 조절 할 때는 사용하고 있는 Stream의 볼륨이 조절됩니다

stream의 종류는 아래와 같습니당

stream 종류	설명
STREAM_MUSIC	음악, 영상, 게임 등 일반 미디어
STREAM_VOICE_CALL	통화, VoIP
STREAM_RING	전화벨 소리
STREAM_ALARM	알람음
STREAM_NOTIFICATION	알림음
STREAM_SYSTEM	시스템 UI 소리

보통 자동으로 사용중인 스트림의 보륨이 조절되는데, 좀 특이한 경우들이 있어요

VoIP나 직접 오디오트랙을 관리하는 경우엔 모드를 설정해줘야 스트림의 볼륨조절이 가능합니다

AudioManager에서 아래와 같이 모드를 지정해야 합니다

audioManager.mode = AudioManager.MODE_IN_COMMUNICATION

볼륨조절을 하는 스트림을 명시적으로 설정할 수도 있는데, 자동으로 잘 붙어요

requireActivity().volumeControlStream = AudioManager.STREAM_VOICE_CALL

(참고) Mode 종류는 아래와 같습니다

Mode 종류	설명	사용 예시	매핑 Stream
MODE_NORMAL (기본)	일반 오디오 재생	대부분의 앱(음악, 영상, 게임, 효과음)	STREAM_MUSIC
MODE_RINGTONE	전화 벨소리 재생 모드	벨소리	STREAM_RING
MODE_IN_CALL	통신사를 통한 통화	시스템/기본 전화앱 전용	STREAM_VOICE_CALL
MODE_IN_COMMUNICATION	VoIP/WebRTC 등 네트워크 기반 통화	Zoom/Discord/게임 보이스챗/Chime 등 네트통 음성	STREAM_VOICE_CALL로 자동 매핑
MODE_CALL_SCREENING	수신전화 콜 스크리닝 중 오디오	기본 다이얼러/콜스크리닝 앱	STREAM_VOICE_CALL

[Android] 소켓 연결하기 - WebSocket , Socket.IO

콩드로이드 — Sat, 27 Sep 2025 16:49:35 +0900

Socket IO를 사용할 일이 있었는데, 웹소켓과 Socket IO에 대해 정리해보면 좋을 거 같아서 정리를 해봅니다

모두 실시간 양방향 통신을 위해 사용되지만, 내부 구조와 동작 방식에는 분명한 차이가 있어요

이번 포스팅에서는 WebSocket과 Socket.IO의 차이점, 그리고 각각을 Android에서 어떻게 연결해야하는지에 대해 알아보겠습니다

	WebSocket	Socket IO
프로토콜	순수 WebSocket 프로토콜 (RFC 6455)	WebSocket 기반 + 추가 기능 (자체 프로토콜)
통신 방식	단순한 양방향 통신	양방향 통신 + 이벤트 기반 통신
재연결 지원	기본적으로 없음 (직접 구현해야 함)	자동 재연결 내장 (reconnect = boolean 으로 설정)
Fallback 지원	없음	WebSocket이 안 되면 HTTP long polling 사용 가능
브로드캐스트	직접 구현 필요	기본 지원 (io.emit, socket.broadcast.emit)

WebSocket은 낮은 수준의 통신 채널이고, Socket.IO는 그 위에 올라가는 고수준 프레임워크

즉 Socket IO도 웹소켓을 기반으로 하지만 프로토콜이 다르기 때문에 연결 방식이 다름

그러므로 서버가 Socket.IO 기반이라면 클라이언트도 Socket.IO 클라이언트를 사용해야 정상적인 통신이 가능

WebSocket 연결

1. 라이브러리 추가

implementation("com.squareup.okhttp3:okhttp:4.12.0")

2. 연결

val client = OkHttpClient()

val request = Request.Builder()
    .url(연결할 소켓 주소)
    .build()

val listener = object : WebSocketListener() {
    override fun onOpen(webSocket: WebSocket, response: Response) {
        // 연결 성공 시
    }

    override fun onMessage(webSocket: WebSocket, text: String) {
        // 서버로부터 메시지를 수신했을 때
    }

    override fun onFailure(webSocket: WebSocket, t: Throwable, response: Response?) {
       // 에러 발생 시
    }
}

val webSocket = client.newWebSocket(request, listener)

Request에서는 주소 외에도 헤더, 쿠키 등 옵션을 지정

client.newWebSocket()을 호출하면 즉시 비동기적으로 연결 시도가 시작
→ SocketIO와 달리 별도의 .connect()를 호출할 필요는 없습니다.

연결 결과는 WebSocketListener 콜백을 통해 확인

3. 서버로 메시지 전송 시

webSocket.send(미리 약속된 형식의 데이터)

//string
webSocket.send("Hello World!")


//json
val json = """
    {
        "type": "chat",
        "message": "Hello"
    }
""".trimIndent()
webSocket.send(json)

서버와 약속된 형식(JSON 등)에 맞춰 데이터를 전송해야함

전송 가능한 데이터 타입

String
JSON 형식 문자열
Binary Data

Socket IO 연결

1. 라이브러리 연결

implementation("io.socket:socket.io-client:2.1.2")

2. 소켓 생성 및 연결

import io.socket.client.IO
import io.socket.client.Socket
import org.json.JSONObject

lateinit var mSocket: Socket

try {
    mSocket = IO.socket(연결할 소켓 주소 )
} catch (e: URISyntaxException) {
    e.printStackTrace()
}

mSocket.on(Socket.EVENT_CONNECT) {
  //
}

mSocket.on("message") { args ->
    // 서버에서 내려오는 메시지가 찍히는 부분
    // args로 payload를 가져올 수 있습니다,,
}

mSocket.connect()

3. 서버로 메시지 전송 시

mSocket.emit(미리 약속된 이벤트명, 보낼 데이터)

Socket.IO는 이벤트 기반 통신이기 때문에, 약속된 이벤트 이름 + 데이터 형태로 메시지 전송
전송 가능한 데이터는 대부분의 기본 타입이 포함

안드로이드는 서버의 상황에 따라 가게 되지만..

Socket.IO는 자체 프로토콜을 사용하기 때문에 서버와 클라이언트는 반드시 같은 방식으로 구성되어야 하고,
WebSocket은 표준 프로토콜이라서 다양한 플랫폼에 독립적으로 연결할 수 있는 장점이 있지만, 그만큼 기능은 단순하고 직접 구현해야할 부분이 많다는 단점이 있다

[Android] 하나의 화면에 다양한 UI 블록을 구성하는 3가지 방식

콩드로이드 — Mon, 28 Jul 2025 21:55:26 +0900

앱 만들다 보면 한 화면에 여러 종류의 UI를 스크롤 되게 구성해야 할 일이 자주 생기는데,
이런 경우에 사용하는 3가지 방식에 대해 알아보겠습니다

FragmentContainerView 방식 (Fragment 삽입)

특징

각 UI 블록을 Fragment로 나눠서 FragmentContainerView에 삽입
고정된 레이아웃이나, 특정 위치에 동적으로 fragment를 붙이는 방식

장점

각 블록마다 생명주기, ViewModel 분리 가능
로직이 복잡하거나 독립된 기능일 경우 구조화에 유리

단점

fragment가 많아지면 성능 저하 발생
ScrollView 안에 fragment 여러 개 → 비추천 구조 (nested fragment 문제 등)

[layout]

<ScrollView
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <LinearLayout
        android:orientation="vertical"
        android:layout_width="match_parent"
        android:layout_height="wrap_content">

        <androidx.fragment.app.FragmentContainerView
            android:id="@+id/bannerFragmentContainer"
            android:layout_width="match_parent"
            android:layout_height="wrap_content" />

        <androidx.fragment.app.FragmentContainerView
            android:id="@+id/listFragmentContainer"
            android:layout_width="match_parent"
            android:layout_height="wrap_content" />

    </LinearLayout>
</ScrollView>

[activity]

  supportFragmentManager.beginTransaction()
            .replace(R.id.bannerFragmentContainer, BannerFragment())
            .commit()

  supportFragmentManager.beginTransaction()
            .replace(R.id.listFragmentContainer, ItemListFragment())
            .commit()

addLayout()방식

특징

API 응답을 순회하며 뷰를 직접 생성해서 addView()로 붙이는 방식
LinearLayout이나 ConstraintLayout 안에서 뷰 조합

장점

구조가 단순하고 유연함 (서대로 뷰만 붙이면 됨)
빠르게 화면 만들기 좋고, 레이아웃 순서를 동적으로 바꾸기도 쉬움

단점

뷰 재사용이 안 되기 때문에 수가 많아지면 성능 저하
코드가 복잡해지기 쉬움 (뷰, 데이터, 로직이 뒤엉김)

[layout]

<ScrollView
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <LinearLayout
        android:id="@+id/container"
        android:orientation="vertical"
        android:layout_width="match_parent"
        android:layout_height="wrap_content" />
</ScrollView>

[activity]

class MainActivity : AppCompatActivity() {

    private lateinit var container: LinearLayout

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        
        container = findViewById(R.id.container)

        val titles = listOf("Title 1", "Title 2", "Title 3")

        titles.forEach { title ->
            val textView = TextView(this).apply {
                text = title
                textSize = 20f
                setPadding(16, 16, 16, 16)
            }
            container.addView(textView)
        }
    }
}

RecyclerView + ViewType 방식

특징

다양한 UI 블록을 ViewType으로 분기해서 하나의 RecyclerView로 구성
ViewHolder 기반으로 뷰 재사용 가능

장점

성능 최고 (뷰 재사용, ViewHolder 풀링)
각 타입별로 클래스 분리 가능 → 유지보수, 테스트 용이
구조화된 패턴으로 확장성 높음

단점

초기 설계가 조금 번거롭다 (ViewType 정의, sealed class 설계..)

[layout]

<androidx.recyclerview.widget.RecyclerView
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:id="@+id/recyclerView"
    android:layout_width="match_parent"
    android:layout_height="match_parent" />

[adapter]

sealed class UiModel {
    data class Title(val text: String) : UiModel()
    data class Image(val url: String) : UiModel()
}

class MultiViewAdapter(private val items: List<UiModel>) : RecyclerView.Adapter<RecyclerView.ViewHolder>() {

    override fun getItemViewType(position: Int): Int {
        return when (items[position]) {
            is UiModel.Title -> 0
            is UiModel.Image -> 1
        }
    }

    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): RecyclerView.ViewHolder {
        return when (viewType) {
            0 -> TitleViewHolder(LayoutInflater.from(parent.context).inflate(android.R.layout.simple_list_item_1, parent, false))
            else -> ImageViewHolder(ImageView(parent.context))
        }
    }

    override fun getItemCount() = items.size

    override fun onBindViewHolder(holder: RecyclerView.ViewHolder, position: Int) {
        when (val item = items[position]) {
            is UiModel.Title -> (holder as TitleViewHolder).bind(item.text)
            is UiModel.Image -> (holder as ImageViewHolder).bind(item.url)
        }
    }

    class TitleViewHolder(view: View) : RecyclerView.ViewHolder(view) {
        fun bind(text: String) {
            (itemView as TextView).text = text
        }
    }

    class ImageViewHolder(private val imageView: ImageView) : RecyclerView.ViewHolder(imageView) {
        fun bind(url: String) {
            imageView.setImageResource(android.R.drawable.ic_menu_gallery)
        }
    }
}

[activity]

  val recyclerView: RecyclerView = findViewById(R.id.recyclerView)

        val items = listOf(
            UiModel.Title("Hello"),
            UiModel.Image("https://example.com/image1.jpg"),
            UiModel.Title("World"),
            UiModel.Image("https://example.com/image2.jpg")
        )

        recyclerView.layoutManager = LinearLayoutManager(this)
        recyclerView.adapter = MultiViewAdapter(items)

각각 3가지 타입이 있는데,

기능 단위로 분리하고 싶고, 각각 UI가 독립적이면 → FragmentContainerView
뷰 몇 개 순서대로 붙이기만 하면 되면 → addLayout()
여러 UI 타입이 섞여 있고 리스트가 길어질 수 있으면 → RecyclerView + ViewType

이 와중에 FragmentContainerView랑 recyclerview가 각각 언제 사용되면 좋은지 좀 헷갈렸는데,

이 블록이 미니 화면처럼 동작하고 독립적으로 동작해야 한다? : FragmentContainerView
(ex. 영상 플레이어, 지도 등)
그냥 여러 UI를 스크롤되게 보여주고 성능도 중요하다? : RecyclerView + ViewType
(ex. 홈피드, 뉴스 피드, 상품 리스트 등)

이렇게 생각하면 이해가 편하더라구요!

[Android] NetworkInfo Deprecated

콩드로이드 — Fri, 6 Jun 2025 12:31:10 +0900

과거 방식: NetworkInfo → 이제는 ❌

예전 사용법

val cm = context.getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager
val networkInfo = cm.activeNetworkInfo
val isConnected = networkInfo?.isConnectedOrConnecting == true

하지만 이 방식은 API 29(Android 10) 부터 deprecated

단순히 연결 유무만 알 수 있고, 인터넷 실제 연결 상태는 확인 불가
ex) Wi-Fi는 연결되었지만 인터넷이 안 터지는 경우에도 true로 찍힘,,
Android의 Doze Mode, App Standby, VPN, 제한 네트워크 등 새로운 개념을 반영 못 함

→ 더 정확한 NetworkCapabilities 기반 방식으로 변경됨

NetworkCapabilities

실제로 인터넷 연결 가능한지 확인

fun isNetworkAvailable(context: Context): Boolean {
    val connectivityManager = context.getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager
    val network = connectivityManager.activeNetwork ?: return false
    val capabilities = connectivityManager.getNetworkCapabilities(network) ?: return false
    return capabilities.hasCapability(NetworkCapabilities.NET_CAPABILITY_INTERNET)
}

activeNetwork → 현재 기기에서 실제로 연결되어 있는 네트워크를 의미함
hasCapability(NetworkCapabilities.NET_CAPABILITY_INTERNET)→ 그중에서도 "인터넷에 연결 가능한지" 여부를 확인하는 메서드
getNetworkCapabilities(network) → 해당 네트워크가 지원하는 기능들(인터넷 가능 여부, Wi-Fi인지 등)을 확인 가능

네트워크 연결 변화 감지하는 방식 (callback 기반)

- 위에서의 기능은 함수를 실행하는 시점의 네트워크 연결 여부를 판단한다면,

이 callback은 네트워크 변화를 추적할 수 있음 !! 다만 콜백 해제에 유의해야함 !

val callback = object : ConnectivityManager.NetworkCallback() {
    override fun onAvailable(network: Network) {
        Log.d("Network", "인터넷 사용가능")
    }

    override fun onLost(network: Network) {
        Log.d("Network", "인터넷 끊김")
    }
}

val cm = context.getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager
val request = NetworkRequest.Builder().build()
cm.registerNetworkCallback(request, callback)

입사 3개월차의 회고록

콩드로이드 — Sat, 31 May 2025 14:38:35 +0900

어느덧 3개월차...?

정말 정신없이 입사해서 여유가 하나도 없었는데, 어느덧 입사한 지 3개월..!
처음엔 모르겠는 것들 투성이였는데, 이제야 조금 적응해가고 있다는 느낌 ㅎㅅㅎ
그래서 한번,
그동안의 기록을 남겨보려고 합니다 ✍️

내가 새롭게 해본 것들

입사하고 나서 실무에서 처음으로 다뤄본 기술들이 많았어요 ~~역시 배움에 끝이란 없다..~~

Jetpack Compose
SDK 멀티모듈
자동화 스크립트
안드로이드 위젯
InstallReferrer
Notification에 다양한 스타일 입혀보기

하나하나 처음엔 어렵고 걱정이 너무 앞섰지만,
지금은 “아! 그건 내가 해봤어” 라고 말할 수 있을 정도 !?
→ ‍ 으로 성장 중,,,,
그래도 처음이란 두려움보다 이제 그래 해보지 뭐! 라는 마인드가 되었다는게 너무나도 큰 수확같아요

앞으로 나아갈 것들

사실 예전엔 당연하다고 생각한 코드들,
막상 속을 들여다보면 성능적으로 손해 보는 구조일 때가 있어서 차근차근 메모를 남겨나가는 중입니다
그리고 코틀린

구조 분해
고차 함수
람다

이런 문법들은 꽤 손에 익었어요
나아가서 이젠 사용 전에 “왜 이렇게 써야 하지?” 를 생각하게 된 게 큰 변화 중 하나입니다..!
그리고 ..! 같이 고민해주는 분들이 있는 게 정말 큰 안정감을 주어서 더 열심히 해야지 하는 원동력이 되는 거 같아요

스스로 아쉬웠던 점

일정 산출... 그게 젤 어려워요 아직도 진행 중..
주체적으로 일정을 정해본 적이 드물기에, 이런 산출이 정말 어려웠습니다
그래도 팀장님의 도움하에 조금씩 산출해보고 있어요 좀 더 익으면 쉽게 쉽게 되겠죠,,?
그리고 또, 쓰고 있는 기술뿐만 아니라 다양한 기술들도 조금씩 접목해 볼 것..!!
너무 급하게 생각하지 말 것! ! !

☀️ 마무리

3개월밖에 안 됐는데도 정말 많은 걸 보고, 배우고, 느꼈습니다
익숙하지 않음을 견디다 보면, 어느 순간 내가 조금은 익숙해져 있는 게 느껴지더라구요
앞으로도
“모른다 → 해본다 → 익숙해진다”
이 흐름을 반복하며 쌓아갈 수 있으면 좋겠어요
역시 기록은 쌓이면 뭐든 됩니다 :)

[Android] MVI 패턴, 이름을 왜이렇게 헷갈리게 지었어요?

콩드로이드 — Tue, 27 May 2025 21:43:34 +0900

MVI란?

MVI는 Model - View - Intent

여기서 말하는 Intent는 Android Intent가 아니라 !!!

“사용자의 의도(Intent)부터 상태(State) 변경까지 이어지는 흐름 전체”를 뜻하는 개념적인 용어,,

❗️그러니까 MVI의 Intent ≠ UIEvent ≠ 안드로이드 Intent → 절대 헷갈리면 안된다..

MVI 흐름

[사용자 행동 (UIEvent)]
→ ViewModel이 받음
→ 상태(UIState) 변경 or 효과(UIEffect) 발생
→ View가 변화됨

- 이 흐름의 출발점은 항상 UIEvent

- 화면은 항상 UIState 하나로만 관리

자주 사용되는 타입들

UIState	현재 화면의 상태 (ex. 키워드, 로딩 중, 결과 등)	data class
UIEvent	사용자 액션 (ex. 버튼 클릭, 키 입력 등)	sealed class
⚡ UIEffect	Toast, 화면 이동 등 일회성 처리	sealed class

MVI의 구성요소는 아니고, MVI를 Android에서 구현할 때 자주 등장하는 타입들

왜 타입이 다를까?

- UIState → data class

현재 화면의 상태를 나타내는 데이터 덩어리 라서 → data class로 관리
일부만 바꿀 땐 copy()로 간편하게 처리 가능

val newState = oldState.copy(keyword = "아몬드")

이렇게 하면 상태도 immutable하게 유지되고, Compose에서 recomposition도 정확히 됨

- UIEvent, UIEffect → sealed class

사용자 액션이나, 그에 따른 동작이 다양하니 → sealed class로 묶어 관리

sealed class BookSearchEvent {
    data class SearchKeywordChanged(val keyword: String) : BookSearchEvent()
    object SearchButtonClicked : BookSearchEvent()
    data class BookClicked(val bookId: String) : BookSearchEvent()
}

sealed class BookSearchEffect {
    data class ShowToast(val message: String) : BookSearchEffect()
    data class NavigateToDetail(val bookId: String) : BookSearchEffect()
}

✅

MVI는 구조이고, Intent는 흐름 전체를 의미함
실제 구현할 때는 이 3가지 단위를 다룸:
- UIEvent → 사용자 입력
- UIState → 화면 상태
- UIEffect → 일회성 작업 (토스트 같은..)
UIEvent에서 시작해서 ViewModel이 처리 → State or Effect로 변환 → View 변화

예시 코드

// UIEvent
sealed class BookSearchEvent {
    data class SearchKeywordChanged(val keyword: String) : BookSearchEvent()
    object SearchButtonClicked : BookSearchEvent()
    data class BookClicked(val bookId: String) : BookSearchEvent()
}

// UIState
data class BookSearchState(
    val keyword: String = "",
    val isLoading: Boolean = false,
    val results: List<Book> = emptyList(),
    val errorMessage: String? = null
)

// UIEffect
sealed class BookSearchEffect {
    data class ShowToast(val message: String) : BookSearchEffect()
    data class NavigateToDetail(val bookId: String) : BookSearchEffect()
}

[viewModel]

@HiltViewModel
class BookSearchViewModel @Inject constructor() : ViewModel() {

    private val _uiState = MutableStateFlow(BookSearchState())
    val uiState: StateFlow<BookSearchState> = _uiState

    private val _effect = MutableSharedFlow<BookSearchEffect>()
    val effect = _effect.asSharedFlow()

    fun onEvent(event: BookSearchEvent) {
        when (event) {
            is BookSearchEvent.SearchKeywordChanged -> {
                _uiState.update { it.copy(keyword = event.keyword) }
            }

            BookSearchEvent.SearchButtonClicked -> {
                _uiState.update { it.copy(isLoading = true) }

                // 가짜 API 호출 예시
                viewModelScope.launch {
                    delay(1000)
                    val results = getFakeBooks(event = _uiState.value.keyword)
                    _uiState.update { it.copy(isLoading = false, results = results) }

                    if (results.isEmpty()) {
                        _effect.emit(BookSearchEffect.ShowToast("검색 결과가 없습니다"))
                    }
                }
            }

            is BookSearchEvent.BookClicked -> {
                viewModelScope.launch {
                    _effect.emit(BookSearchEffect.NavigateToDetail(event.bookId))
                }
            }
        }
    }

    private fun getFakeBooks(event: String): List<Book> {
        return if (event.contains("아몬드")) listOf(Book("1", "아몬드")) else emptyList()
    }
}

[Screen]

@Composable
fun BookSearchScreen(
    navController: NavController,
    viewModel: BookSearchViewModel = hiltViewModel()
) {
    val uiState by viewModel.uiState.collectAsState()
    val context = LocalContext.current

    // 상태 반영
    Column(modifier = Modifier.padding(16.dp)) {
        TextField(
            value = uiState.keyword,
            onValueChange = {
                viewModel.onEvent(BookSearchEvent.SearchKeywordChanged(it))
            },
            label = { Text("검색어 입력") }
        )

        Spacer(modifier = Modifier.height(8.dp))

        Button(onClick = {
            viewModel.onEvent(BookSearchEvent.SearchButtonClicked)
        }) {
            Text("검색")
        }

        Spacer(modifier = Modifier.height(16.dp))

        if (uiState.isLoading) {
            CircularProgressIndicator()
        } else {
            LazyColumn {
                items(uiState.results) { book ->
                    Text(
                        text = book.title,
                        modifier = Modifier
                            .fillMaxWidth()
                            .clickable {
                                viewModel.onEvent(BookSearchEvent.BookClicked(book.id))
                            }
                            .padding(8.dp)
                    )
                }
            }
        }
    }

    // 일회성 Effect 처리
    LaunchedEffect(Unit) {
        viewModel.effect.collect { effect ->
            when (effect) {
                is BookSearchEffect.ShowToast -> {
                    Toast.makeText(context, effect.message, Toast.LENGTH_SHORT).show()
                }

                is BookSearchEffect.NavigateToDetail -> {
                    navController.navigate("detail/${effect.bookId}")
                }
            }
        }
    }
}

[Compose] XML처럼 TextField 쓰면 Compose에선 망해요

콩드로이드 — Fri, 16 May 2025 22:38:12 +0900

Compose에서 TextField로 입력할 때, 글자 하나 칠 때마다 뭔가 버벅임을 느꼈습니다..

처음 Compose로 전환했을 때 XML에서 하던 습관대로

OutlinedTextField(
    value = text,
    onValueChange = {
        text = it
        viewModel.search(it) // ❌ 글자 칠 때마다 API 호출
    }
)

이렇게 작성했는데… 텍스트 입력할 때마다 밀리는 느낌?,, 스크롤과 겹치면 거의 끊기는 수준까지 가더라고요.

원인은 recomposition....

Compose는 상태가 바뀌면 해당 Composable이 다시 그려지니, TextField도 마찬가지였습니다,

근데 onValueChange에서 상태 변경 + API 호출까지 동시에 하니 ☠️

입력 → 상태 변경 → recomposition
recomposition 중 launch, joinToString, format 등 무거운 연산 있음 → 스크롤 버벅임

XML 기반 View에선 이런 식으로 해도 이벤트만 전달되기 때문에 이런 문제가 안 드러났어서 모르고 있었지만,

Compose에선 진짜 망하는 길이더라구요..

XML vs Compose

상태 변화	내부에서 직접 보유 (EditText 자체에 있음)	외부에서 상태를 전달 (state)
이벤트 처리 방식	텍스트 변경 이벤트만 따로 발생	value가 바뀌면 recomposition 전체 발생
API 호출 위치	TextWatcher에서 직접 호출 가능 (re-draw 영향 없음)	onValueChange에서 호출하면 UI 전체 다시 그림
렌더링 방식	OS 뷰 시스템이 직접 그림 (뷰 재사용 가능)	선언형 구조라 매번 다시 그릴 수 있도록 설계됨
성능 최적화 필요성	뷰 재사용 구조라 성능 최적화 덜 민감함	recomposition 민감 → 조금만 무거워도 랙 발생

해결 방법: 입력은 입력만, 로직은 분리

val input = remember { mutableStateOf("") }

OutlinedTextField(
    value = input.value,
    onValueChange = { input.value = it }
)

LaunchedEffect(Unit) {
    snapshotFlow { input.value }
        .debounce(300) // 입력 끝나고 300ms 기다림
        .filter { it.length >= 2 }
        .collectLatest {
            viewModel.search(it)
        }
}

이런 식으로 입력과 로직을 분리시켰어요

snapshotFlow로 Compose 상태를 Flow처럼 다룸
debounce로 중복 호출 방지
실제 검색 로직은 입력과 완전히 분리됨 → 스크롤 개선

Compose TextInput 사용 시 고려 사항

✅ onValueChange엔 상태 변경만 — 무거운 로직은 절대 ❌
✅ 포맷팅, 스타일 계산 등은 remember {} 안에서
✅ recomposition이 자주 일어나는 부분은 가능한 단순하게

XML 습관 그대로 Compose에서 쓰면 성능이 무너지는 대표적인 예가 바로 TextField입니다..

Compose에선 "입력은 입력만 처리하고, 로직은 나중에 처리"가 진짜 진짜 중요하더라구요

recomposition에 대해 글을 여러 번 적지만, 매번 겪어보지 않고 고려하기가 어렵네요..

필요하다면 기존 LazyColumn 성능 튜닝과도 연결해서 글 이어보세요
LazyColumn 성능 정리한 글

[Compose] LazyColumn 성능을 위해

콩드로이드 — Tue, 13 May 2025 21:54:51 +0900

✅ LazyColumn이란?

- Compose에서 RecyclerView를 대체하는 스크롤 가능한 Composable
- 내부적으로 보이는 항목만 그림 (지연 로딩)
- 데이터가 많아질수록 Recomposition에 주의

사용하면서 느낀 성능 관련 주의점

key 설정 필요

- Recomposition의 기준 설정

LazyColumn {
    items(list) { item ->
        Text(item.name)
    }
}

key를 설정하지 않으면 → Compose는 index를 기준으로 recomposition 설정
만약, 리스트에서 요소가 삽입, 삭제되면 → 순서 바뀌면서 다시 그려짐 (☠️ 성능 낭비)

✅ 해결 방법:

LazyColumn {
    items(list, key = { it.id }) { item ->
        Text(item.name)
    }
}

key를 고유한 값으로 설정 -> 항목 자체의 고유 값으로 비교 → 순서가 바뀌어도 기존 UI를 재사용

LazyColumn안의 forEach는 Compose가 추적 불가능

-LazyColumn은 기본적으로 보이는 항목만 그려주는 지연 렌더링(Lazy Rendering) 구조

근데 forEach로 직접 Composable을 호출하면, Compose는 그걸 Lazy 항목으로 인식하지 않고 일반적인 Composable 호출로 처리 -> 즉 forEach 항목을 매번 새로 그림 -> Lazy가 의미가 없어짐

LazyColumn {
    // ❌ 이렇게 하면 LazyColumn의 역할이 의미 X
    list.forEach { item ->
        Text(item.name)
    }
}

✅ 해결 방법: items { } 사용

- 내부적으로 LazyListItem으로 관리 → 리스트 스크롤 시 화면에 보여야 할 항목만 렌더링

val userList = listOf(
    User("방", 33),
    User("케", 31),
    User("필", 31),
    User("돈", 29),
)

LazyColumn {
    items(userList, key = { it.name }) { user ->
        Text(
            text = "${user.name}, 나이: ${user.age}",
            modifier = Modifier.padding(16.dp)
        )
    }
}

항상 `items {}`를 쓰고, `key`를 설정하자 → 그래야 Compose가 항목을 재사용하고 성능이 떨어지지 않는다..!

[Android / Compose] Compose Context

콩드로이드 — Sun, 11 May 2025 14:52:39 +0900

까먹기 전에 줍줍..

XML vs Compose의 "생명주기 + context" 구조 차이

XML 기반

Activity나 Fragment가 View를 직접 소유
View는 Activity가 죽을 때 context도 같이 정리됨 → context를 View 내부에서 써도 큰 문제가 없다
즉, UI는 생명주기를 따라감

Compose 기반

UI 자체가 "함수로 구성된 상태 기반 UI"
상태에 따라 UI가 수시로 재구성(recomposition) 되기에 Activity와 느슨하게 연결됨
그래서 UI 함수 내에서 context를 막 쓰면, 그 시점에 context가 유효하지 않을 수 있음

XML : context가 항상 Activity와 뷰 안에 있고, 생명주기를 같이 가져가니까 자유롭게 써도 괜찮았지만,
Compose : UI 함수들이 Activity 생명주기와 독립적으로 돌아가기도 하니까, context를 직접 관리하지 않으면 위험

✅ 그래서 context는 명시적으로 전달해야 한다!

@Composable
fun MyComposable(context: Context) { ... }

: 이 함수가 context가 꼭 필요한 걸 명확히 드러낼 수 있음

호출 시점에서도 context를 보장된 상태에서 넘기게 되니까 → 버그 줄고, 메모리 릭 위험도 줄고, 테스트도 쉬워짐

⚠️ 잊지말자

Compose는 함수형 UI는 예측 불가능한 시점에 다시 실행될 수 있다

예를 들어 context를 갖고 있던 composable 함수가 ViewModel의 상태 변화로 인해 다시 실행되었는데 → 앱이 크래시 나거나, 이상한 동작 발생 ,,

compose하다보면 Recomposition이 굉장히 중요한데, 이렇게 context같은 부분을 빼먹지않도록 유념해야한다,,

[Android] Widget 사용해보기

콩드로이드 — Sat, 26 Apr 2025 15:21:21 +0900

위젯을 처음 사용해봤어서, 언젠가 쓸 날을 위해 정리해보도록 하겠습니다

Widget

- 홈 화면에 배치 하는 뷰 컴포넌트 (RemoteView 기반)

- RemoteView이기에 일반 View처럼 직접 조작 불가 즉, 동적 뷰 생성이 불가하기 때문에 RecyclerView, ListView, Glide등이 사용 불가

⚙️ Widget의 필수 구성 요소

AppWidgetProvider - 위젯 생명주기 관리

widget_info.xml - 위젯 크기, 초기 레이아웃, 업데이트 주기, configureActivity 설정

RemoteViews - 위젯 UI를 위한 뷰 생성 도구, 동적 뷰는 생성 불가능

ConfigureActivity - 위젯 추가 시 보여지는 Activity (widget_info.xml에서 선언한 경우만 보여짐)

위젯 동작 전체 흐름

1️⃣ 위젯은 widget_info.xml, AppWidgetProvider, RemoteViews로 구성

2️⃣ 위젯 추가 시 ConfigureActivity가 있으면 설정 화면(ConfigureActivity로 선언한 화면)으로 진입

3️⃣ 설정 완료 시 setResult(RESULT_OK)로 위젯 ID 등록

4️⃣ 시스템이 onUpdate() 호출 → RemoteViews로 위젯 UI 구성

5️⃣ AppWidgetManager.updateAppWidget()으로 실제 위젯 업데이트

전체 코드

widget ui

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:id="@+id/widget_container"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:background="#FFFFFF"
    android:orientation="vertical"
    android:gravity="center">

    <TextView
        android:id="@+id/widget_text"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Hello Widget!"
        android:textSize="18sp"
        android:textColor="#000000" />
</LinearLayout>

widget_info

<?xml version="1.0" encoding="utf-8"?>
<appwidget-provider xmlns:android="http://schemas.android.com/apk/res/android"
    android:minWidth="180dp"
    android:minHeight="60dp"
    android:updatePeriodMillis="86400000" //업데이트 주기
    android:initialLayout="@layout/widget_ui" //사용할 위젯 ui
    android:resizeMode="horizontal|vertical"
    android:widgetCategory="home_screen"  // 홈화면에서 사용할지, 잠금화면에서 사용할지
    />

widget provider

class SimpleTextWidgetProvider : AppWidgetProvider() {

    override fun onUpdate(
        context: Context, appWidgetManager: AppWidgetManager, appWidgetIds: IntArray
    ) {
        for (appWidgetId in appWidgetIds) {
            // RemoteViews 생성
            val views = RemoteViews(context.packageName, R.layout.widget_simple)

            // 텍스트 동적으로 변경 가능 (필요 시)
            views.setTextViewText(R.id.widget_text, "Hello Widget!")

            // 위젯 업데이트
            appWidgetManager.updateAppWidget(appWidgetId, views)
        }
    }
}

manifest

<receiver android:name=".SimpleTextWidgetProvider" >
    <intent-filter>
        <action android:name="android.appwidget.action.APPWIDGET_UPDATE" />
    </intent-filter>

    <meta-data
        android:name="android.appwidget.provider"
        android:resource="@xml/simple_widget_info" />
</receiver>

onEnabled()

호출 시점: 위젯이 홈 화면에 ‘처음’ 추가될 때 딱 한 번 호출됨.
주요 용도: 시스템이 onUpdate()를 누락하거나 앱이 재실행될 때 강제 업데이트 trigger

앱이 다시 실행돼도 시스템이 onUpdate()를 보장하지 않기 때문에 → onEnabled()나 앱 onCreate() 시점에서 수동 갱신 권장

사용 방식: AppWidgetManager.getAppWidgetIds()로 위젯 ID를 가져와 ACTION_APPWIDGET_UPDATE 브로드캐스트 전송.
주의사항: UI 업데이트는 여기서 직접 XXX

알아두면 좋을 팁

ConfigureActivity가 안 뜰 때 : info.xml에 선언되어 있는지 확인 필요

미리보기 이미지 등록: AndroidManifest.xml에서 <meta-data>로 android.appwidget.preview 등록

RemoteViews 제약: setTextViewText, setImageViewBitmap 등 제한된 API만 가능(동적 뷰는 XX)

주기적 갱신: AlarmManager, WorkManager 등을 활용해 수동 트리거. 단, 실시간 갱신은 비추천.

❓ 테스트하며 들었던 의문들.,

Q. Glide로 불러온 이미지를 위젯에 넣을 수 있을까?

✅ Glide에서 비트맵으로 만든 후 setImageViewBitmap()으로 넣으면 가능

Glide.with(context) 
	.asBitmap()
    .circleCrop() 
    .load(imageUrl) 
    .into(object : CustomTarget<Bitmap>() 
    { 
    	override fun onResourceReady(resource: Bitmap, transition: Transition<in Bitmap>?) 
        { 
        	views.setImageViewBitmap(R.id.widget_iv, resource) 
        }
    })

Q. configureActivity가 한 번 안 뜨면 계속 안 뜰 때?

왜냐하면 시스템이 해당 위젯 ID는 이미 설정 완료된 것으로 간주 → setResult(RESULT_OK) 또는 RESULT_CANCELED를 명확히 호출해야 재설정 가능

Q. 앱 재설치하면 다시 잘 뜨는 이유?

✅ 시스템은 위젯 상태를 앱 패키지 단위로 캐싱

: 앱을 삭제하면 위젯 관련 정보도 전부 삭제됨 → 새 앱처럼 동작 → 설정 화면 다시 뜸

Q. 위젯 크기가 실제보다 너무 클 때

✅ res/xml/widget_info.xml의 minHeight, minWidth 값을 조정해야 함(grid 단위도 있으니 확인 필요)

✅ 위젯 미리보기 이미지는 metat-data에 등록필수

AndroidManifest.xml에서 <meta-data> 등록

<meta-data 
android:name="android.appwidget.preview" 
android:resource="@drawable/preview_image" /> 

<meta-data android:name="android.appwidget.description" 
android:value="@string/widget_description" />

[Android] WorkManager

콩드로이드 — Fri, 18 Apr 2025 23:42:29 +0900

WorkManager는 처음 사용해봐서 정리해두려고 함,,

✅ WorkManager란?

- Android Jetpack의 백그라운드 작업 처리 라이브러리

네트워크 연결 상태, 충전 중 여부 등 다양한 제약 조건 설정 가능

언제 사용하면 좋을까 ?

- 작업이 백그라운드에서도 꼭 실행돼야 할 때 (ex. 업로드 같은 동작)

- 네트워크 활성화 / 충전 중 등 조건을 걸고 싶을 때

- 주기적으로 실행되어야 할 때 (ex. 하루에 한 번 데이터 전송 예약)

WorkManager 구성요소

Worker

- 실제 작업을 정의한 클래스 즉, doWork() 구현

- 작업 방식(동기 / 코루틴 / RxJava)에 따라 Worker는 Worker, CoroutineWorker, RxWorker 3가지 타입으로 나뉨

class MyWorker(
    context: Context,
    workerParams: WorkerParameters
) : CoroutineWorker(context, workerParams) {

    override suspend fun doWork(): Result {
        val input = inputData.getString("key")
        
        // TODO: 비동기 작업 수행 (예: 네트워크 요청, 파일 저장 등)
        return Result.success()
    }
}

WorkRequest

- 어떤 작업을 어떻게 실행할지 방법을 정의

- 한 번만 실행 → OneTimeWorkRequestBuilder
정기적 실행 → PeriodicWorkRequestBuilder

val work = OneTimeWorkRequestBuilder<MyWorker>()
    .setInputData(workDataOf("key" to "odense"))
    .build()

WorkManager

- 작업을 큐에 넣고 실행하는 핵심 요소

WorkManager.getInstance(context).enqueue(work)

Constraints (optional)

- 제약 조건 설정

와이파이 연결됐을 때만 작업하고 싶을 때
충전 중일 때만 실행되게 하고 싶을 때
기기가 *유휴 상태일 때만 실행되게 하고 싶을 때

유휴 상태가 필요하나 싶었는데 예를 보니까 필요할 때도 있을 거 같다,,

사용자가 기기를 안 만지는 상태 (잠김, 화면 꺼짐 등), 백그라운드에서 시스템이 쉬는 상태

val constraints = Constraints.Builder()
    .setRequiresCharging(true)
    .setRequiredNetworkType(NetworkType.UNMETERED)
    .setRequiresDeviceIdle(true)
    .build()

즉 간단하게 줄이자면

Worker : 할 일 정의

WorkRequest : 할 일 요청

Constraints : 특정 조건을 걸지 말지

WorkManager : 실행 담당

전체 코드

class MyWorker(
    context: Context,
    workerParams: WorkerParameters
) : CoroutineWorker(context, workerParams) {

    override suspend fun doWork(): Result {
        val value = inputData.getString("key")
        Log.d("MyWorker", "값 받음: $value")

        // TODO: 백그라운드에서 수행할 작업
        return Result.success()
    }
}

// 보통 Activity, ViewModel 등에 작성됨
val constraints = Constraints.Builder()
    .setRequiredNetworkType(NetworkType.UNMETERED)
    .setRequiresCharging(true)
    .build()

val work = OneTimeWorkRequestBuilder<MyWorker>()
    .setInputData(workDataOf("key" to "odense"))
    .setConstraints(constraints)
    .build()

WorkManager.getInstance(context).enqueue(work)

어떤 파일에 어떤 구성 요소가 들어가야하는지 헷갈릴 수 있다

구조를 보자면 아래와 같다

project
├── work
MyWorker.kt ← Worker 클래스 정의
├── ui 관련
MainActivity.kt ← WorkerRequest, WorkerManager, constraints

백그라운드 작업을 많이 안 해봐서 접근이 어려웠지만 꼭 써먹어봐야지 ㅎㅅㅎ

[Android] 클린 아키텍처 적용 시 고민했던 3가지 의문점

콩드로이드 — Sat, 12 Apr 2025 11:56:29 +0900

새 프로젝트를 시작하며 새로운 디자인 패턴(MVI)를 적용하려고 하다보니, 클린 아키텍처에 대한 고심?이 필요했습니다

들었던 의문점들을 정리해보았어요

Q1. Repository는 화면을 따라가야 할까? 데이터 주체를 따라가야 할까?

A. Repository는 무조건 “데이터 주체” 기준으로 네이밍해야 함!

❌ MainRepository, BookScreenRepository
✅ BookRepository, UserRepository

: Repository는 데이터 주체를 중심으로 만들어야 여러 화면에서 재사용 가능하고, 구조가 깔끔하게 유지

Q2. Repository는 domain 계층인데, 구현체는 왜 data에 있을까?

A. Repository의 정의는 도메인에 있고, 실제 구현은 data에 있어야 함!

BookRepository (interface) → domain
BookRepositoryImpl (구현체) → data

: 이유는 도메인은 외부 기술(Retrofit, Room 등)을 몰라야 하기 때문
→ 기술 독립성 유지가 클린 아키텍쳐에서 제일 중요함!

Q3. UseCase에서 Repository 호출하면, 결국 어차피 Repository의 구현체(RepositoryImpl)가 동작하는 거 아닐까?
그럼 UseCase를 사용할 필요가 있나?

1. 계층 간 의존 역전 원칙(DIP)을 지키기 위해

구현체가 동작하긴 하지만 UseCase나 Repository는 인터페이스 기준으로만 동작해야 함!

UseCase는 BookRepository를 부르고, 실제로는 Hilt가 BookRepositoryImpl을 주입해주는 구조

: UseCase나 Repository에서 외부 기술을 직접 사용하면 계층 간 의존 역전 원칙(DIP)이 깨짐

상위 계층이 하위계층에 의존하면 X, 인터페이스에만 의존해야함!

2. 관심사 분리로 유지보수성과 테스트성을 높이기 위해

ViewModel은 상태 관리와 UI 이벤트 처리만 담당
UseCase는 비즈니스 로직, 데이터 처리 등의 실제 기능을 담당

이렇게 분리하면 각 계층이 하나의 책임만 갖게 돼서
→ 로직이 더 깔끔해지고
→ 테스트 작성, 기능 확장, 유지보수 용이

항상 프로젝트 구조를 짜는 게 제일 어려운 거 같아요 꾸준한 연습하기,, !

[Android / RecyclerView] onCreateViewHolder vs onBindViewHolder: 클릭 리스너는 어디에 둘까?

콩드로이드 — Mon, 7 Apr 2025 21:42:32 +0900

RecyclerView 클릭 리스너, 어디서 설정하는 게 좋을까?

저는 원래 RecyclerView의 Adapter에 리스너를 설정할 때, 자연스레 onBindViewHolder()에서 뷰홀더로 넣어주는 방식을 많이 사용했었는데, 이게 성능과 메모리에 좋지 않다는 걸 알게 되었습니다 ,,!

일단, 2개의 호출 시점이 중요했습니다 !

호출 시점의 차이

onCreateViewHolder()
→ 새로운 뷰 홀더가 필요할 때 한 번만 호출

onBindViewHolder()
→ 뷰 홀더가 데이터와 바인딩될 때마다 반복적으로 호출
⚠️ 스크롤할 때마다 계속 호출됨

onBindViewHolder에서 리스너를 생성하게 된다면,

스크롤할 때마다 새로운 리스너 객체가 만들어지기 때문에 메모리 사용량이 증가되고 GC가 생성됩니다

따라서 재사용성을 향상시키고 메모리를 절약하기 위해선 onCreateViewHolder()에서 해주는 게 좋다고 합니다

소스를 예로 보자면,

class MyAdapter(
    private val items: List<String>,
    private val listener: OnClickListener
) : RecyclerView.Adapter<MyAdapter.MyViewHolder>() {

    inner class MyViewHolder(private val binding: ItemLayoutBinding) :
        RecyclerView.ViewHolder(binding.root) {

        init {
            // 클릭 리스너는 한 번만 설정
            binding.root.setOnClickListener {
                val position = bindingAdapterPosition
                if (position != RecyclerView.NO_POSITION) {
                    listener.onClick(position)
                }
            }
        }

        
        fun bind(item: String) {
            binding.textView.text = item
        }
    }

    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): MyViewHolder {
        val binding = ItemLayoutBinding.inflate(LayoutInflater.from(parent.context), parent, false)
        return MyViewHolder(binding) 
    }

    override fun onBindViewHolder(holder: MyViewHolder, position: Int) {
        holder.bind(items[position]) 
    }

    override fun getItemCount() = items.size

    interface OnClickListener {
        fun onClick(position: Int)
    }
}

❓inner class 없이 onCreateViewHolder에서 바로 리스너를 설정하면 안 될까?

이론적으로는 가능하지만이 시점에서는 아직 뷰홀더가 어떤 데이터를 바인딩받을지 결정되지 않았기 때문에,
position 값이 유효하지 않을 수 있고 , 재사용 시 잘못된 position을 참조할 위험이 있습니다 ..!

즉, 예시 코드처럼 inner class의 ViewHolder에서 init {} 블록 안에서 bindingAdapterPosition을 사용하는 방식이
항상 최신 position을 가져오기 때문에 더 안전한 방법입니다

[Kotlin] ifEmpty

콩드로이드 — Mon, 31 Mar 2025 23:30:57 +0900

아주 편한 인라인 함수가 있어서 부랴부랴 포스팅합니다

kotlin 버전 1.3 이상부터 사용가능해요

ifEmpty

inline fun <C : Array<*>, R, R> C.ifEmpty(defaultValue: () -> R): R

inline fun <C : Collection<*>, R, R> C.ifEmpty(defaultValue: () -> R): R

inline fun <M : Map<*, *>, R, R> M.ifEmpty(defaultValue: () -> R): R

만약 이 배열/컬렉션/맵이 비어 있지 않으면 이 배열/컬렉션/맵 을 반환하고, 비어 있으면 defaultValue 함수를 호출한 결과를 반환

fun main() {
    val myArray: Array<Int> = arrayOf() 

 
    val defaultValue = listOf(42)

    val result = myArray.toList().ifEmpty { defaultValue }

    println(result) // 42가 출력됩니다 ~~ 
}

if else 안 써도 되니까 편한 거 같아요..! 또 괜찮은 함수를 발견하면 줍줍해오겠습니다

[Android] LiveData - observeForever

콩드로이드 — Fri, 21 Mar 2025 21:53:19 +0900

안녕하세요 오늘은 liveData의 observeForever에 대해 알아보겠습니다

observeForever

LiveData의 메서드로 LifecycleOwner가 아닐 때도 데이터를 관찰할 수 있도록 합니다

하지만 lifecycleOwner와 관계없이 데이터를 관찰할 수 있기에, 수동으로 해제하지 않으면 메모리 누수 위험성이 있습니다

해제해줄 땐 꼭 removeObserver를 호출해야 합니다 !

완전한 코드는 아니지만 대충 뉘앙스만 보자면,, 아래와 같은 형식으로요

	override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_my)

        // Observer 초기화
        observer = Observer { data ->
            // UI 업데이트
            updateUI(data)
        }

        // LiveData 관찰
        viewModel.data.observeForever(observer)
    }

    override fun onDestroy() {
        super.onDestroy()
        // Observer 해제
        viewModel.data.removeObserver(observer)
    }

LiveData의 본래 장점인 생명주기 관리와는 거리가 먼 거 같은데,, 전역으로 쓰이는 경우에 사용될 수 있다고 하네요 ,, ?

정확히 어떤 경우에 사용해야 좋은지는 잘 모르겠습니다 ..!

라이프사이클에 맞춰서 관리되는 observe를 사용하는 게 좋을 거 같은데

observeForever를 언제 사용하면 좋은지 의견이 있으신 분들은 알려주시면 감사하겠습니다 ..

[Compose] Compose의 성능 최적화 기법 - 상태 읽기 연기

콩드로이드 — Sun, 23 Feb 2025 18:27:56 +0900

상태 읽기 연기

- 상태를 직접적으로 읽지 않고, 대신 lambda 같이 상태를 간접적으로 참조하는 것을 의미

만약 상태를 직접적으로 읽는다면 (param으로 값을 받게되면) 값이 변경될때마다 recomposition

즉 Composition -> Layout -> Drawing을 거치게 되는데,

param대신 lambda를 사용하면 UI의 상태나 데이터를 직접적으로 참조하지 않고, 함수의 결과를 사용하기 때문에

Layout -> Drawing 단계만 진행하게 된다!

composition 단계에서 ui 트리를 만드는데 많은 리소스가 사용되는데 이 단계를 건너뛸 수 있다는 것만으로도 리소스 낭비를 막을 수 있는 셈!

[Compose] 의존성 주입 (Dependency Injection) (ft.hilt)

콩드로이드 — Tue, 11 Feb 2025 19:48:17 +0900

우선, 라이브러리 적용이 필요합니다 (dagger, hilt)

[versions]
//...
daggerVersion = "2.48"
hiltVersion = "1.2.0"
retrofitVersion = "2.9.0"
gsonVersion = "2.10.1"


[libraries]
//...
dagger-android = { group = "com.google.dagger", name = "hilt-android", version.ref = "daggerVersion" }
hilt-compose = { group = "androidx.hilt", name = "hilt-navigation-compose", version.ref = "hiltVersion" }
androidx-gson = { group = "com.google.code.gson", name = "gson", version.ref = "gsonVersion" }
androidx-retrofit = { group = "com.squareup.retrofit2", name = "retrofit", version.ref = "retrofitVersion" }
androidx-gson-converter = { group = "com.squareup.retrofit2", name = "converter-gson", version.ref = "retrofitVersion" }
hilt-compiler = { group = "com.google.dagger", name = "hilt-android-compiler", version.ref = "daggerVersion" }

[plugins]
android-application = { id = "com.android.application", version.ref = "agp" }
kotlin-android = { id = "org.jetbrains.kotlin.android", version.ref = "kotlin" }
kotlin-compose = { id = "org.jetbrains.kotlin.plugin.compose", version.ref = "kotlin" }
kotlin-kapt = { id = "org.jetbrains.kotlin.kapt" }
hilt-android = { id = "com.google.dagger.hilt.android"}

build.gradle

의존성주입을 통해 network를 설정하고 github api를 사용해봅시다

1. hilt에서 제일 처음해줘야 할 Application을 설정합니다

Manifest에 application을 생성한 클래스의 name으로 변경해줘야합니다

@HiltAndroidApp
class MainApplication: Application() {

}

2. Module을 설정합니다

Module : 의존성 주입을 하고 있는 provider가 있는 곳 즉, Hilt는 모듈을 통해 "이 클래스에 필요한 것은 이거야!"라고 알게 되고, 자동으로 필요한 객체를 주입

@InstallIn(SingletonComponent::class)
@Module
class MainModule {
    @Singleton
    @Provides
    @Named("API_URI")
    fun provideApiUri(): String  = "https://api.github.com/"
    //provide명은 전혀 중요하지 않다, 같은 타입이 여러개 있을 수 있으니 @Named 셋팅

    @Singleton
    @Provides
    fun provideGson(): Gson = GsonBuilder().setFieldNamingPolicy(FieldNamingPolicy.LOWER_CASE_WITH_UNDERSCORES).create()

    //gson, retrofit match
    @Singleton
    @Provides
    fun provideConverterFactory(): Converter.Factory = GsonConverterFactory.create()

    @Singleton
    @Provides
    fun provideRetrofit(@Named("API_URI") apiUri: String, converterFactory: Converter.Factory): Retrofit = 
        Retrofit.Builder().baseUrl(apiUri).addConverterFactory(converterFactory).build()
    
    @Singleton
    @Provides
    fun provideGithubService(retrofit: Retrofit): GithubService = 
        retrofit.create(GithubService::class.java)

}

3. viewModel을 생성합니다

@HiltViewModel
class MainViewModel @Inject constructor(
    private val apiService: GithubService
): ViewModel() {

    val repositorys = mutableStateListOf<Repository>()

    fun getRepository() {
        repositorys.clear()
        viewModelScope.launch {
            repositorys.addAll(apiService.getUsersRepos("eunie9498"))
        }
    }
}

[Compose] 안정성 stability

콩드로이드 — Sun, 9 Feb 2025 16:44:11 +0900

안정성에 관해서도 가장 중요한 키워드는 Smart Recomposition 같아요

Smart Recomposition

- composition 함수에서 사용되는 데이터가 변경된 데이터의 함수만 재호출 즉 일부분의 ui만 업데이트

- 성능 최적화

이 때 compose는 필요한 recomposition임을 어떻게 구분할까 ? -> paramater로 구분

크게 3가지로 나눠본다면

Stable parameters

- 변경 시 컴포지션에서 추적이 가능하기 때문에 smart recomposition이 가능

- 즉, 변경 사항이 없다면 compose는 skip

Unstable parameters

- 변경 시 컴포지션에서 추적이 불가 -> 데이터의 변경 사항의 유무와 관계 없이 무조건 Recomposition

- 퍼포먼스에 안 좋은 영향

Immutable parameters

- 변경 불가

- compose에선 당연히 변경 사항이 없을 거라 생각해서 skip

data class Contact(val name: String, val number: String)

@Composable
fun ContactRow(contact: Contact, modifier: Modifier = Modifier) {
   var selected by remember { mutableStateOf(false) }

   Row(modifier) {
      ContactDetails(contact)
      ToggleButton(selected, onToggled = { selected = !selected })
   }
}

- contact의 paramater는 val로 지정 : immutable

- contactDetails는 recomposition에서 제외 (smart recomposition)

근데 만약, data class에서 val이 아니라 var로 선언된다면

data class Contact(var name: String, var number: String)

@Composable
fun ContactRow(contact: Contact, modifier: Modifier = Modifier) {
   var selected by remember { mutableStateOf(false) }

   Row(modifier) {
      ContactDetails(contact)
      ToggleButton(selected, onToggled = { selected = !selected })
   }
}

mutable이기 때문에 contactDetail이 무조건 recomposition 된다

Compose를 Smart하게 사용하려면 Immutable이나, stable paramater를 사용하는 것이 좋다 .. !

(all primitive types and string are immutable )

compose compiler report로 확인해보기 (compose가 함수를 어떻게 판단하는지)

빌드 전 build.gradle에 아래와 같이 추가

  android { ... }

  composeCompiler {
    reportsDestination = layout.buildDirectory.dir("compose_compiler")
    metricsDestination = layout.buildDirectory.dir("compose_compiler")
  }

싱크 후 빌드하면 프로젝트 경로/app/build/compose_compiler 폴더에 파일들이 생성되어있습니다

이런 코드를 빌드하고 리포트를 생성했는데, <modulename>-composables.txt 파일을 확인하면

@Composable
fun Greeting(name: String, modifier: Modifier = Modifier) {
    Text(
        text = "Hello $name!",
        modifier = modifier
    )
}

아래와 같이 생성되어 있습니다

restartable skippable scheme("[androidx.compose.ui.UiComposable]") fun Greeting(
  stable name: String
  stable modifier: Modifier? = @static Companion
)

stable / unstable : 위에서 살펴봤던 개념과 동일합니다

restartable

- composable이 recomposition의 진입점 (어느 부분부터 recomposition이 가능한지)을 나타냅니다

skippable

composable이 recomposition일 때 값이 변경되지 않았다면 recomposition을 skip할 수 있음을 나타냅니다

composable 함수의 모든 매개변수가 안정해야지만 붙을 수 skippable이 붙게됩니다

위의 예제를 아래와 같이 변경해본다면

data class NotStable(
    var name: String
)

@Composable
fun Greeting(dto: NotStable, modifier: Modifier = Modifier) {
    Text(
        text = "Hello ${dto.name}!",
        modifier = modifier
    )
}

compiler report에서 skippable이 빠진 걸 알 수 있습니다

restartable scheme("[androidx.compose.ui.UiComposable]") fun Greeting(
  unstable dto: NotStable
  stable modifier: Modifier? = @static Companion
)

Annotation으로 immutable, stable을 지정할 수 있다

@Immutable
data class TestCollection(
 val dto : List<DTO>
)

이런식으로 미리 annotation으로 지정할 수 있다

[Android] ViewPager2 감도 조절하기

콩드로이드 — Sat, 8 Feb 2025 19:15:52 +0900

viewpager2를 카드뷰처럼 넘기고 싶은데 너무 휙휙 돌아가지는 거 같아서 서치하다 찾은 방법이다

ViewPager2는 ViewPager와 다르게 RecyclerView를 기반이라 recyclerview내에 스크롤 감도를 조절하는 mTouchSlop을 변경하면 된다

fun ViewPager2.reduceDragSensitivity() {
    val recyclerViewField = ViewPager2::class.java.getDeclaredField("mRecyclerView")
    recyclerViewField.isAccessible = true
    val recyclerView = recyclerViewField.get(this) as RecyclerView

    val touchSlopField = RecyclerView::class.java.getDeclaredField("mTouchSlop")
    touchSlopField.isAccessible = true
    val touchSlop = touchSlopField.get(recyclerView) as Int
    touchSlopField.set(recyclerView, touchSlop * 8) // 원하는 숫자     
}

touchSlop 값은 유저가 스와이프할 때 인식되는 최소 거리라, 값을 높일수록 드래그 감도가 낮아진다고 생각하면 된다

하지만 이 방법은 내부 필드에 접근 하는 방법이라 업데이트가 된다면..! 안 먹히는 방법이 될 수도 있다 ..!

[Android] AAC의 LiveData, ViewModel의 LiveData

콩드로이드 — Tue, 4 Feb 2025 20:32:37 +0900

AAC

- 안드로이드 아키텍처 컴포넌트(Android Architecture Components)로 앱 개발을 더 쉽고 유지보수 가능하게 해주는 구성요소들의 모음

LiveData는 AAC의 일부로 아래와 같은 특성을 가진다

Observer 패턴 기반의 데이터 홀더로, 데이터를 감싸고 UI와 연결할 수 있음.
LifecycleOwner(Activity, Fragment 등)를 인식해, UI Controller가 종료되면 자동으로 Observer를 제거해 메모리 누수를 방지함

ViewModel에서 쓰느냐 Activity, Fragment에서 쓰느냐의 차이는 바로 lifecycle

만약 ViewModel에서 사용하면 ViewModel의 Lifecycle을 따르기 때문에, 화면 회전 시에도 데이터가 유지

즉 , ViewModel은 Activity보다 수명이 길고, Activity가 재생성되어도 같은 ViewModel 인스턴스를 유지하기 때문

근데 만약 Fragment나 Activity에서 LiveData를 선언해서 쓰게 된다면, 화면 회전 시 Activity/Fragment가 재생성되면서 LiveData도 새로 만들어지고 기존 데이터는 날아감

그러므로 LiveData는 ViewModel에서 선언해서 쓰는 것이 좋다

[Compose] Rendering

콩드로이드 — Fri, 31 Jan 2025 16:46:05 +0900

Compose는 크게 보자면 Data를 UI로 변환하는 과정인데, 아래의 과정들을 거칩니다

Composition : what (무엇을 그릴지)

layout : where (UI를 어디에 배치할지)

Drawing: How (어떻게 UI를 그릴지)

Composition

code를 UI Tree화 시킵니다 즉, 데이터와 UI 요소 간의 관계가 정의됩니다

Layout

아래의 과정으로 UI 트리를 탐색을 하면서, 각 레이아웃을 측정하고 배치됩니다

하위 요소 측정: 노드가 하위 요소(있는 경우)를 측정
자체 크기 결정: 이러한 측정치를 기반으로 노드가 자체 크기를 결정
하위 요소 배치: 각 하위 노드는 노드의 자체 위치를 기준으로 배치

이 때 , 모든 노드는 단 한번씩만 방문하기 때문에 Compose 런타임은 모든 노드를 측정하고 배치하는 데 UI 트리를 한 번만 통과하면 되므로 성능이 향상됩니다!

이 단계를 거치면 할당된 높이, 너비, 그리고 그려야하는 x,y 좌표를 알게됩니다

Draw

UI Tree를 위에서 아래로 한번씩만 방문하면서 그리게 됩니다

[Compose] Compose의 LifeCycle

콩드로이드 — Mon, 27 Jan 2025 19:18:38 +0900

⭐️ Smart Recomposition

- composition 함수에서 사용되는 데이터가 변경된 데이터의 함수만 재호출 즉 일부분의 ui만 업데이트

- 성능 최적화

Compose의 Lifecycle

https://developer.android.com/develop/ui/compose/lifecycle?hl=ko

- composition : 컴포저블 함수가 호출되어 UI 트리를 구성하는 과정으로 여러 개의 컴포저블이 결합되어 최종 UI 생성, 즉 초기 UI를 설정하는 단계

- recomposition : 상태가 변경되어 UI가 다시 그려지는 과정, 상태 변화를 감지하고 영향을 받는 부분만 업데이트 (최적화 하는 것이 제일 중요)

- disposal : composable이 소멸, 리소스 해제

recomposition의 최적화를 위해서 생명주기를 아는 것이 중요합니다

만약 아래와 같이 코드를 사용한다고 하면,

@Composable
fun MovieOverview(movie: Movie) {
    Column {
       //...
        val image = loadNetworkImage(movie.url)
        MovieHeader(image)

        /* ... */
    }
}

@Composable
fun MoviesScreen(movies: List<Movie>) {
    Column {
        for (movie in movies) {
            // MovieOverview composables are placed in Composition given its
            // index position in the for loop
            MovieOverview(movie)
        }
    }
}

만약 맨 하단에 아이템을 추가한다면, 별다른 문제 없이 잘 추가가 될 것입니다

하지만 목록의 상단 혹은 중간에 아이템을 추가하면 모든 MovieOverview 호출들이 recomposition이 되어버립니다

만약 네트워크를 통해 데이터를 가져오고 있는 중이였다면 네트워크 요청이 중복 실행되거나 이전 요청이 취소되는 상황이 발생합니다

이런 문제를 해결하기 위해서는

@Composable
fun MoviesScreenWithKey(movies: List<Movie>) {
    Column {
        for (movie in movies) {
            key(movie.id) { // Unique ID for this movie
                MovieOverview(movie)
            }
        }
    }
}

트리의 특정 부분(key 컴포저블)을 식별하는 데 사용할 값을 지정하면 됩니다

이 key 값은 전체적으로 고유하지 않아도 되며 호출 사이트에서의 컴포저블 호출 간에만 고유하면 됩니다

위와 같이 특정 식별값을 준다면 어디에 추가된다고 해도 전체적으로 Recomposition 하지 않고

compose는 개별 MovieOverview를 인식하고 재사용할 수 있습니다

[Compose] 단방향 데이터 흐름

콩드로이드 — Thu, 23 Jan 2025 17:50:59 +0900

State : 위에서 아래로만 내려간다

- 일반적으로 상위 컴포넌트(부모)에서 하위 컴포넌트(자식)로 전달

- UI 상태를 한 곳 (보통 부모 컴포넌트) 에서 관리해서 UI 컴포넌트(자식)는 그 상태에 대한 직접적인 수정이 불가능 -> 캡슐화

Event : 아래에서 위로 올라간다

- UI 일부에서 이벤트를 생성해 위로 전달

- 그 이벤트를 부모에게 알려주고 부모가 해당 이벤트에 대한 처리

- 이벤트 발생 -> 이벤트 핸들러가 상태 변경(업데이트) -> 상태가 변경되면 state holder에서 변경된 상태 UI 표시

- 부모는 이벤트를 처리하고 상태를 변경 후, 새로운 상태를 다시 자식에게 전달. 자식은 상태 변경에 대한 영향을 받지만 직접적으로 상태를 수정불가

테스트 하기 용이하고, ui에 일관성

ex)

mutableStatOf -> Compose가 관측할 수 있는 MutableState 생성

값 변경 -> 값을 읽는 모든 Composition의 Recomposition 예약

remember

- remember는 Compose가 상태를 유지, 컴포넌트가 다시 그려질 때, 이전에 저장했던 값을 기억
- 만약 해당 컴포넌트가 UI에서 제거 -> remember로 저장된 객체는 자동으로 제거(메모리 효율)

[Compose] Navigation

콩드로이드 — Wed, 22 Jan 2025 18:47:18 +0900

라이브러리 추가가 필요합니다

[libs.version.toml]

[versions]
//...
navigationVersion = "2.8.5"

[libraries]
//...
androidx-navigation-compose = { group = "androidx.navigation", name = "navigation-compose", version.ref = "navigationVersion" }

[build.gradle]

implementation(libs.androidx.navigation.compose)

Navigation은 화면 간 전환을 관리하는 중요한 요소입니다

예제를 통해 각각 필요한 개념을 익혀보겠습니다

NavController

- 현재 Navigation 상태 관리, 화면 간 이동을 처리
- 각 스크린에서 NavController를 인자로 받아 사용 가능

navController를 받는 Composable 함수를 생성합니다

@Composable
fun NavTest(
    modifier: Modifier = Modifier,
    navController : NavHostController = rememberNavController()
)

NavHost를 생성합니다

- Navigation 그래프를 정의하는 컨테이너, startDestination을 지정하여 처음 표시될 화면 설정

    NavHost(
        navController = navController,
        startDestination = "Korea",
        modifier = modifier
    ) {
        composable("Korea") {

            Column {
                Text("한국이에요  ")
                Spacer(modifier = Modifier.size(10.dp))
                Button(onClick = {
                    navController.navigate("Korea") {
                        launchSingleTop = true
                    }
                }) {
                    Text(text = "한국으로 이동")
                }

                Button(onClick = {
                    navController.navigate("America")
                }) {
                    Text(text = "미국으로 이동")
                }
                Button(onClick = {
                    navController.navigate("Japan")
                }) {
                    Text(text = "일본으로 이동")
                }

                Button(onClick = {
                    navController.navigate("Argument/Mexico")
                }) {
                    Text(text = "멕시코로 이동")
                }
            }
        }

startDestination을 설정하는 NavHost를 만들었고, NavHost 내부 즉 NavBackStackEntry에 composable을 추가합니다

각 화면은 composable 함수로 정의되고 compose은 NavHostBuilder의 composable로 아래의 paramater들을 가질 수 있습니다

위의 예제에선 route를 "Korea"으로 설정합니다

여러 화면을 왔다갔다 하는 예제를 보면 아래와 같습니다

@Composable
fun NavTest(
    modifier: Modifier = Modifier,
    navController : NavHostController = rememberNavController()
) {
    NavHost(
        navController = navController,
        startDestination = "Korea",
        modifier = modifier
    ) {
        composable("Korea") {

            Column {
                Text("한국이에요  ")
                Spacer(modifier = Modifier.size(10.dp))
                Button(onClick = {
                    navController.navigate("Korea") {
                        launchSingleTop = true
                    }
                }) {
                    Text(text = "한국으로 이동")
                }

                Button(onClick = {
                    navController.navigate("America")
                }) {
                    Text(text = "미국으로 이동")
                }
                Button(onClick = {
                    navController.navigate("Japan")
                }) {
                    Text(text = "일본으로 이동")
                }

                Button(onClick = {
                    navController.navigate("Argument/Mexico")
                }) {
                    Text(text = "멕시코로 이동")
                }
            }
        }

        composable("America") {
            Column {
                Text("미국입니다   ")
                Button(onClick = {
                    navController.navigate("Korea")
                }) {
                    Text(text = "한국으로 이동")
                }
                Button(onClick = {
                    navController.navigate("Japan")
                }) {
                    Text(text = "일본으로 이동")
                }
            }
        }


        composable("Japan") {
            Column {
                Text("일본입니다  ")
                Button(onClick = {
                    navController.navigate("Korea")
                }) {
                    Text(text = "한국으로 이동")
                }
            }
        }

        composable("Argument/{countryName}") { navBackStackEntry ->
            val countryName = navBackStackEntry.arguments?.getString("countryName")
            Text("Argument/$countryName")
            Button({
                navController.navigate("Argument/Mexico")
            }) {
                Text("Argument/Mexico로 이동")
            }
        }

        composable("Argument/Mexico") {
            Text("멕시코입니다  ")
        }
    }
}

navigate의 인자로는 다양하게 들어갈 수 있어요

destination (String) : ex) "Korea", "America"
args (Bundle?) : ex) navController.navigate("Argument/$countryName")와 같이 사용
options (NavOptions?) : NavOptions 객체를 통해 애니메이션, 화면 전환 방식 등을 설정 가능

val navOptions = NavOptions.Builder()
                .setEnterAnim(R.anim.slide_in_right)  // 진입 애니메이션
                .setExitAnim(R.anim.slide_out_left)    // 퇴장 애니메이션
                .setPopEnterAnim(R.anim.slide_in_left)  // 뒤로 가기 시 진입 애니메이션
                .setPopExitAnim(R.anim.slide_out_right)  // 뒤로 가기 시 퇴장 애니메이션
                .build()
                
navController.navigate("detail", navOptions)

builder (NavOptionsBuilder.() -> Unit)

 Button(onClick = {
            navController.navigate("Japan") {
                // NavOptionsBuilder를 사용하여 네비게이션 옵션 설정
                launchSingleTop = true // 이미 존재하는 화면으로 이동할 때 중복 생성 방지
                restoreState = true // 이전 상태 복원
                popUpTo("Korea") {
                    inclusive = true 
                }
            }
        }) {
            Text("한국으로 이동")
        }

이런식으로 다양한 옵션을 설정할 수 있습니다

launchSingleTop은 기존 안드로이드에서의 개념과 똑같아요

popUpTo는 현재 스택에서 지정한 목적지(destination)까지의 모든 화면을 제거

만약 Korea -> Japan -> Mexico -> Korea의 스택일 때 popUpTo("Korea")를 하면 빈 스택이 됩니다.

inclusive는 popUpTo와 함께 사용되는데, popUpTo에서 화면을 제거할 때 특정 목적지 화면을 포함할지 여부를 결정

inclusive가 true로 설정되면, 지정한 목적지 화면도 스택에서 제거됩니다. 기본값은 false이구요

만약 Korea -> Japan -> Mexico -> Korea의 스택일 때 popUpTo("Korea") { inclusive = false } 를 하게 되면

"Korea"까지의 모든 화면이 제거되지만, "Korea" 자체는 포함되지 않으므로 남게 됩니다

궁금하신 점이나 의견이 있으시면 댓글 부탁드립니다 감사합니다

[Compose] Theme

콩드로이드 — Wed, 22 Jan 2025 17:47:24 +0900

프로젝트를 생성하면 기본으로 프로젝트명Theme가 생성되어있습니다

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            ComposeTestTheme  {

            }
        }
    }
}

ComposeTestTheme으로 이동하면 아래와 같이 선언되어있습니다

package com.kong.composetest.ui.theme

import android.app.Activity
import android.os.Build
import androidx.compose.foundation.isSystemInDarkTheme
import androidx.compose.material3.MaterialTheme
import androidx.compose.material3.darkColorScheme
import androidx.compose.material3.dynamicDarkColorScheme
import androidx.compose.material3.dynamicLightColorScheme
import androidx.compose.material3.lightColorScheme
import androidx.compose.runtime.Composable
import androidx.compose.ui.graphics.Color
import androidx.compose.ui.platform.LocalContext

private val DarkColorScheme = darkColorScheme(
    primary = Purple80,
    secondary = PurpleGrey80,
    tertiary = Pink80,
    surface = Color.Black,
    onSurface = Color.White
)

private val LightColorScheme = lightColorScheme(
    primary = Color.Green,
    secondary = PurpleGrey40,
    tertiary = Pink40,
    surface = Color.Black

    /* Other default colors to override
    background = Color(0xFFFFFBFE),
    surface = Color(0xFFFFFBFE),
    onPrimary = Color.White,
    onSecondary = Color.White,
    onTertiary = Color.White,
    onBackground = Color(0xFF1C1B1F),
    onSurface = Color(0xFF1C1B1F),
    */
)

@Composable
fun ComposeTestTheme(
    darkTheme: Boolean = isSystemInDarkTheme(),
    // Dynamic color is available on Android 12+
    dynamicColor: Boolean = true,
    content: @Composable () -> Unit
) {
    val colorScheme = LightColorScheme

    MaterialTheme(
        colorScheme = colorScheme,
        typography = Typography,
        content = content
    )
}

몇개만 알아보자면, 원래 안드로이드 테마와 비슷합니다

- darkColorScheme / lightColorScheme: 다크모드 / 라이트모드 에서 적용할 색상들

- primary, secondary, tertiary: 애플리케이션에서 사용되는 주요 색상, ex) primary는 주요 버튼이나 강조되는 component에 사용

- 보통 primary, onPrimary / surface, onSurface처럼 XXX, onXXX를 짝을 이뤄서 사용

예를 들어, primary: 주로 버튼, 강조된 텍스트 등에서 사용되는 기본 색상 / onPrimary: primary 색상 위에 놓이는 텍스트나 아이콘의 색상

이런식으로 일관성을 유지하게 짝으로 사용된다고 합니다

아래처럼 프로젝트의 ui.theme에서도 확인 가능합니다

[Compose] compositionLocal

콩드로이드 — Tue, 21 Jan 2025 16:54:49 +0900

CompositionLocal을 통해 전역 상태를 선언, 이를 CompositionLocalProvider를 사용해 하위 Composable에 전달할 수 있다

특정 값을 하위 Composable에주입하는 데 유용함

val LocalExampleValue = compositionLocalOf { "기본 값" }

@Composable
fun ParentComposable() {
    CompositionLocalProvider(LocalExampleValue provides "제공된 값") {
        ChildComposable()
    }
}

@Composable
fun ChildComposable() {
    val value = LocalExampleValue.current
    Text(text = value) // "제공된 값"이 표시됨..! 
    
}

제공된 값이 표시되는 이유는 current에서 가장 가까운 곳에서 설정한 값을 가져오기 때문에 !

전역으로 설정하기엔 좋을 거 같은데 추적이 힘들 거 같다

찾아보니, CompositionLocalProvider는 전역 상태 공유, 의존성 주입, UI 컨텍스트 제공 등의 상황에서 주로 사용된다고 한다

[Compose] viewModel , LiveData

콩드로이드 — Tue, 21 Jan 2025 15:30:09 +0900

우선 라이브러리를 추가합니다

[libs.version.toml]

[versions]
//...
viewModelVersion = "2.8.7"
composeVersion = "1.7.2" // 현재 사용 중인 compose 버전

[libraries]
//...
androidx-viewmodel-compose = { group = "androidx.lifecycle", name = "lifecycle-viewmodel-compose", version.ref="viewModelVersion"}
androidx-livedata-compose = { group = "androidx.compose.runtime", name = "runtime-livedata", version.ref = "composeVersion" }

[build.gradle] app

implementation(libs.androidx.viewmodel.compose)
implementation(libs.androidx.livedata.compose)

viewModel을 상속받는 클래스를 하나 만들어줍니다

class ToDoViewModel: ViewModel() {
    val (text, setText) =
        androidx.compose.runtime.mutableStateOf("")
}

근데 여기서 val (text, setText)에 레드라인이 생기고 아래와 같은 메시지가 떠요

구조 분해 선언은 지역 변수나 지역 값에 대해서만 사용할 수 있어요 즉 , 구조 분해 선언(destructuring declarations)은 한 클래스 내에 종속될 수 없기 때문에 위와 같은 에러가 뜹니다

그래서 이렇게 바꿔줍니다

class ToDoViewModel: ViewModel() {
    val text = mutableStateOf("")
}

ViewModel을 param으로 받는 composable func에서 viewModel의 값을 가져오거나, 변경해야한다면 아래와 같이 쓸 수 있습니다

@Composable
fun Test(viewModel: ToDoViewModel = viewModel()) {
	//...
    	ToDoInput(
                text = viewModel.text.value,
                onTextChange = {
                    viewModel.text.value = it
                },
                onSubmit = onSubmit
            )
            
}


@Composable
fun ToDoInput(
    text: String,
    onTextChange: (String) -> Unit,
    onSubmit: (String) -> Unit
) {
    Row(modifier = Modifier.padding(8.dp)) {
        OutlinedTextField(
            value = text,
            onValueChange = onTextChange,
            modifier = Modifier.weight(1f)
        )
        Spacer(modifier = Modifier.size(8.dp))
        Button(onClick = {
            onSubmit(text)
        }) {
            Text("입력")
        }
    }
}

viewModel로 상태를 옮길 수 있고, 상태를 옮기는 경우에는 remember를 쓰지 않습니다

(remember는 composable 함수의 생명주기에 맞춰 동작하기 때문에)

그리고, ViewModel을 사용하여 상태를 관리하면 상태가 생명주기와 더 잘 분리되고, 당연히 구성 변경시에도 상태를 유지합니다

이제 위에서 했던 예제들을 LiveData로 변경해보겠습니다

먼저, viewmodel을 상속받은 곳에서 아래와 같이 변경을 해줍니다

텍스트는 liveData화 시키고, 텍스트의 값을 변경하는 것을 viewModel로 가져옵니다

    val text = MutableLiveData("")
    val setText : (String) -> Unit = {
        text.value = it
    }

그리고 composable 함수에서 text의 값을 liveData를 쓰는 게 아니라, 그 값을 상태로 변환해서 가져옵니다

@Composable
fun Test(viewModel: ToDoViewModel = viewModel()) {
	//...
    	ToDoInput(
                text = viewModel.text.observeAsState("").value,
                onTextChange = {
                    viewModel.setText
                },
                onSubmit = onSubmit
            )
            
}

상태로 변환해서 사용하는 이유 ? -> Compose의 핵심 기능이 상태 기반 프레임워크이기 때문에, Compose 내의 값들은 당연히 상태를 기반으로 해야 Compose를 사용하는 의미가 있다..!

그리고 LiveData를 사용할 때 주의할 점인 viewModel 외부에서 MutableLiveData에 직접 접근해서 수정하지 못하도록 해야하기 때문에 위의 viewModel을 다시 수정합니다

    val _text = MutableLiveData("")
    val text: LiveData<String> get() = _text
    
    val setText : (String) -> Unit = {
        _text.value = it
    }

만약 ViewModel에서 리스트를 관리하고 싶다면 Livedata로 선언하고 이걸 state로 변환하는 것은 추천하지 않는 방법이라고 합니다

그 이유는, observeAsState의 원형을 보면 DisposableEffect에서 this(LiveData)를 받아서 호출하게 되는데

이 때 LiveData의 Observer는 리스트의 참조가 변경이 되어야 이 observer가 호출되기 때문에 매번 리스트 전체를 갱신해줘야 호출이 된다 -> 아주 ..

@Composable
fun <R, T : R> LiveData<T>.observeAsState(initial: R): State<R> {
    val lifecycleOwner = LocalLifecycleOwner.current
    val state = remember {
        @Suppress("UNCHECKED_CAST") /* Initialized values of a LiveData<T> must be a T */
        mutableStateOf(if (isInitialized) value as T else initial)
    }
    DisposableEffect(this, lifecycleOwner) {
        val observer = Observer<T> { state.value = it }
        observe(lifecycleOwner, observer)
        onDispose { removeObserver(observer) }
    }
    return state
}

그래서 compose에서는 mutableStateListOf를 많이 사용한다고 합니다

[프로그래머스 / Kotlin ] 귤 고르기

콩드로이드 — Mon, 20 Jan 2025 20:32:35 +0900

k개를 고를 때 크기가 서로 다른 종류가 총 몇개가 되는지에 대한 문제

처음엔 서로 다른 종류 중 가장 적은 무게를 구하는 줄 알았는데 그게 아니라 단순히 서로 다른 종류 수의 최솟값이다

1. 우선 빈도수 별로 배열을 정리해야겠다고 생각 -> Map<무게, 빈도수> 로 바꾸기

var map = tangerine.toList().groupingBy{ it }.eachCount()

k가 2일 때 [1,1,1,1,2,2,2,3]은 이렇게 정렬된다

{1=4, 2=3, 3=1}

2. 빈도수가 높은 순으로 내림차순 정렬

it.value를 더해서 k보다 같거나 크면 끝이니까..!

val sortedEntries = map.entries.sortedByDescending { it.value }

3. 서로 다른 종류가 몇 종류가 들어가야하는지 계산

k가 2일 때를 기준으로 하면 무게가 1인 귤 4개로만 해도 충분하니 더 이상 계산할 필요가 없다고 생각했다

var count = 0

for (entry in sortedEntries) {
    count += entry.value
    answer += 1

    if (count >= k) {
        break
    }
}

만약, k가 4일 경우에는 {2 = 2, 3 = 2, 5 = 2, 1=1, 4=1} 이렇게 정렬될텐데,

구하고자 하는 게 가장 적은 무게의 조합도 아니고, 그냥 서로 다른 종류가 몇개가 되는 게 최소한인지 구하는 거니까

정렬하고 entry의 value들을 더해가면서(카운팅 시작) 그 합이 K보다 크거나 같아지면 break 하면 된다고 생각했다!

잘 푼 건지는 모르겠다..!

스스로 풀어냈음에 의의를 두..기..

[Compose] Compose 주의점

콩드로이드 — Fri, 17 Jan 2025 13:37:29 +0900

1. Scaffold 사용 시 padding

예전엔 Scaffold의 content에 직접 Column을 배치해도 문제가 없었는데, 최근 Studio 버전에서는 Lint 검사가 강화되어서 Scaffold의 content에 padding을 적용해야 경고, 오류가 안 뜬다

❌

⭕️

2. Card의 elevation

예전에는 Card의 elevation 속성에 직접 Dp 값 사용가능

- Material Design 3로 업데이트 되면서 CardElevation 객체를 사용하도록 변경됨

❌

⭕️

3. LazyColumn items

- LazyColumn의 items 함수에 List<T>를 직접 전달해 아이템 표시가 가능했는데 Compose 1.2.0 버전부터는 items 함수가 변경되어 더 이상 List<T>를 직접 전달할 수 없다

- Compose 1.2.0부터 LazyColumn의 items 함수는 count와 itemContent 파라미터를 사용하도록 변경

❌

⭕️

[Compose] SideEffect

콩드로이드 — Thu, 16 Jan 2025 17:25:46 +0900

SideEffect

- Composable 함수는 입력 값이 변경될 때마다 재실행되며, UI를 업데이트. 하지만, UI 업데이트와 직접적인 관련이 없고, Composable 함수의 재실행 시마다 반복적으로 실행될 필요가 없는 작업이 side-effect

- 즉, 상태 값과 직접적으로 관련 없는 UI 작업들이 Composable 함수에서 불필요하게 재호출되는 것을 방지하기 위해 사용

LaunchedEffect : Composable 안에서 suspend func 실행

- 하나 이상의 key를 paramater로 받아야 한다 (ex. error.value)

- key가 바뀌지 않는 이상 같은 코루틴을 사용하고, key가 바뀌면 기존 코루틴을 취소하고 다시 코루틴을 만들어 실행

fun test(
    flavors: State<List<Flavor>>,
    error: State<Throwable?>,
    scaffoldState: ScaffoldState = rememberScaffoldState()
) {
    LaunchedEffect(error.value) {
        val errorMessage = error.value?.message ?: return@LaunchedEffect
        scaffoldState.snackbarHostState.showSnackbar(
            message = errorMessage,
            actionLabel = "show toast"
        )
    }

    // ... flavors를 사용하여 UI를 구성 ...
}

rememberCoroutineScope

- Composable 내에서 코루틴을 시작하기 위한 방법을 제공하여 더 이상 필요하지 않을 때 적절하게 관리, 취소됨

@Composable
fun MyComposable() {
    val scope = rememberCoroutineScope()
    val snackbarHostState = remember { SnackbarHostState() }

    Button(onClick = {
        scope.launch {
            snackbarHostState.showSnackbar("Hello from coroutine!")
        }
    }) {
        Text("Show Snackbar")
    }

    SnackbarHost(hostState = snackbarHostState)
}

rememberUpdateState:

- 값이 변경되더라도 LaunchedEffect가 다시 시작되지 않도록 하면서 최신 값에 접근해야 할 때 사용 즉, LaunchedEffect 내부에서 사용되는 값이 변경되더라도 LaunchedEffect가 다시 시작되지 않아야 하는 경우 (ex. 타이머, 지속되어야하는 애니메이션 같은 경우)에 LaunchedEffect를 다시 시작하지 않고도 최신 값에 접근

- rememberUpdatedState는 값이 변경될 때마다 내부적으로 최신 값을 업데이트하지만, LaunchedEffect의 key로 사용되지 않기 때문에 LaunchedEffect에는 영향 X

@Composable
fun MyScreen(text: String) {
    val currentText = rememberUpdatedState(text) // currentText는 MutableState<String> 타입

    LaunchedEffect(Unit) {
        while (true) {
            delay(1000)
            val currentTextValue = currentText.value // currentText.value를 통해 최신 값에 접근
            println("The latest text is: $currentTextValue") 
        }
    }

    Text(text = text)
}

값을 새 값으로 변경해주는 것 밖에 없음..!

DisposableEffect: Composable 함수가 Composition에서 제거될 때 리소스를 해제하기 위해 사용

- lifecycleOwner를 key로 받음

- 리소스 관리에 용이

@Composable
fun MyScreen(lifecycleOwner: LifecycleOwner = LocalLifecycleOwner.current) {
    DisposableEffect(lifecycleOwner) {
        val observer = LifecycleEventObserver { _, event ->
            if (event == Lifecycle.Event.ON_RESUME) {
                // 리소스 초기화 또는 시작
            } else if (event == Lifecycle.Event.ON_PAUSE) {
                // 리소스 해제 또는 중지
            }
        }
        lifecycleOwner.lifecycle.addObserver(observer)

        onDispose {
            lifecycleOwner.lifecycle.removeObserver(observer)
        }
    }
}

SideEffect

- 매 recomposition마다 호출됨 (이게 헷갈릴 수 있다)

- Composable 함수가 처음 Composition에 추가될 때, SideEffect 내부의 코드가 실행 O
- Composable 함수가 재구성될 때, SideEffect 내부의 코드는 다시 실행 X
- Composable 함수가 Composition에서 제거될 때, SideEffect 내부의 코드는 실행 X

@Composable
fun MyScreen(count: Int) {
    SideEffect {
        println("SideEffect called!") 
    }

    Text("Count: $count")
}

SideEffect called!는 한번만 찍힌다..!

즉, 매 Recomposition마다 호출은 되지만 SideEffect { } 내부가 실행되진 않는다!

그래서 로그를 남기거나, analytics 이벤트를 전송하는 작업들이 SideEffect에 넣기 좋다

productState: 비 compose 상태를 compose 상태로 변환

- 비동기적로 상태를 업데이트하고, 그 결과를 State<T>로 반환하는 함수

@Composable
fun MyScreen() {
    val counterState = produceState(initialValue = 0) {
        while (true) {
            delay(1000)
            value++ 
        }
    }

    Text("Counter: ${counterState.value}")
}

ProduceStateScope를 통해 상태를 업데이트..!

- produceState는 내부적으로 remember를 사용하여 mutableStateOf(initialValue)를 생성
- LaunchedEffect(Unit)을 사용하여 비동기 작업을 시작
- producer lambda 내부에서 ProduceStateScope를 통해 상태를 업데이트하면, mutableStateOf의 값이 변경 (예제에선 value ++)

derivedStateOf: Compose에서 다른 상태 값을 기반으로 새로운 상태 값을 계산하여 생성하는 함수

- 상태의 값이 바뀌지 않으면 그 값을 유지 (derivedStateOf는 내부적으로 계산된 값을 캐싱하고 있기 때문에, 값이 같다면 value 변경 X)

- 계산된 값이 바뀔 때만 state의 value가 바뀜 -> 불필요한 재구성 방지: derivedStateOf는 필요한 경우에만 상태 값을 다시 계산하여 업데이트

@Composable
fun MyScreen() {
    var counter by remember { mutableStateOf(0) }
    val doubledCounter by remember { derivedStateOf { counter * 2 } }

    Column {
        Button(onClick = { counter++ }) { Text("Increment Counter") }
        Text("Counter: $counter")
        Text("Doubled Counter: $doubledCounter")
    }
}

snapshotFlow

- Compose State를 Flow로 변환하여 State 값의 변경 사항을 비동기적으로 collect하도록 하는 함수

- 이전에 방출한 값과 다를 경우에만 방출 즉, State 값이 변경되면 snapshotFlow는 새로운 값을 Flow로 방출

var counter by remember { mutableStateOf(0) }

LaunchedEffect(Unit) {
    snapshotFlow { counter }
        .collect { newCounter ->
            println("Counter updated: $newCounter")
        }
}

Counter updated: 0 만 찍히고 그 후엔 안 찍힘

[Compose] Animation

콩드로이드 — Wed, 8 Jan 2025 20:04:16 +0900

AnimatedVisibility

- visibility에 Animated 적용

- Transition이 enter, exit 따로 나눠져있다

- FadeTransition: 나타날 때, 사라질 때 투명도를 조절해 부드럽게 변하는 효과
- SlideTransition: 화면의 한 쪽에서 다른 쪽으로 이동하며 나타나고 사라지는 효과
- ExpandTransition: 펼쳐지거나 축소되며 나타나고 사라지는 효과, 주로 패널이나 리스트 항목에 사용
- ScaleTransition: 크기를 확대하거나 축소하면서 나타나거나 사라지는 효과

이런 식으로 사용 ..! textVisible은 아래와 같이 선언되어있다

var textVisible by remember { mutableStateOf(false) }

AnimatedVisibility(
    visible = textVisible,
    enter = expandHorizontally(),
    exit = shrinkHorizontally()
) {
    Text("Animation Test")
}


Row(
    modifier = Modifier.selectable(
        selected = textVisible,
        onClick = {
            textVisible = true
        }
    ),
    verticalAlignment = Alignment.CenterVertically
) {
    RadioButton(
        selected = textVisible,
        onClick = {
            textVisible = true
        }
    )

    Text(text = "본다")
}

Row(
    modifier = Modifier.selectable(
        selected = !textVisible,
        onClick = {
            textVisible = false
        }
    ),
    verticalAlignment = Alignment.CenterVertically
) {
    RadioButton(
        selected = !textVisible,
        onClick = {
            textVisible = false
        }
    )

    Text(text = "안 본다")
}

만약, 컬러를 변경시키고 싶다면

val bgColor by animateColorAsState(
    targetValue = if(isDefault) Color(0xffcecece) else Color(0xff0094ff), 
    label = ""
)

위와 비슷한 두 개의 row를 눌러가며 테스트 해볼 수 있다

Row(
    modifier = Modifier.selectable(
        selected = isDefault,
        onClick = {
            isDefault = true
        }
    ),
    verticalAlignment = Alignment.CenterVertically
) {
    RadioButton(
        selected = isDefault,
        onClick = {
            isDefault = true
        }
    )

    Text(text = "default")
}

Row(
    modifier = Modifier.selectable(
        selected = !isDefault,
        onClick = {
            isDefault = false
        }
    ),
    verticalAlignment = Alignment.CenterVertically
) {
    RadioButton(
        selected = !isDefault,
        onClick = {
            isDefault = false
        }
    )

    Text(text = "blue")
}

Crossfade

Crossfade는 두 개의 UI 요소 간에 부드러운 전환 효과, 주로 상태에 따라 서로 다른 UI를 표시할 때 사용된다

좀 더 다이나믹한 UI 애니메이션 표시할 때 주로 사용

@Composable
fun MyCrossfadeExample() {
    var isFirstState by remember { mutableStateOf(true) }

    Column(
        modifier = Modifier.fillMaxSize(),
        verticalArrangement = Arrangement.Center,
        horizontalAlignment = Alignment.CenterHorizontally
    ) {
        // Crossfade를 사용하여 상태에 따라 UI 전환
        Crossfade(
            targetState = isFirstState,
            label = "text crossfade") 
        { state ->
            if (state) {
                Text("첫 번째 상태", modifier = Modifier.padding(16.dp))
            } else {
                Text("두 번째 상태", modifier = Modifier.padding(16.dp))
            }
        }

        // 상태 변경 버튼
        Button(onClick = { isFirstState = !isFirstState }) {
            Text("상태 변경")
        }
    }

[Compose] State, StateHoisting

콩드로이드 — Tue, 7 Jan 2025 20:41:42 +0900

상태가 전달되는 범위는 최대한 좁혀야한다 -> StateHoisting (상태를 위로 끌어올린다)

@Composable
fun StateTest() {
    var downCase by rememberSaveable { mutableStateOf("aa") }
    var upperCase by rememberSaveable { mutableStateOf("AA") }


    Column(modifier = Modifier.padding(16.dp)) {
        OutlinedTextField(
            value = downCase,
            onValueChange = {
                if(it.isBlank()) {
                    downCase = ""
                    upperCase = ""
                    return@OutlinedTextField
                }
                downCase = it
                upperCase = downCase.uppercase()
            },
            label = {
                Text("소문자")
            }
        )

        OutlinedTextField(
            value = upperCase,
            onValueChange =  {
                upperCase = it
            },
            label = {
                Text("대문자")
            }
        )
    }
}

이렇게 잘 나오지만, 하위 컴포넌트는 상태에 대한 의존성을 갖게 되므로 이걸 최대한 분리하는 게 좋다고 한다

상위 컴포넌트가 상태를 가질 수 있게끔 -> 테스트가 쉬워지고, 상태를 한 곳에만 몰아둘 수 있다

@Composable
fun StateTest() {
    var downCase by rememberSaveable { mutableStateOf("aa") }
    var upperCase by rememberSaveable { mutableStateOf("AA") }

    DownToUpperStateless(
        downCase,
        upperCase) {
        if(it.isBlank()) {
            downCase = ""
            upperCase = ""
            return@DownToUpperStateless
        }
        downCase = it
        upperCase = downCase.uppercase()
    }

}

//상태를 모르고 전혀 개입하지 X
@Composable
fun DownToUpperStateless(
    downCase: String,
    upperCase: String,
    onDownChanged: (String) -> Unit
) {
    Column(modifier = Modifier.padding(16.dp)) {
        OutlinedTextField(
            value = downCase,
            onValueChange = onDownChanged,
            label = {
                Text("소문자")
            }
        )

        OutlinedTextField(
            value = upperCase,
            onValueChange = onDownChanged,
            label = {
                Text("대문자")
            }
        )
    }
}

즉, UI와 상태가 분리되고, 재사용성, 테스트 용이성도 좋아진다

후에 state를 ViewModel에서 관리하게 할 때도 쉬울 거 같아

[Compose] BottomAppBar

콩드로이드 — Tue, 7 Jan 2025 20:11:37 +0900

원하는 ref들은 content를 사용해 추가해야함을 알 수 있다

보통 scaffold와 함께 사용한다, 자주 사용하는 bottombar의 형식인 5가지 버튼을 공부했던 내용들을 사용해 생성해보자

@SuppressLint("UnusedMaterial3ScaffoldPaddingParameter")
@Composable
fun WholeTest() {
    Scaffold(
        bottomBar = { MyBottomAppBar() }
    ) {  innerPadding ->

    }
}

@Composable
fun MyBottomAppBar() {
    BottomAppBar {
        ConstraintLayout(
            modifier = Modifier.fillMaxWidth()
        ) {

            val (button1, button2, button3, button4, button5) = createRefs()
            
            IconButton(
                onClick = {  },
                modifier = Modifier.constrainAs(button1) {
                    start.linkTo(parent.start)
                    end.linkTo(button2.start)
                    width = Dimension.wrapContent
                }
            ) {
                Icon(Icons.Filled.Home, contentDescription = "Home")
            }
            
            IconButton(
                onClick = {  },
                modifier = Modifier.constrainAs(button2) {
                    start.linkTo(button1.end)
                    end.linkTo(button3.start)
                    width = Dimension.wrapContent
                }
            ) {
                Icon(Icons.Filled.Favorite, contentDescription = "Favorite")
            }
            
            IconButton(
                onClick = {  },
                modifier = Modifier.constrainAs(button3) {
                    start.linkTo(button2.end)
                    end.linkTo(button4.start)
                    width = Dimension.wrapContent
                }
            ) {
                Icon(Icons.Filled.Search, contentDescription = "Search")
            }
            
            IconButton(
                onClick = {  },
                modifier = Modifier.constrainAs(button4) {
                    start.linkTo(button3.end)
                    end.linkTo(button5.start)
                    width = Dimension.wrapContent
                }
            ) {
                Icon(Icons.Filled.Notifications, contentDescription = "Notifications")
            }
            
            IconButton(
                onClick = {  },
                modifier = Modifier.constrainAs(button5) {
                    start.linkTo(button4.end)
                    end.linkTo(parent.end)
                    width = Dimension.wrapContent
                }
            ) {
                Icon(Icons.Filled.Settings, contentDescription = "Settings")
            }

            // 각 버튼 사이에 균등한 간격을 주기 위해 chain을 설정
            createHorizontalChain(button1, button2, button3, button4, button5)
        }
    }
}

화면엔 이렇게 보인ㄷㅏ ~

[Compose] Snackbar

콩드로이드 — Tue, 7 Jan 2025 19:36:40 +0900

SnackbarHost

- Snackbar는 직접 쓰지 않고 SnackbarHost를 사용해야한다 -> SnackbarHostState를 사용하여 Snackbar의 상태를 관리

@Composable
fun SnackBarTest() {
    var counter by remember { mutableStateOf(0) }

    val snackbarHostState = remember { SnackbarHostState() }
    val coroutineScope = rememberCoroutineScope()


    Scaffold(snackbarHost = { SnackbarHost(snackbarHostState) },) { padding ->
        Button(onClick = {
            counter++
            coroutineScope.launch {
                snackbarHostState.showSnackbar(
                    message = "Hello, Snackbar! count = $counter",
                    actionLabel = "close",
                    duration = SnackbarDuration.Short)
            }
        }, modifier = Modifier.padding(padding)) {
            Text("더하기")
        }
    }
}

- SnackbarHostState: remember { SnackbarHostState() }를 사용하여 Snackbar의 상태 관리
- Scaffold: Scaffold를 사용하여 기본 레이아웃을 설정하고, snackbarHost 매개변수에 SnackbarHost(snackbarHostState)를 전달

CoroutineScope내에서 실행하는 이유

: Snackbar의 showSnackbar 메서드는 suspend 함수로 정의됨 -> Snackbar는 CoroutineScope 내에서 실행되어야 한다

[Compose] ConstraintLayout, ConstraintSet

콩드로이드 — Tue, 7 Jan 2025 14:47:15 +0900

library 추가 필요

[libs.version.toml]

[versions]
//...
constaraintLayoutVersion = "1.1.0"

[libraries]
//...
androidx-constraint-layout = { group = "androidx.constraintlayout", name = "constraintlayout-compose", version.ref = "constaraintLayoutVersion" }

[plugins]
//...

createRefs()

- constraintLayout 안에 있는 여러 UI 요소(예: 버튼, 텍스트 등)를 서로 연결하고 배치할 수 있는 참조를 생성

@Stable
fun createRefs(): ConstraintLayoutScope.ConstrainedLayoutReferences =
    referencesObject ?: ConstrainedLayoutReferences().also { referencesObject = it }

ConstrainedLayoutReferences를 보면 총 16개까지의 제약 조건을 설정가능, 16개 이상이 필요하면 여러번 호출하면 된다

inner class ConstrainedLayoutReferences internal constructor() {
    operator fun component1(): ConstrainedLayoutReference = createRef()

    operator fun component2(): ConstrainedLayoutReference = createRef()

    operator fun component3(): ConstrainedLayoutReference = createRef()

    operator fun component4(): ConstrainedLayoutReference = createRef()

    operator fun component5(): ConstrainedLayoutReference = createRef()

    operator fun component6(): ConstrainedLayoutReference = createRef()

    operator fun component7(): ConstrainedLayoutReference = createRef()

    operator fun component8(): ConstrainedLayoutReference = createRef()

    operator fun component9(): ConstrainedLayoutReference = createRef()

    operator fun component10(): ConstrainedLayoutReference = createRef()

    operator fun component11(): ConstrainedLayoutReference = createRef()

    operator fun component12(): ConstrainedLayoutReference = createRef()

    operator fun component13(): ConstrainedLayoutReference = createRef()

    operator fun component14(): ConstrainedLayoutReference = createRef()

    operator fun component15(): ConstrainedLayoutReference = createRef()

    operator fun component16(): ConstrainedLayoutReference = createRef()
}

val (first, second, third) = createRefs()

Box(
    modifier = Modifier.size(40.dp)
        .background(Color.Red)
        .constrainAs(first) {//box가 어디에 위치해야할지 랜더링
            bottom.linkTo(parent.bottom)
        }
)

이 예시로 본다면

Box는 first가 되며 box의 bottom은 parent의 bottom에 연결된다

기존의 constraintBottomToBottom="parent"의 의미

fun linkTo(
    anchor: ConstraintLayoutBaseScope.HorizontalAnchor,
    margin: Dp = 0.dp,
    goneMargin: Dp = 0.dp
)

linkTo는 위와 같이 margin, goneMargin 값도 설정 가능하다

ConstraintLayout( modifier = Modifier.fillMaxSize()) {
     // 여러개의 reference return
    val (first, second, third) = createRefs()

    Box(
        modifier = Modifier.size(40.dp)
            .background(Color.Red)
            .constrainAs(first) {//box가 어디에 위치해야할지 랜더링
                top.linkTo(parent.top, margin = 8.dp)
            }
    )

    Text(
        text = "second Text",
        modifier = Modifier.constrainAs(second) {
            top.linkTo(first.bottom)
        }
    )
}

linkTo는 꼭 parent에 붙는게 아니다 (xml에서의 constraint를 생각할 것)

가운데 정렬은 기존의 constraint에서와 달리

centerTo(ref), centerVerticallyTo(ref), centerHorizontallyTo(ref)로 사용 가능

Text(
    text = "second Text",
    modifier = Modifier.constrainAs(second) {
        centerTo(parent)
    }
)

Chain

이렇게 3개의 ref를 선언한 후

val (first, second, third) = createRefs()

Box(
    modifier = Modifier.size(40.dp)
        .background(Color.Red)
        .constrainAs(first) {

        }
)

Box(
    modifier = Modifier.size(40.dp)
        .background(Color.Cyan)
        .constrainAs(second) {

        }
)

Box(
    modifier = Modifier.size(40.dp)
        .background(Color.Black)
        .constrainAs(third) {

        }
)

createVerticalChain(first, second, third)

수직으로 3가지 ref의 체인을 생성하면 동일한 간격으로 수평 체인이 생성됩니다

param으로 ChainStyle을 지정할 수 있는데 (Packed, Spread(default), SpreadInside)

createVerticalChain(first, second, third, chainStyle = ChainStyle.Packed)

packed / spreadInside

Packed
- 뷰들이 서로 가까이 모여서 배치
- 체인 내의 뷰들은 중앙에 위치하며, 남는 공간은 양쪽에 균등하게 분배

Spread
- 뷰들이 체인 내에서 가능한 한 멀리 떨어져 배치
- 체인 내의 뷰들은 양쪽 끝에 위치하고(끝 사이에 공백있음), 남는 공간은 뷰들 사이에 균등하게 분배

SpreadInside
- 이 스타일은 Spread와 유사하지만, 체인의 양 끝에 있는 뷰는 끝에 고정되고, 나머지 뷰들 사이에만 간격이 균등하게 분배
- 즉, 체인 내의 첫 번째와 마지막 뷰는 끝에 위치하고, 중간 뷰들 사이에만 간격 생김

Barrier

- 여러 뷰의 경계를 기준으로 제약 조건 설정

- Barrier는 수평 또는 수직 방향으로 설정 가능

val (first, second, third, txt) = createRefs()

Box(
    modifier = Modifier.size(40.dp)
        .background(Color.Red)
        .constrainAs(first) {
            top.linkTo(parent.top)
        }
)

Box(
    modifier = Modifier.size(40.dp)
        .background(Color.Cyan)
        .constrainAs(second) {
            top.linkTo(parent.top)
        }
)

Box(
    modifier = Modifier.size(40.dp)
        .background(Color.Black)
        .constrainAs(third) {
            top.linkTo(parent.top, margin = 32.dp)
        }

)

createHorizontalChain(first, second, third, chainStyle = ChainStyle.SpreadInside)

val barrier = createBottomBarrier(first, second, third)

Text(" barrier 위치를 잘 보세요",
    modifier = Modifier.constrainAs(txt) {
        top.linkTo(barrier)
        end.linkTo(parent.end)
    }
)

이렇게 한다면 margin이 적용된 third의 bottom을 기준으로 barrier가 생긴다

ConstraintSet

- 제약 조건을 modifier에서 선언하지 않고 ConstraintSet을 선언해 밖으로 빼내는 방법

    val constraintSet = ConstraintSet { //여기서 제약 설정
        val box = createRefFor("box")
        val txt = createRefFor("txt")

        constrain(box) {
            top.linkTo(parent.top, margin = 8.dp)
        }

        constrain(txt) {
            centerTo(parent)
        }
    }

    ConstraintLayout(modifier = Modifier.fillMaxSize(), constraintSet = constraintSet) {
        Box(
            modifier = Modifier.size(40.dp)
                .background(Color.Red)
                .layoutId("box")
//                .constrainAs(first) {
//                    top.linkTo(parent.top, margin = 8.dp)
//                }
        )

        Text(
            text = "second Text",
            modifier = Modifier
                .layoutId("txt")
//            modifier = Modifier.constrainAs(second) {
//                centerTo(parent)
//            }
        )
    }

1️⃣ ConstraintSet 선언 createRefFor(id)를 통해 식별자 생성

2️⃣ Constrain(원하는 ref) { 원하는 제약 조건 설정 }

3️⃣ ConstraintLayout에 param으로 ConstraintSet 선언

4️⃣ ConstraintLayout에서 원하는 제약 조건이 필요한 곳에 Modifier의 layoutId에 ConstraintSet에서 설정한 id를 설정

레이아웃 구조가 복잡해지면 ConstraintSet으로 빼내는 게 더 좋을 거 같다

[Compose] Recomposition

콩드로이드 — Mon, 6 Jan 2025 20:37:57 +0900

Composition

- composable을 호출해 만들어지는 것으로 ui를 기술하는 composable의 트리 구조

compose의 단계

Composition

- composable fun을 실행하고 ui를 표시

Layout

- ui를 배치

Draw

- ui를 랜더링 즉, 캔버스에 그림

⭐️ Recomposition

- state가 바뀌었을 때 변경된 state를 반영하기 위해 Composition 업데이트

- ui를 변경하기 위해선 state가 변경되어야 함

Recomposition을 조절하려면 ?

@Stable이 없어도 compose complier가 안정적으로 간주하는 타입

- 모든 Primitive 타입, 문자열, 모든 함수 타입

위의 타입들이 아니라면 안정적이라고 간주할 수 없을 때 (ex. 리스트, 맵, 사용자 정의 객체 등) @Stable 표기해야하면 된다

@Stable을 사용해야 하는 이유

성능 최적화: Compose는 해당 타입의 인스턴스가 변경되지 않는다고 가정하고, 불필요한 재조정을 방지 -> 성능 향상

⚠️ 리스트와 같은 UI 요소를 다룰 때, 각 아이템에 고유한 키를 부여하는 것이 중요합니다. 키가 없거나 잘못된 경우, Compose는 아이템을 올바르게 추적하지 못해 불필요한 recomposition이 발생할 수 있습니다

[Compose] scaffold

콩드로이드 — Mon, 6 Jan 2025 16:46:24 +0900

scaffold

- slot api의 확장

- paramater로 여러 슬롯을 제공하여 다양한 UI(ex : topBar, bottomBar, floatingActionButton, drawerContent, content)을 쉽게 정의하고 구성 가능

- 기본틀로 사용하면 체계적으로 개발하기 좋다

- Scaffold는 기본적으로 content 슬롯에 패딩을 적용해야하고 아니면 아래와 같은 에러가 뜬다

Content padding parameter it is not used More

@OptIn(ExperimentalMaterial3Api::class)
@Composable
fun ScaffoldTest() {
    var checked by remember { mutableStateOf(false) }

    Scaffold(
        topBar = {
            TopAppBar(
                navigationIcon =  {
                    IconButton(onClick = { }) {
                        Image(imageVector = Icons.AutoMirrored.Filled.ArrowBack, contentDescription = null)
                    }
                },
                title = { Text("Scaffold TopBar") }
            )
        }
    ) { paddingValues ->
        Surface(modifier = Modifier.padding(paddingValues)) {
            CheckBoxText(checked, onCheckedChanged = {
                checked = !checked
            }) {
                Text("check box")
            }
        }
    }

}

@Composable
fun CheckBoxText(checked: Boolean,
                 onCheckedChanged: () -> Unit,
                 content: @Composable RowScope.() -> Unit) {
    Row(verticalAlignment = Alignment.CenterVertically,
        modifier = Modifier.clickable {
            onCheckedChanged()
        }) {
        Checkbox(checked = checked,
            onCheckedChange = {
                onCheckedChanged()
            })
        content()
    }
}

[Compose] Slot API

콩드로이드 — Mon, 6 Jan 2025 16:26:55 +0900

- Composable 내에서 다른 Composable을 사용할 수 있도록 하는 패턴

@Composable
fun MyCustomCard(
    title: String,
    content: @Composable () -> Unit // Slot API를 사용하여 Composable을 매개변수로 받음
) {
    Card {
        Column {
            Text(text = title)
            content() // 전달된 Composable을 호출
        }
    }
}

@Composable
fun MyScreen() {
    MyCustomCard(title = "Hello") {
        Text("This is the content of the card.") // Slot에 전달된 Composable
    }
}

보통 content를 마지막 인자로 받아서 사용하는 경우가 많다

➡️ 고정된 ui를 가지지 않기에 유연성 , 재사용성에서 좋다

만약 content를 받지 않는다면 Text는 고정이 되므로, 좋지 않은 방식이다

@Composable
fun MyCustomCard(title: String) {
    Card {
        Column {
            Text(text = title)
            Text("This is the fixed content of the card.") // 고정된 내용
        }
    }
}

@Composable
fun MyScreen() {
    MyCustomCard(title = "Hello") // 이제 content를 전달할 필요 없음
}

만약 특정 Scope에서만 동작하는 composable함수라면

@Composable
fun MyCustomCard(
    title: String,
    content: @Composable RowScope.() -> Unit // RowScope를 사용하여 Composable을 매개변수로 받음
)

위와 같이 content에 RowScope 혹은 ColumnScope를 지정할 수도 있다

재사용성이 높아지도록 위임할 수 있는 것들은 최대한 위임해주는 게 좋다

[Compose] Component 알아보기 - TopAppBar

콩드로이드 — Sat, 4 Jan 2025 13:50:11 +0900

Column {
    TopAppBar(
        title = { Text(text = "보통의 앱 바") },
        navigationIcon = {
            IconButton(onClick = {}) {
                Icon(imageVector = Icons.AutoMirrored.Filled.ArrowBack,
                    contentDescription = null)
            }
        },
        actions = { // row Scope
            IconButton(onClick = {}) {
                Icon(imageVector = Icons.Filled.Edit,
                    contentDescription = null)
            }

            IconButton(onClick = {}) {
                Icon(imageVector = Icons.Filled.Check,
                    contentDescription = null)
            }
        }
    )
}

이런 식으로 생성된다

조절할 일은 아이콘 설정, 클릭 시 동작 이 정도일 거 같긴 하다 ..!

[Compose] Component 알아보기 - TextField

콩드로이드 — Sat, 4 Jan 2025 13:38:22 +0900

TextField = EditText

var name by remember { mutableStateOf("Myday") }
Column(modifier = Modifier.padding(4.dp)) {
    TextField(
        value = name,
        label = {
            Text(text = "name")
        },
        onValueChange = {
            name = it
        })
    
    Text(text = "입력값 $name")
}

Outline을 설정하고 싶으면 OutlinedTextField를 사용하면 된다

var name by remember { mutableStateOf("Myday") }
Column(modifier = Modifier.padding(4.dp)) {
    OutlinedTextField(
        value = name,
        label = {
            Text(text = "name")
        },
        onValueChange = {
            name = it
        })

    Text(text = "입력값 $name")
}

설정할 수 있는 값은 정말 많다..!

디자인에 따라서 여러개 조합해보면 재밌을거 같다

@Composable
fun TextField(
    value: String,
    onValueChange: (String) -> Unit,
    modifier: Modifier = Modifier,
    enabled: Boolean = true,
    readOnly: Boolean = false,
    textStyle: TextStyle = LocalTextStyle.current,
    label: @Composable (() -> Unit)? = null,
    placeholder: @Composable (() -> Unit)? = null,
    leadingIcon: @Composable (() -> Unit)? = null,
    trailingIcon: @Composable (() -> Unit)? = null,
    prefix: @Composable (() -> Unit)? = null,
    suffix: @Composable (() -> Unit)? = null,
    supportingText: @Composable (() -> Unit)? = null,
    isError: Boolean = false,
    visualTransformation: VisualTransformation = VisualTransformation.None,
    keyboardOptions: KeyboardOptions = KeyboardOptions.Default,
    keyboardActions: KeyboardActions = KeyboardActions.Default,
    singleLine: Boolean = false,
    maxLines: Int = if (singleLine) 1 else Int.MAX_VALUE,
    minLines: Int = 1,
    interactionSource: MutableInteractionSource = remember { MutableInteractionSource() },
    shape: Shape = TextFieldDefaults.shape,
    colors: TextFieldColors = TextFieldDefaults.colors()
)

[Compose] Component 알아보기 - CheckBox

콩드로이드 — Sat, 4 Jan 2025 13:15:22 +0900

CheckBox

Row(verticalAlignment = Alignment.CenterVertically) {
    Checkbox(checked = false, onCheckedChange = {

    })
    Text(text = "checkbox를 테스트해보자")
}

- 기존 안드로이드 view와는 달리 체크박스를 눌러도 ui상에 아무 변화가 없음

- checked 값이 바뀌어야만 ui가 갱신된다

그럼 이렇게 하면 될까 ?

❌ 변경되지 않는다 (primitive값만 바꾼다고 반영이 되는 게 아님)

compose에서는 Composable 함수 즉, recomposition을 시켜야만 반영된다

var checked = false
Checkbox(checked = checked, onCheckedChange = {
    checked = !checked
})
Text(text = "checkbox를 테스트해보자")

그럼 상태를 변경시켜보자

주의해야 할 점 아래와 같이 사용하면

var checked = mutableStateOf(false)

위와 같은 에러가 뜬다

Creating a state object during composition without using remember

Composable 함수 내에서 상태값을 생성하는데 remember를 쓰고 있지 않다

발생원인 : Composable 내에서 ui가 그려질 때 조금 그려지다가 다시 그려질 수 있는데(recomposition이 언제 발생할지 알 수 없다), remember가 없다면 상태값이 날아가버린다

즉, Composable은 언제든 다시 그려질 수 있다(recomposition) 그래서 상태값 주의해야한다

다시 본문으로 돌아가 체크박스의 상태를 변화하려면 아래와 같이 사용해야한다

Row(verticalAlignment = Alignment.CenterVertically) {

    var checked = remember { mutableStateOf(false) }

    Checkbox(checked = checked.value, onCheckedChange = {
        checked.value = !checked.value
    })
    Text(text = "checkbox를 테스트해보자")
}

만약 mutableStateOf의 값을 사용할 때 일일이 .value를 하기 번거롭다면

var checked by remember { mutableStateOf(false) }
Checkbox(checked = checked, onCheckedChange = {
    checked = !checked
})

Text(text = "checkbox를 테스트해보자")

이렇게 delegated 형식으로 사용하면 된다 아래의 방식을 사용하는 거라고 보면 된다

/**
 * Permits property delegation of `var`s using `by` for [MutableState].
 *
 * @sample androidx.compose.runtime.samples.DelegatedStateSample
 */
@Suppress("NOTHING_TO_INLINE")
inline operator fun <T> MutableState<T>.setValue(thisObj: Any?, property: KProperty<*>, value: T) {
    this.value = value
}

구조분해 사용하기

MutableState를 살펴보자면

- 값을 나타내는 value

- 값을 반환하는 component1 함수

-값을 설정하는 component2

@Stable
interface MutableState<T> : State<T> {
    override var value: T
    operator fun component1(): T
    operator fun component2(): (T) -> Unit
}

여기서 구조분해를 한다면 componentN에 해당하는 component1(getter), component2(setter)가 구조분해된다

그래서 아래와 같은 형태로도 쓸 수 있다

val (checked, setChecked) = remember { mutableStateOf(false) }

Checkbox(checked = checked, onCheckedChange = {
    //체크됐을 때 호출되므로 it 자체가 변경된 checked 값
    setChecked(it)
})

Text(text = "checkbox를 테스트해보자")

[Compose] Component 알아보기 - Image, Coil

콩드로이드 — Fri, 3 Jan 2025 21:13:29 +0900

Image

네트워크 없이 간단한 Image를 설정하는 3가지 방법이 있다

1. painter = painterResource 사용

2. imageVector = 벡터 이미지 사용

3. bitmap 사용

    Column {
        Image(
            painter = painterResource(R.drawable.simpson),
            contentDescription = "simpson")

        Image(
            imageVector = Icons.Filled.Face,
            contentDescription = "vector"
        )

        //bitmap은 순수 Composable 함수에선 사용할 수 없고
        //context가 있는 곳에서 주입받아야 한다
//        Image(
//            bitmap = ,
//            contentDescription = null
//        )
    }

기여운 심슨..

Coil 라이브러리 사용해서 이미지 가져오기

coil 라이브러리 추가하기

1. libs.version.toml

[versions]
coilVersion = "2.2.2"
coilComposeVersion = "2.2.2"

[libraries]
androidx-coil = { group = "io.coil-kt", name = "coil", version.ref = "coilVersion" }
androidx-coil-compose = { group = "io.coil-kt", name = "coil-compose", version.ref = "coilComposeVersion" }

2. build.gradle (app)

implementation(libs.androidx.coil)
implementation(libs.androidx.coil.compose)

rememberImagePainter

(deprecated됨..)

val painter = rememberImagePainter(
    data = "https://media.contentapi.ea.com/content/dam/eacom/images/2023/07/simpsons-hero-md-homepage-7x2-xl.jpg.adapt.crop7x2.1920w.jpg"

)
Column {
    Image(
        painter = painter,
        contentDescription = null)
}

AsyncImage

AsyncImage(
    model = "https://media.contentapi.ea.com/content/dam/eacom/images/2023/07/simpsons-hero-md-homepage-7x2-xl.jpg.adapt.crop7x2.1920w.jpg",
    contentDescription = null
)

[Compose] Component 알아보기 - BoxWithConstraints

콩드로이드 — Fri, 3 Jan 2025 20:27:30 +0900

BoxWithConstraints

- 부모의 제약 조건을 기반으로 크기를 조정

- 부모의 최대, 최소 크기의 정보를 제공

@Composable
fun BoxWithConstraintsTest(modifier: Modifier = Modifier) {
    BoxWithConstraints(
        modifier = modifier
    ) { //box scope
        Text("maxW: $maxWidth minW: $minWidth")
    }
}

선언된 BoxWithConstraintsTest를 사용해서 값을 modifier에 값을 넣어주면 전달된 값이 찍힌다

@Composable
fun Greeting() {
    Column {
        BoxWithConstraintsTest(Modifier.widthIn(min = 100.dp))
    }
}

[Compose] Component 알아보기 - Box, Row, Column

콩드로이드 — Fri, 3 Jan 2025 18:23:33 +0900

Box

Box 자체로 쓰거나 FrameLayout처럼 중첩시킬 때 사용된다

BoxScope내의 확장함수 2개 align, matchParentSize

Modifier.align

Box(modifier = Modifier.size(100.dp)) { // Box Scope
    Box(modifier = Modifier.size(70.dp).background(Color.Black).align(Alignment.CenterStart))
    Box(modifier = Modifier.size(70.dp).background(Color.Magenta).align(Alignment.BottomEnd))
}

중첩되는 걸 볼 수 있따

Modifier.matchParentSize()

- 자식 컴포넌트 중 가장 큰 크기에 의해 결정

- 두번째 box의 사이즈 80만큼만 생성된다

Box { // Box Scope
    Box(modifier = Modifier.matchParentSize().background(Color.Black).align(Alignment.CenterStart))
    Box(modifier = Modifier.size(80.dp).background(Color.Magenta).align(Alignment.Center))
}

fillMaxSize를 사용하면 그릴 수 있는 최대 영역만큼 그려지게 된다

Box { // Box Scope
    Box(modifier = Modifier.fillMaxSize().background(Color.Black).align(Alignment.CenterStart))
    Box(modifier = Modifier.size(80.dp).background(Color.Magenta).align(Alignment.Center))
}

Row

- 기본적으로 Horizontal 정렬 따라서 align은 항상 Vertical만 가능, arrangement는 row의 방향과 같이간다(Horizontal)

Row(modifier = Modifier.height(40.dp)) {
    Text(text= "First", modifier = Modifier.align(Alignment.Top))
    Text(text= "Second", modifier = Modifier.align(Alignment.CenterVertically))
    //Alignment.Center는 사용 불가 -> Center는 Horizontal, Vertical 둘 다 Center를 의미
    Text(text= "Third", modifier = Modifier.align(Alignment.Bottom))
    //Alignment.BottomStart, BottomEnd도 같은 이유로 사용 불가 
}

❌ Alignment.Center 사용 불가 -> Center는 Horizontal, Vertical 둘 다 Center를 의미

❌ Alignment.BottomStart, Alignment.BottomEnd도 같은 이유로 사용 불가

만약 Row 하위 요소들이 다 같은 방향의 Vertical Align을 가진다면 상위 Box에 Alignment 선언

(몇몇 하위 요소들도 개별적으로 설정 가능)

Row(
    verticalAlignment = Alignment.Bottom,
    modifier = Modifier.height(40.dp)
) {
    Text(text= "First")
    Text(text= "Second")
    Text(text= "Third")
}

horizontalArrangement

그 중에서 SpaceBetween, SpaceEvenly, SpaceArround만 비교해보자면

SpaceBetween : 자식 component들 사이에 간격

SpaceEvenly : 자식 component들 사이에 동일한 간격, 양 끝에도 동일한 간격 생성

SpaceArround : 자식 component들 사이에 동일한 간격, 양 끝에는 자식 component간 동일한 간격의 절반만큼 간격 생성

|--- A ---|--- B ---|--- C ---|

Column

- 기본적으로 Vertical 정렬 따라서 align은 항상 Horizontal만 가능, arrangement는 column의 방향과 같이간다(Vertical)

Column(
    horizontalAlignment = Alignment.Start,
    verticalArrangement = Arrangement.Center,
    modifier = Modifier.size(100.dp)
) {
    Text(text = "First", modifier = Modifier.background(Color.Blue))
    Text(text = "Second", modifier = Modifier.background(Color.Cyan))
    Text(text = "Third", modifier = Modifier.background(Color.Magenta))
}

Box는 2차원 alignment가 가능

Column과 Row는 각 기본 정렬방향과 반대인 1차원 Alignment만 가능하다

[Compose] Component 알아보기 - Surface

콩드로이드 — Fri, 3 Jan 2025 17:15:26 +0900

surface :

- 가장 기본적으로 UI를 구현하는 기반

elevation, border, shape, color 등 설정이 가능하다

contentColor를 설정하지 않으면 color에 따라서 contentColor가 자동으로 설정된다

(contentColor가 설정되지 않았다면, 이 Surface는 배경 색상을 테마의 ColorScheme에 정의된 색상에 맞는 ContentColor를 반환한다. 예를 들어, 이 Surface의 색상이 ColorScheme.surface라면, contentColor는 ColorScheme.onSurface로 설정된다)

 Surface(
        modifier = Modifier.padding(10.dp),
        shadowElevation = 10.dp,
        border = BorderStroke(2.dp, color = Color.Cyan),
        shape = CircleShape,
        color = MaterialTheme.colorScheme.background
    ) {
        Text("Test",
            modifier = Modifier.padding(8.dp))
    }

compose는 margin이 있는게 아니라 padding이 존재한다

만약, Surface내에 속한 Text component가 margin을 가져야한다면 Text에 padding을 주는게 아니라 surface에 패딩을 준다

Surface(
    modifier = Modifier.padding(5.dp)
) {
    Button({

    }) {
        Text("Test")
    }
}

[Compose] Component 알아보기 - Text, Button

콩드로이드 — Wed, 1 Jan 2025 19:19:37 +0900

Component들이 아직 손에 익지 않아서 테스트해보면서 몇가지만 기록해보려고 합니다

Text에서 색상, 폰트 크기, 폰트 굵기 변경 등 테스트해보겠습니다

가장 기본형태를 아래와 같다는 가정입니다 :)

커스텀하려면 parameter로 원하는 걸 추가하면 되는데 아직 손에 익지 않아서 하나씩 해보는 중입니다

Text(
      text = "Hello $name!",
      modifier = modifier
)

폰트 컬러 변경

Text(
        color = Color(0xff0094ff), //혹은 color = Color.Green 의 형태도 가능
        text = "Hello $name!",
        modifier = modifier
)

폰트 크기 변경

Text(
    color = Color(0xff0094ff),
    fontSize = 30.sp,
    text = "Hello $name!",
    modifier = modifier
)

폰트 weight 변경

Text(
    color = Color(0xff0094ff),
    fontSize = 30.sp,
    fontWeight = FontWeight.Bold,
    text = "Hello $name!",
    modifier = modifier
)

폰트 글꼴 변경

Text(
    color = Color(0xff0094ff),
    fontSize = 30.sp,
    fontWeight = FontWeight.Bold,
    fontFamily = FontFamily.Cursive,
    text = "Hello $name!",
    modifier = modifier
)

폰트 decoration 설정

Text(
    color = Color(0xff0094ff),
    fontSize = 30.sp,
    fontWeight = FontWeight.Bold,
    fontFamily = FontFamily.Cursive,
    text = "Hello $name!",
    letterSpacing = 3.sp,
    maxLines = 4,
    textDecoration = TextDecoration.LineThrough,
    modifier = modifier
)

그 외에도 Text 원형을 보고 원하는 parameter를 사용하면 될 거 같아요

Button은 onClick이 필수이고 기본적으로 RowScope입니다

@Composable
fun Button(
    onClick: () -> Unit,
    modifier: Modifier = Modifier,
    enabled: Boolean = true,
    shape: Shape = ButtonDefaults.shape,
    colors: ButtonColors = ButtonDefaults.buttonColors(),
    elevation: ButtonElevation? = ButtonDefaults.buttonElevation(),
    border: BorderStroke? = null,
    contentPadding: PaddingValues = ButtonDefaults.ContentPadding,
    interactionSource: MutableInteractionSource = remember { MutableInteractionSource() },
    content: @Composable RowScope.() -> Unit
)

버튼 클릭 시 Toast 출력

Composable 함수에서 paramater로 unit 설정 후 Activity의 setcontent 부분에서 Toast 출력 시켰습니당

@Composable
fun Greeting(onClicked: () -> Unit) {
    Button(onClick = onClicked) {
        Text(text = "button")
    }
}

Button에 다른 ui들 추가해보기

@Composable
fun Greeting(onClicked: () -> Unit) {
    Button(
        onClick = onClicked,
        enabled = false,
        border = BorderStroke(1.dp, Color.Black), // border width, color 설정 
        shape = RoundedCornerShape(10.dp), // paramater로 radius 조절
        contentPadding = PaddingValues(16.dp) // 공통, 개별 설정 가능
    )
    { // 버튼 내의 ui
        Icon(
            imageVector = Icons.Filled.Edit,
            contentDescription = ""
        )
        Spacer(modifier = Modifier.size(ButtonDefaults.IconSpacing)) // 여백 설정
        Text(text = "button")
    }
}

Button의 색상 변경하기

button의 색상은 modifier로 변경이 안됩니다

button의 colors를 사용해야합니다

Button(
    colors = ButtonDefaults.buttonColors(
        containerColor = Color.Magenta, // 버튼 배경의 컬러
        contentColor = Color.Black // 버튼 content 컬러 
    ),
    onClick = onClicked,
    modifier = Modifier
        .size(width = 200.dp, height = 100.dp)
        .background(Color.Gray) //button에서는 modifier로 버튼의 색상을 변경할 수 없다 
)
{
    Icon(
        imageVector = Icons.Filled.Edit,
        contentDescription = null
    )
    Spacer(modifier = Modifier.size(ButtonDefaults.IconSpacing))
    Text(text = "button")
}

적용된 색상은 아래와 같습니다

[Compose] Compose 시작에 앞서

콩드로이드 — Wed, 1 Jan 2025 18:44:55 +0900

compose 구글에서 제공하던 캠프를 들은 적 있는데 다 까먹었어요

그래서 다시 공부합니다.. 시작하기 앞서 간단하게 끄적여봅니다

기존에 사용하던 안드로이드 UI는 XML을 사용해 레이아웃을 정의하고, Java나 Kotlin 코드를 통해 UI를 조작하는 명령형 방식인데 이와 달리 Compose는 선언형 UI입니다

선언형 UI

- 모든 컴포넌트가 상태를 가지고 각 컴포넌트는 자신의 상태를 기반으로 UI를 구성

- 상태가 변경되면 해당 컴포넌트가 자동으로 다시 그려져 최신 상태를 반영

compose를 시작하기 전 잘 이해해야할 부분들을 체크해가며 공부해야할 거 같아요

- 상태 관리에 대한 이해 필요(remember, mutableStateOf, State 등)

- 비동기 작업을 처리하는 방법에 대한 이해가 필요

Kong-droid

[Android] SharedPreferences 대신 DataStore #2

DataStore는 암호화를 자동으로 제공 X

EncryptedSharedPreferences Deprecated

Crypto API

라이브러리 추가

Master Key 생성

암호화/복호화

DataStore에 암호화 적용하기

[Android] SharedPreferences 대신 DataStore #1

SharedPreferences가 왜 더 이상 추천되지 않을까 ?

DataStore란 ?

2️⃣ Context기반으로 접근가능한 datastore 생성

3️⃣ 비동기 형태로 save, get 함수 생성

4️⃣ 저장, 불러오기

[Android] ForegroundService - SecurityException

1. android:foregroundServiceType 지정 (AndroidManifest.xml)

2. startForeground()호출 시 타입 명시

3. Runtime 권한(Prerequisites) 확인

정리하자면 Android 14에서는 포그라운드 서비스의 유형 선언, 권한 요청 시점이 모두 명확해야 합니다Manifest, startForeground(), 권한 요청 시점 — 이 세 개가 맞물리지 않으면 SecurityException이 발생할 수 있어요

[Android] AudioManager와 isSpeakerPhoneOn Deprecated

AudioManager란?

⚠️ isSpeakerphoneOn의 deprecated

[Android] 소켓 연결하기 - WebSocket , Socket.IO

WebSocket 연결

Socket IO 연결

[Android] 하나의 화면에 다양한 UI 블록을 구성하는 3가지 방식

FragmentContainerView 방식 (Fragment 삽입)

특징

장점

단점

addLayout()방식

특징

장점

단점

RecyclerView + ViewType 방식

특징

장점

단점

[Android] NetworkInfo Deprecated

과거 방식: NetworkInfo → 이제는 ❌

NetworkCapabilities

네트워크 연결 변화 감지하는 방식 (callback 기반)

입사 3개월차의 회고록

어느덧 3개월차...?

내가 새롭게 해본 것들

앞으로 나아갈 것들

스스로 아쉬웠던 점

☀️ 마무리

[Android] MVI 패턴, 이름을 왜이렇게 헷갈리게 지었어요?

MVI란?

MVI는 Model - View - Intent

MVI 흐름

자주 사용되는 타입들

왜 타입이 다를까?

- UIState → data class

- UIEvent, UIEffect → sealed class

✅

예시 코드

[Compose] XML처럼 TextField 쓰면 Compose에선 망해요

원인은 recomposition....

XML vs Compose

해결 방법: 입력은 입력만, 로직은 분리

Compose TextInput 사용 시 고려 사항

[Compose] LazyColumn 성능을 위해

✅ LazyColumn이란?

사용하면서 느낀 성능 관련 주의점

key 설정 필요

- Recomposition의 기준 설정

LazyColumn안의 forEach는 Compose가 추적 불가능

[Android / Compose] Compose Context

XML vs Compose의 "생명주기 + context" 구조 차이

XML 기반

Compose 기반

✅ 그래서 context는 명시적으로 전달해야 한다!

⚠️ 잊지말자

[Android] Widget 사용해보기

Widget

⚙️ Widget의 필수 구성 요소

위젯 동작 전체 흐름

정리하자면 Android 14에서는 포그라운드 서비스의 유형 선언, 권한 요청 시점이 모두 명확해야 합니다
Manifest, startForeground(), 권한 요청 시점 — 이 세 개가 맞물리지 않으면 SecurityException이 발생할 수 있어요

Q3. UseCase에서 Repository 호출하면, 결국 어차피 Repository의 구현체(RepositoryImpl)가 동작하는 거 아닐까?
그럼 UseCase를 사용할 필요가 있나?