사용 버전: 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/ Coroutine

오늘은 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로 구성됩니다. •  created (생성 시각)  •  expires (종료 시각) •  nonce (signatur