Skip to content

Use Jetpack WorkManager instead of the custom implementation #882

Open
@bencehornak

Description

@bencehornak

I have stumbled upon the custom PeriodicWork implementation in the project, which is used by the disk buffering implementation to export signals:

Its API is quite similar to that of the JetPack WorkManager API so I assume that you guys consciously decided not to use it, but to provide an own implementation. If this decision is already documented somewhere, could you point me there?

Otherwise I'd like to propose to use the Jetpack/androidx implementation, which is Google's official recommendation for doing periodic background work. It relies on sophisticated decisions made by the OS to optimize, when the best moment is to launch background tasks. E.g. one can set certain constraints to schedule the work only when the device is online, or if it's not low on battery (which is what I would recommend to set by default).

If I understand it correctly, it would work with the current minSdk (21), see the androidx.work docs:

WorkManager uses an underlying job dispatching service when available based on the following criteria:

  • Uses JobScheduler for API 23+
  • Uses a custom AlarmManager + BroadcastReceiver implementation for API 14-22

The downsides I can think of:

  1. I find it difficult to pass object references between Work objects and the rest of the code.
  2. Moreover, if the app developer decides to replace the default WorkManagerInitializer things get dirty very quickly.
  3. The minimum frequency is 1x every 15 minutes

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions