IssueTracker

since these are in public API (:/) we need to do this in 1.2

Opening diff shortly

Project: platform/frameworks/support
Branch: androidx-master-dev

commit d576cbdc911cba16638a44fd8223391a90a07ef7
Author: Mike Nakhimovich <digitalbuddha@users.noreply.github.com>
Date:   Tue Aug 11 09:30:34 2020

    [GH] Hide deprecated internal API.
   
    ## Proposed Changes
   
    * `RoomDatabase.java` has protected `mCallbacks` field which is leaking in the API docs, we should @Hide it.
   
    ## Testing
   
    Test: Ran unit tests locally
   
    ## Issues Fixed
   
    Fixes: 76109329
   
    This is an imported pull request from https://github.com/androidx/androidx/pull/61.
   
    Resolves #61
    Github-Pr-Head-Sha: 6440daa3a63752c7f9d5ba2a390248cd85bc634f
    GitOrigin-RevId: fe92d8466a59b44b218b6ca3cbd57dcda17992f7
   
    Change-Id: Id599cdf5b02b32bdae0166266fb7da967598fe92

A       room/runtime/api/current.ignore
M       room/runtime/api/current.txt
M       room/runtime/api/public_plus_experimental_current.txt
M       room/runtime/api/restricted_current.txt
M       room/runtime/src/main/java/androidx/room/RoomDatabase.java

https://android-review.googlesource.com/1396827

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.