IssueTracker

Can you describe your use case?

The only way currently is as a side-effect of using unique work (which can permanently delete your old work with that name).

So, I made an app that checks if there was a change to a website, like every 30 min (user customizable, global settings for now).

When user opens my app, I think would be nice to make a refresh and reset the worker, so that it retry again in 30 minutes (not less, since some of that time was elapsed already). There will also be some settings, like changing this time period, or temporarily disabling the worker.

How should I proceed? On my head I thought about killing/removing everything on app open, then making the refresh and enqueuing a new worker. On settings, same. Killing the current worker and making a new one (or none, if the pause option is set).

BTW, there is no cancelUniqueWork on PeriodicWorkRequest, which is what I'm attempting to do.

I think your use-case maybe a better fit for a OneTimeWorkRequest. You just need to schedule yourself, with an initial delay at the end of doWork() to have the granular control you want.
Also, with PeriodicWork, the only way to change the period and flex times, are to cancel and reschedule. The OneTimeWorkRequest approach (which schedules itself at the end) might be an easier way to do it, especially if you want everything to be driven by a user defined config.

I modified my app to use a one time, unique work request that calls itself at the end and it worked fine! In the coming days I'll release it on github. This thing, however, is incredibly powerful. I'm not sure if it is a feature, but, while testing, I was able to fetch more than 40 times per minute, even with the app force closed.

Anyway, awesome work. I still wish there was a better way to cancel/remove works that are not unique, better documentation for the periodic request (and a way to remove it from the queue, in case someone falls in the same pitfall as I did).

Could you please explain what you mean by fetching more than 40 times per minute?  Does that mean you're effectively creating a period of 1-2 seconds?

I made a beginUniqueWork with no delay and no constraint at the end of my Worker/doWork() (which makes a okhttp call, returns success, and create a notification when the call ends), put another beginUniqueWork on my OnCreate, compiled the app, opened it, and watched chaos happen. Then force-closed it, and chaos still happened.

Which version of Android are you testing on?

Also, if you were wanted to get behavior similar to a PeriodicWorkRequest, you want to set an initial delay on the Work being enqueued at the end of doWork().

Android 8.

I basically created a PeriodicWorkRequest without the minimum 15min limit - which again, I'm not sure if this is a bug or a feature. This is my code:

override fun doWork(): Worker.WorkerResult {

       // this launch is required to avoid this bug: https://github.com/googlesamples/android-architecture-components/issues/356
        launch {
            Thread.sleep(1)
           
            // from https://github.com/Karn/notify, just to keep it brief and see the app is still alive
            Notify
                .with(applicationContext)
                .content {
                    title = "New dessert menu"
                    text = "The Cheesecake Factory has a new dessert for you to try!"
                }
                .show()
        reloadWorkManager()
        }
        return WorkerResult.SUCCESS
    }


fun reloadWorkManager(){
            WorkManager.getInstance().cancelUniqueWork("work")
       
            val photoWork = OneTimeWorkRequest.Builder(
                SyncWorker::class.java)
                .setInitialDelay(1, TimeUnit.SECONDS)
                .setConstraints(workerConstraints.build())
                .build()

            WorkManager.getInstance().beginUniqueWork("work", ExistingWorkPolicy.REPLACE, photoWork).enqueue()
        }

You will be able to do this in alpha03 using a new method called pruneWork.