사용 버전: Android Studio Koala 2024.1.1 사용 언어: Kotlin 2.0.10 안드로이드 Migrate view to compose instrumented test를 알아보겠습니다. 먼저 View를 Compose로 변경하는 것을 알아보았고, https://shwoghk14.blogspot.com/2024/08/android-migrate-xml-view-to-compose.html XML themes를 compose를 변경하는 것도 알아보았습니다. https://shwoghk14.blogspot.com/2024/08/android-migrate-xml-themes-to-compose.html 이제 대망의 Instrumented(계측) test를 view에서 compose로 변경하는 것을 알아보겠습니다. View(뷰)의 경우 ActivityScenarioRule을 사용하게 됩니다. 이것을 우리는 AndroidComposeTestRule로 변경해야 합니다. Test가 있는 Module(모듈)의 build.gradle.kts로 갑니다. 설명을 위해 version catalog는 일단 제외했습니다. androidTestImplementation(platform("androidx.compose:compose-bom:2024.08.00")) androidTestImplementation("androidx.compose.ui:ui-test-junit4") Sync Now를 누릅니다. TranslateFragmentTest.kt ActivityScenario를 createAndroidComposeRule로 변경해 줍니다. Test에는 일반 Compose에서 Test를 하듯이 composeTestRule을 사용해 주면 됩니다. 끝. 카테고리: Android

사용 버전: Android Studio Koala 2024.1.1 사용 언어: Kotlin 2.0.10 안드로이드 Migrate XML themes to compose를 알아보겠습니다. 이전 이야기에서는 View(뷰)를 Compose로 변경하는 것을 다뤘습니다. https://shwoghk14.blogspot.com/2024/08/android-migrate-xml-view-to-compose.html 이번에는 XML(엑스엠엘)에 사용하는 Themes(테마)를 Compose(컴포즈)로 이전하는 것을 알아보겠습니다. 우선, Material theme builder가 필요합니다. https://material-foundation.github.io/material-theme-builder/ 그러면 위의 사이트에서 색깔을 정해봅시다. Primary, Secondary, Tertiary 등을 설정해 줍니다. 우리는 XML을 옮기는 것이기 때문에 XML에 있는 것을 적어줍니다. colors를 참고해서 위에 대입해 줍니다. 상단의 + 버튼을 누릅니다. Export - Theme Jetpack compose를 눌러줍니다. 다운로드됩니다. 압축을 해제하고 theme 파일을 적당한 곳에 옮겨줍니다. Theme.kt에 있는 AppTheme을 원하는 이름으로 변경해 줍니다. 저는 AboutSubnetMaskTheme으로 변경했습니다. 그리고 3개의 파일에 package를 본인의 package로 변경해 줍니다. 그 뒤, 사용하는 Compose를 위에서 넣은 AboutSubnetMaskTheme으로 감싸줍니다. 실행해 볼까요? 짜잔. 버튼 색깔이 잘 들어갔네요. 다음 이야기에서는 Instrumented(계측) test를 view에서 compose로 변경하는 방법을 알아보겠습니다. https://shwoghk14.blogspot.com/2024/08/android-migrate-view-to-compose-on.html 끝. 카테고리: Android

사용 버전: Android Studio Koala 2024.1.1 사용 언어: Kotlin 2.0.10 안드로이드 Migrate an xml view to compose를 알아보겠습니다. 오늘은 XML(엑스엠엘) View(뷰)로 만들어진 앱을 Compose(컴포즈)로 변경해 보는 작업을 해봅시다. 아쉽지만 Compose에 대한 설명은 없습니다. 이미 알고 계신다고 생각하고 진행할 거예요. 아래는 현재 XML로 작성된 제 앱입니다. 이걸 Compose로 변경할 것입니다. 재미있어 보이지 않나요? Compose로 변경할 때에는 보통 Fragment 단위로 변경하는 것을 추천합니다. 다시 말하자면, 화면 단위로 변경하는 것이죠. buildFeatures에 compose = true를 적어줍니다. dependencies에는 다음의 내용을 추가해 줍니다. 설명을 위해 version catalog는 적용하지 않았습니다. implementation(platform("androidx.compose:compose-bom:2024.08.00")) implementation("androidx.compose.material3:material3") implementation("androidx.compose.ui:ui-tooling-preview") debugImplementation("androidx.compose.ui:ui-tooling") Sync Now를 눌러줍니다. plugin에 compose compiler를 추가해 줍니다. Project 용 build.gradle id("org.jetbrains.kotlin.plugin.compose") version("2.0.10") apply false Sync Now를 눌러줍니다. compose를 적용할 모듈 용 build.gradle id("org.jetbrains.kotlin.plugin.compose") ...

