
💡 Source : https://dongsik93.github.io/til/2020/05/15/til-jetpack-workmanager/
위의 조건들 중 어느것도 해당되지 않는다면 앱이 백그라운드에 있는 것으로 간주된다

앞서 말한 것과 같이,
WorkManager는 사용자가 화면을 벗어나 이동하거나, 앱이 종료되거나, 기기가 다시 시작되도라도 안정적으로 실행되어야 하는 작업을 대상으로 설계되었다.
이런 예시가 그 작업에 해당한다.
하지만, 항상 WorkManager를 사용해서 백그라운드 작업을 처리해야 되는 것은 아니다.
사용자가 앱을 백그라운드로 전환하거나 기기를 다시 시작하더라도 즉시 실행해야 하며 지속적인 처리가 필요한 작업의 경우
WorkManager를 이용하는 것이 좋다.
또한 사용자에 의해 정확한 때를 정해놓지 않고 향후 언제든지 실행할 수 있는 모든 Defferable 작업은WorkManager로 해결하는 것이 좋다.
사용자가 특정 범위를 벗어나거나 인터렉션을 완료할 때 종료해야 하는 작업에는
coroutine을 사용하는 것이 좋다.
위의 상황과 반대로, 정확한 시점에 실행해야 하는 작업에는
AlarmManager를 사용하여 해결해야 된다.
sunflower를 살펴 보면 MainApplication 클래스에서 WorkManager의 Configuration.Provider클래스를 상속 받고 있는 것을 알 수 있다.
Configuration.Provider
WorkManager에Configuration을 제공하는 인터페이스이다- 요구사항대로
WorkManager를 초기화한다Configuration
객체로서, 초기화를 통해WorkManager를 커스터마이징 하기 위해 사용된다.
기본적으로WorkManager는 앱이 시작될 때 대부분의 앱에 적합한 합리적인 옵션을 사용하여 자동으로 구성되는데,WorkManager가 작업을 관리하고 예약하는 방법을 더 제어해야 하는 경우WorkManager를 직접 초기화하여WorkManager구성을 맞춤설정할 수 있다.
WorkManager를 맞춤 초기화하는 방법주문형 초기화(on-demand initialization) 를 사용하는 것이 좋다. (단, WorkManager 2.1.0 이상에서 지원)
on-demand방식을 적용하면 WorkManager가 앱이 시작될 때마다가 아닌, 구성요소가 필요할 때만 만들어지고 앱 시작 성능이 향상된다.
만약 자신의 프로젝트에서 사용하는 WorkManager 라이브러리가 2.6 버전 이상이라면 공식문서를 참고하길 바란다. 나는 2.4 버전이기에 해당 버전을 기준으로 해결방법을 적어보면...
AndroidManifest.xml 파일에서 provider 태그에서 workmanager-init 을 삭제한다
<provider
android:name="androidx.work.impl.WorkManagerInitializer"
android:authorities="${applicationId}.workmanager-init"
tools:node="remove" />
Application 클래스에서 Configuration.Provider 인터페이스를 구현하고, getWorkManagerConfiguration()를 override하여 자체 구현한다. 보통 logging 관련 코드를 추가한다
import androidx.work.Configuration
class MainApplication : Application(), Configuration.Provider {
override fun getWorkManagerConfiguration(): Configuration =
Configuration.Builder().build()
}
build.gradle(project)
ext {
...
workVersion = '2.4.0'
...
}
build.gradle(app)
dependencies {
...
implementation "androidx.work:work-runtime-ktx:$rootProject.workVersion"
...
}