IssueTracker

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

commit b90079595f33f58fece04026a97faa0d243acdb1
Author: Yuichi Araki <yaraki@google.com>
Date:   Wed Sep 18 16:55:49 2019

    Change the way to detect mismatch between POJO and query
   
    This fixes cursor mismatch warnings with expandProjection.
   
    Bug: 140759491
    Test: QueryMethodProcessorTest
    Change-Id: I7659002e5e0d1ef60fc1af2a625c0c36da0664d8

M       room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M       room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M       room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
M       room/compiler/src/test/kotlin/androidx/room/processor/QueryMethodProcessorTest.kt
M       room/compiler/src/test/kotlin/androidx/room/testing/TestProcessor.kt

https://android-review.googlesource.com/1123258
https://goto.google.com/android-sha1/b90079595f33f58fece04026a97faa0d243acdb1

  The following changes were cherrypicked through Coastguard (https://android-build.googleplex.com/coastguard/)
  Release Track: (https://android-build.googleplex.com/coastguard/dashboard/6093116828680192/#/cherrypickHistory/all)
  Created: 2019-10-14 17:23:42.610596+00:00
  Changes: aosp/1123258
 

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

commit bdde5a1a970ddc9007b28de4aa29d60ffa588f08
Author: Yigit Boyar <yboyar@google.com>
Date:   Thu Apr 16 16:47:05 2020

    Re-factor how errors are dismissed when query is re-written
   
    This CL changes how we handle errors/warnings if query is
    re-written.
    There was a bug in expandProjection where we would report warnings
    for things that Room already fixes automatically (b/140759491).
    The solution to that problem (I7659002e5e0d1ef60fc1af2a625c0c36da0664d8)
    solved it by deferring validating of columns until after re-write
    decision is made. Unfortunately, this required changing PojoRowAdapter
    to have a dummy mapping until it is validating, make it hard to use
    as it does have a non-null mapping which is not useful.
   
    This CL partially reverts that change and instead rely on the log
    deferring logic we have in Context. This way, we don't need to break
    the stability of PojoRowAdapter while still having the ability to
    drop warnings that room fixes. This will also play nicer when we
    have different query re-writing options that can use more information
    about the query results.
   
    Bug: 153387066
    Bug: 140759491
    Test: existing tests pass
    Change-Id: I2ec967c763d33d7a3ff02c1a13c6953b460d1e5f

M       room/compiler/src/main/kotlin/androidx/room/log/RLog.kt
M       room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M       room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M       room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt

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

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.