Glacier's Daily Log

최근에 리액트 네이티브로 개발할 일이 있어서 난생 처음으로 리액트 네이티브 개발환경을 구축해보았다. 해당 프로젝트에서 내 임무는, 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는 람다..

Strong Skipping Mode는 Compose Compiler 1.5.4 version에 실험적으로 추가된 기능이다.(Note: Strong Skipping is enabled by default in Kotlin 2.0.20.)Strong Skipping Mode기본적으로 Compose 컴파일러는 Composable Function의 arguments들이 안정적이라면 skippable 하다고 간주.이와 관련하여 Strong Skipping Mode가 skippable 한 파라미터를 더 잘 찾을 수 있게 함.1. 기존 Skipping Mode기존에는 다음 조건을 만족해야 리컴포지션이 Skip됨.:데이터가 Stable이어야 함.데이터가 변경되지 않았음을 Compose가 알 수 있어야 함.따라서 St..

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(블루투스 저에너지)로 디바이스 연결 및 데이터 송수신 (아두이노 우노, 라즈베리파..

안드로이드 개발을 코틀린으로 진행하다보면 Sealed, Open, Abstract 클래스를 많이 사용하게 된다. 자주 사용하다보면 어떤 상황에 쓰면 되는지 감은 오지만 정확히 정리해본적은 없는 것 같아서 시작한다. 코틀린에서 abstract, open, sealed, 그리고 기본 class는 각각의 용도와 제약 조건이 있다. 이들의 차이점과 공통점을 살펴보자.1. abstract, open, sealed 의 공통점모두 클래스이다. 코틀린에서 클래스는 객체 지향 프로그래밍의 기본 단위로, 인스턴스를 생성하거나 상속의 기반이 된다.모두 상속을 허용할 수 있는 클래스로 사용될 수 있지만, 어떤 클래스는 상속이 기본적으로 허용되지 않으며, 상속 가능 여부는 해당 키워드에 따라 결정된다.2. abstract, o..