사용 버전: Android Studio Koala 2024.1.1 사용 언어: Kotlin 2.0.10 안드로이드 코틀린 CoroutineScope and CoroutineContext를 알아보겠습니다. Coroutine(코루틴)에는 중요한 요소가 세 가지 정도 있습니다. CoroutineScope(코루틴 스코프), Job(잡), CoroutineContext(코루틴 컨텍스트)입니다. CoroutineScope는 모든 코루틴에 필요한 요소입니다. https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/-coroutine-scope/ CoroutineScope로 생명 주기를 관리할 수 있습니다. 보통 class의 생성 시, scope를 만들고, class의 소멸 시, scope를 취소합니다. scope가 취소되면 scope에 있는 모든 coroutine은 정지됩니다. CoroutineScope에는 기본적으로 CoroutineContext 4가지 요소가 들어갑니다.  Job, CoroutineDispatcher(코루틴 디스패처), CoroutineName(코루틴 이름) 그리고 CoroutineExceptionHandler(코루틴 익셉션 핸들러). 이러한 4가지 중 Job과 CoroutineDispatcher가 가장 많이 사용되는 CoroutineContext입니다. 미리 정의된 Scope들이 있습니다. GlobalScope, MainScope, supervisorScope, coroutineScope가 있으며, 안드로이드에서는 생명주기에 맞춰진 lifecycleScope, viewModelScope가 있으며, 테스트를 위한 TestScope도 존재합니다. Job부터 보겠습니다. https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/-job/ Corou...

오늘은 RFC 9421에 대해 알아보겠습니다. https://datatracker.ietf.org/doc/html/rfc9421 1. 기술이 생겨난 이유 보통 TLS를 많이 사용합니다. TLS는 하나의 연결만 보증하지 중계기 간의 연결은 보증할 수 없습니다. 또한, Application은 검증을 위해 TLS 인증서와 독립적인 key가 필요하기도 합니다. 그리고, 전체적인 message를 모르더라도 message를 보호할 수 있어야 합니다. JSON Web Signature의 경우 매번 중복된 payload가 필요하게 됩니다. HTTP message만을 위한 무결성과 검증 기술을 만들게 되었습니다. 2. 구성 목록   •  Signature base   •  Signature-Input   •  Signature   •  Accept-Signature 3. Signature base 중계기에서 HTTP 변형이 가능하기 때문에 bit 단위를 비교할 순 없습니다. 대신, 의미가 같은지를 확인합니다. 여기에 사용되는 것이 Signature base입니다. 아래는 signature base를 만드는 표현식입니다. 예시를 보시죠. 위의 HTTP Header는 아래의 Signature base로 표현될 수 있습니다. (Signature-Input을 바탕으로 생성) Component Identifier는 아래와 같습니다. •  Derived Component @method @target-url @authority @scheme @request-target @path @query @query-param @status •  Field-content accept 등 @signature-params Signature base 제일 마지막에 추가되며, 생성, 검증을 위한 metadata를 포함합니다. 서명되는 모든 항목과 추가적인 signature parameters로 구성됩니다. •  ...

사용 버전: Android Studio Koala 2024.1.1 안드로이드 코틀린 Queue refactoring을 알아보겠습니다. Queue(큐)는 기본적인 자료구조에 많이 등장하는 것으로 들어간 순서대로 나옵니다. 보통 배열로 사용하는 List보다 빠릅니다. 4년 전에 작성한 코드입니다. 나름 생각해서 만든 코드인데요. 광고가 4번째 칸마다 들어가도록 만든 로직입니다. 현재 보니 충분히 Queue로 로직을 변경할 수 있을 것 같아 보이네요. 원래 item(아이템)들을 하나의 큐에 넣고 광고를 또 다른 큐에 넣어줍니다. 두 개의 큐 중에 하나라도 다 떨어질 때까지 진행하면서 4번째 차례마다 광고를 꺼내서 넣어줍니다. 무한 반복이 끝난 후, 만약 남은 원래 item이 있다면 차례로 넣어줍니다. Kotlin에 있는 ArrayDeque(어레이 덱)를 사용해봅시다. Double Ended Queue의 준말입니다. https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/-array-deque/ 다음과 같이 refactoring(리펙토링) 되었습니다. 끝. 카테고리: Android

사용 버전: Android Studio Koala 2024.1.1 안드로이드 Unit tests with an android dependency를 알아보겠습니다. Unit(유닛) test(테스트) 또는 Local(로컬) test는 JVM에서 실행됩니다. 즉, Android와 관련된 패키지가 있다면 정상적으로 작동하지 않는다는 얘기입니다. 제 앱에 Unit test를 추가하다가 발견한 문제입니다. Domain(도메인)에 있는 Usecase(유즈케이스)가 test에 사용되었습니다. import android.net.InetAddresses import android.os.Build IP(아이피) 주소를 확인하기 위한 InetAddresses와 OS(운영체제)의 SDK(개발자 도구) 버전을 확인하기 위한 Build.VERSION.SDK_INT를 사용하였습니다. 보시다시피 android에 dependency(의존성)를 가집니다. 이러한 것을 해결하는 방법으로는 Mockito(모키토)를 사용하거나 android 의존성을 없애거나, Instrumented(계측) test에서 test를 진행하는 것입니다. 저는 InetAddresses를 Guava 라이브러리로 대체하며 os.Build도 같이 제거하였습니다. 이렇게 제거하니 test가 정상적으로 작동되더군요. import com.google.common.net.InetAddresses 끝. 카테고리: Android

사용 버전: Android Studio Koala 2024.1.1 안드로이드 Jetpack Navigation with multi-module을 알아보겠습니다. 현재 하나의 module(모듈)로 구성된 제 앱을 multi-module(멀티 모듈)로 변경하고 있습니다. 그러다 만난 난관이 있는데요. 바로 Jetpack(잿팩) Navigation(내비게이션)입니다. Navigation은 Fragment 간의 화면을 전환하는 데 도움을 주는 라이브러리입니다. 문제는 여기서 발생합니다. 제 앱이 이런 식으로 Modularization(모듈화)을 진행합니다. :app -> :feature -> :ui :app에 navigation.xml 파일을 두게 되면, :feature에서 :app을 보지 못해 navigate를 사용할 수 없게 됩니다. 반대로 이것을 :ui에 두게 되면, :ui는 :feature(피처)를 참조할 수 없어서 navigation.xml에 fragment(프레그먼트)를 참조할 수 없게 됩니다. 어떻게 해야 할까요? 저는 이렇게 해결했습니다. Navigation Graph(그래프)를 Kotlin DSL로 전환합니다. https://developer.android.com/guide/navigation/design/kotlin-dsl 그리고, navigation library는 Kotlin DSL에서 Type Safe Args를 사용할 수 있는 2.8.0-alpha08 이상으로 해줬습니다. https://developer.android.com/jetpack/androidx/releases/navigation#2.8.0-alpha08 Navigation graph를 다음과 같이 설정해 줍니다. 이것을 MainActivity에서 호출해 줍니다. Serializable은 :Model 모듈에 만들었습니다. 이러한 navigation.xml은 kotlin DSL로 변환하면, 이렇게 됩니다. 전체적인 구조는 :app, :features -> :model ...

사용 버전: Android Studio Koala 2024.1.1 안드로이드 BuildConfig를 알아보겠습니다. BuildConfig(빌드 컨피그)는 Build(빌드) 시에 자동으로 정보를 생성하여 Runtime(런타임)에 참조할 수 있도록 만들어주는 기능입니다. 참고 문서: https://developer.android.com/build/gradle-tips 현재 제 앱에서는 MainActiivty의 companion object에 Debug를 설정하는 코드를 사용하고 있습니다. 직접 Debug 모드를 설정할 수 있다는 점이 좋았는데요. 문제는 앱 구조를 Official android architecture(공식 안드로이드 아키텍처)로 변경하면서 MainActivity 의존성을 제거해야 하는 것이었습니다. 의존성 분리도 하고, DEBUG(디버그)를 확인할 때 좋은 것이 바로 BuildConfig 기능입니다. 사용할 module(모듈)의 gradle(그레이들)에 갑니다. buildFeatures 안에 buildConfig = true를 적어줍니다. Sync Now 및 Build를 해줍니다. 그 뒤 사용은 이렇게 합니다. 참고로 Build type에 따라서 새로운 buildConfigField를 만들 수도 있습니다. 아래는 IS_DEBUG라는 Field(필드)를 새로 만들어 봤습니다. BuildConfig 생성 위치는 module 이름 - build - generated - source - buildConfig - flavor 이름 - 패키지 이름 - BuildConfig.java입니다. BuildConfig.java를 보시면 이렇게 잘 들어간 모습을 볼 수 있습니다. 끝. 카테고리: Android