Glacier's Daily Log

Compose Preview에서 다양한 옵션 한번에 지원하기Jetpack Compose는 빌드 없이 @Preview 기능을 통해 UI를 빠르게 확인할 수 있는 장점이 있습니다.개발 중 컴포넌트의 다양한 옵션을 테스트하거나, 여러 화면 크기에서 어떻게 보이는지 확인하고 싶을 때가 있습니다.기존 방식 (비효율적인 코드)예를 들어, BannerView를 다양한 화면 크기에서 테스트하고 싶다면 다음과 같이 각각의 @Preview를 지정해야 했습니다.@Preview(widthDp = 180)@Composableprivate fun BannerPreview180() {BannerView(onClick = {})}@Preview(widthDp = 240)@Composableprivate fun BannerPrevie..

최근에 리액트 네이티브로 개발할 일이 있어서 난생 처음으로 리액트 네이티브 개발환경을 구축해보았다. 해당 프로젝트에서 내 임무는, Android SDK31 (안드로이드11) 기준으로 targetSdk 된 소스를, 플레이스토어에 다시 올리기 위해 SDK34 이상으로 올려야하는 것이였다. 말로는 간단해보이지만, 사실 이런 크로스플랫폼 언어로는 굉장히 까다로운 작업이다. 1. android 의존성 폴더 내 gradle과 모든 config를 SDK34 기준으로 업데이트 (gradle, agp 버전 업 등이 있겠다)2. 안드로이드 버전 업데이트에 따른 react-native 라이브러리 업데이트 (내 기준 0.71.5에서 0.74.0으로 업데이트 해야 빌드가 되는 상황이였다.)3. react-native 라이브러리..

Strong Skipping Mode의 람다 메모라이제이션 기능Strong Skipping Mode는 Compose가 람다를 처리하는 방식을 개선해 리컴포지션 최적화를 자동으로 지원할 수 있음. 이 기능은 Compose 1.5.0 이상에서 활성화되며, 람다 사용 시 리컴포지션을 방지할 수 있도록 자동으로 최적화를 제공할 수 있음.람다 메모라이제이션의 기본 원리Compose는 람다가 이전과 동일한 객체인지 확인해 리컴포지션을 건너뛸 수 있을지 판단함. 이전 Compose에서는 람다가 새로운 객체로 간주되면 리컴포지션이 발생했지만, Strong Skipping Mode에서는 이를 자동으로 메모라이제이션하여 불필요한 리컴포지션을 줄일 수 있음.1. 람다의 안정성 판단Strong Skipping Mode는 람다..

Jetpack Compose는 Recomposition 최적화에 관심을 가지고 개발해야 완성도가 높은 결과물을 기대할 수 있다.최적화 방안 중 하나인, Stability를 고려하는 방법에 대해 알아보자.Compose는 Stability(안정성)와 Recomposability(리컴포지션 가능성)를 기반으로 효율적으로 리컴포지션을 수행한다.1. Stability (안정성)Stability는 데이터가 불변(Immutable) 또는 변경이 없을 것으로 예측되는지를 나타냄.안정성은 @Stable 어노테이션 또는 컴파일러 분석에 의해 결정됨.Stable Class:객체의 상태가 변하지 않거나 변화를 잘 감지할 수 있는 클래스.Kotlin의 data class나 ImmutableList 같은 불변 객체가 이에 해당함..

안녕하세요, 크몽, 위시켓, 개인 채널 등에서 활동하고 있는 안드로이드 개발자 Glacier 입니다.최근 다양한 채널에서 블루투스, RESTful API 등을 통한 외부 기기와의 통신이 가능한 앱 개발 의뢰가 많이 들어와서 블로그에도 홍보글 한번 올려보게 되었습니다. 연락 채널 : https://open.kakao.com/me/glacier Glacier님의 오픈프로필코딩 / 안드로이드 개발 Mentoropen.kakao.com기기 연동 안드로이드 앱 개발 전문 서비스BLE, MQTT, TCP, RTSP, PTZ 등 다양한 통신 프로토콜을 활용한 맞춤형 기기 연동 앱 개발 서비스를 제공합니다.이런 기능이 필요하신가요?BLE(블루투스 저에너지)로 디바이스 연결 및 데이터 송수신 (아두이노 우노, 라즈베리파..

ℹ️ 배경 회사에서 개발 중 기능의 공통화를 위해서 여러 클래스의 상위 클래스를 제작하였다. 작업 중 상위카드인 ~~~~~.kt에 선언된 var root: SomeDto? = null 를 상속받은 클래스에서 사용할 일이 생겼다. ☢️ 이슈 코틀린에서는 간단하게 직접 변수명으로 접근할 수 있지만, Kotlin으로 선언된 클래스를 상속받은 Java 코드에서는 Setter/Getter를 통해서 접근할 수 밖에 없는 문제가 생겼다. 따라서 기존에 root로 접근하던 수많은 코드를 모두 getRoot()로 변경해주어야 하는 상황이 발생했다. ✅ 해결 @JvmField Instructs the Kotlin compiler not to generate getters/setters for this property an..