lou@blog $ _

ViewModel의 init {} 블록에서 상태를 초기화하는 것은 편리해보인다.나도 프로젝트에서 종종 그렇게 해 오고는 했는데, 그렇게 하지말라는 이유는 다음과 같다. 1. ViewModel 생성과 강하게 커플링됨데이터를 가져오는 타이밍이 ViewModel 생성시에 있기 때문에, 새로고침 등 사용자 상호작용이나 기타 이벤트에 따라 데이터 로딩시점을 제어하기 어렵게 만든다.  2. 테스트하기 어려움ViewModel이 생성되자마자 데이터 로드가 시작되므로 1번의 이유로 인해 테스트하기 어려워진다.  3. 리소스 낭비의 가능성앱이나 화면에 진입하자마자 데이터를 필요로 하지 않을 경우, 자원의 비효율적인 사용으로 이어질 수 있음. 4. UI 응답성init {} 블록은 최대한 가볍게 유지해야한다. 여기에서 메인 ..

ViewModel의 생성자에 있는 모든 의존성들을 Lazy Inject하라는 것은 아니지만, 드물게 사용하는 것들은 Lazy로 바꿈으로서 초기화 성능을 개선할 수 있다. 의존성이 실제로 필요할때만 주입되므로 이로인한 이점은 다음과 같다. 1. 빠른 시작2. 더 낮은 메모리 점유율3. CPU 부하 감소 Lazy Initialization을 사용해야하는 경우- 규모가 큰 의존성- 드물게 사용되는 의존성- 조건부 의존성 케이스 스터디@HiltViewModelclass BookViewModel @Inject constructor( @IoDispatcher private val ioDispatcher: CoroutineDispatcher, private val bookmarkUseCase: dagger..

앱에서 정확한 시간마다 작업을 수행해야할때 Timer.scheduledAtFixedRate를 사용하던 중, 기이한 로그가 발견되었다. 바로 아주 짧은 시간에 여러번 호출되는 현상! 문서를 보면 메소드에 대한 대략적인 설명은 이렇다. scheduleAtFixedRate(TimerTask task, Date firstTime, long period)Schedules the specified task for repeated fixed-rate execution, beginning at the specified time.지정된 시간부터 고정된 간격으로 반복적으로 작업을 수행하도록 예약한다. 이 "Fixed-rate execution"에는 함정이있다.메소드를 눌러 문서를 더 자세히 살펴보면 다음과 같은 문단을 발..

어이가 없는 모드인데 멀티에서 쓰면 재미있을것 같은... Bullets Boats!사진하나로 설명된다. 최신버전까지도 지원하는 Forge 모드다.

Android Jetpack 라이브러리 중 하나인 App Startup은 안드로이드 앱 구동에 필요한 초기 설정들을 체계적으로 초기화하는데 유용한 라이브러리다. 아래는 App Startup의 사용 예시 코드인데, dependencies 함수를 보면 예시 코드의 로거 Initializer는 WorkManagerInitializer에 의존하고 있음을 알 수 있다.// Initializes ExampleLogger.class ExampleLoggerInitializer : Initializer { override fun create(context: Context): ExampleLogger { // WorkManager.getInstance() is non-null only after ..