Fixed
Status Update
Comments
ky...@bytedance.com <ky...@bytedance.com> #2
So you can do this now by doing something like:
@Suppress("UNCHECKED_CAST")
class DelegateWorker: Worker() {
companion object {
const val DELEGATE_WORKER_NAME = "DELEGATE_WORKER_NAME"
const val PERIOD = "PERIOD" // in minutes.
}
override fun doWork(): Result {
val delegateName = inputData.getString(DELEGATE_WORKER_NAME) ?: return Result.FAILURE
val delegateKlass = Class.forName(delegateName) as? Class<out Worker> ?: return Result.FAILURE
val period = inputData.getLong(PERIOD, 15)
// build your worker with the constraints you want.
val request = PeriodicWorkRequest.Builder(delegateKlass, period, TimeUnit.MINUTES)
.setInputData(inputData)
.build()
WorkManager.getInstance()
.enqueue(request)
return Result.SUCCESS
}
}
class PeriodicWorker: Worker() {
override fun doWork(): Result {
// Do some periodic work
return Result.SUCCESS
}
}
// You want to delay the PeriodicWorker. You can use initial delay on the DelegateWorker, which in
// turn enqueue's PeriodicWorker.
val data = mapOf(DelegateWorker.DELEGATE_WORKER_NAME to PeriodicWorker::class.java.name ).toWorkData()
val delayedPeriodicWorkRequest = OneTimeWorkRequestBuilder<DelegateWorker>()
.setInitialDelay(10, TimeUnit.SECONDS)
.build()
WorkManager.getInstance()
.enqueue(delayedPeriodicWorkRequest)
The idea is to create a OneTimeWorkRequest with an initial delay, which in turn calls an enqueue() on the PeriodicWorkReqeust.
@Suppress("UNCHECKED_CAST")
class DelegateWorker: Worker() {
companion object {
const val DELEGATE_WORKER_NAME = "DELEGATE_WORKER_NAME"
const val PERIOD = "PERIOD" // in minutes.
}
override fun doWork(): Result {
val delegateName = inputData.getString(DELEGATE_WORKER_NAME) ?: return Result.FAILURE
val delegateKlass = Class.forName(delegateName) as? Class<out Worker> ?: return Result.FAILURE
val period = inputData.getLong(PERIOD, 15)
// build your worker with the constraints you want.
val request = PeriodicWorkRequest.Builder(delegateKlass, period, TimeUnit.MINUTES)
.setInputData(inputData)
.build()
WorkManager.getInstance()
.enqueue(request)
return Result.SUCCESS
}
}
class PeriodicWorker: Worker() {
override fun doWork(): Result {
// Do some periodic work
return Result.SUCCESS
}
}
// You want to delay the PeriodicWorker. You can use initial delay on the DelegateWorker, which in
// turn enqueue's PeriodicWorker.
val data = mapOf(DelegateWorker.DELEGATE_WORKER_NAME to PeriodicWorker::
val delayedPeriodicWorkRequest = OneTimeWorkRequestBuilder<DelegateWorker>()
.setInitialDelay(10, TimeUnit.SECONDS)
.build()
WorkManager.getInstance()
.enqueue(delayedPeriodicWorkRequest)
The idea is to create a OneTimeWorkRequest with an initial delay, which in turn calls an enqueue() on the PeriodicWorkReqeust.
rk...@google.com <rk...@google.com>
rk...@google.com <rk...@google.com> #3
This looks like a hack, instead of just adding setInitialDelay method on the periodic worker that will just run once.
rk...@google.com <rk...@google.com> #4
I have tried going the route of the OneTimeWorkRequest with an initial delay that triggers a PeriodicWorkRequest but it doesn't seem to work. It would be much nicer to be able to add a simple delay to the first occurence.
rk...@google.com <rk...@google.com>
aj...@gmail.com <aj...@gmail.com> #5
#3: This is exactly what an internal implementation would look like because the backing JobScheduler does not support initial delays on periodic work. I realize that WorkManager doing it for you is nicer, which is why this feature request is still open, but it may take us some time to get to it.
#4: Please file a separate bug if that doesn't work for you.
#4: Please file a separate bug if that doesn't work for you.
aj...@gmail.com <aj...@gmail.com> #6
#5: How could I debug the behaviour of this chain of Work?
Description
AutoLock
appears to be a custom implementation ofstd::unique_lock/lock_guard
. It does, however, a method namedisLocked()
. There is only one use of the method at the moment:I believe, that has room for improvement. Firstly, even if we checked
isLock()
in general, asisLock()
is not thread-safe, there is no guarantee (in general) that the same thread can then lock it. It is only useful when there is only one thread that locks/unlocks the givenAutoLock
object and the thread wants know whether thelock
is acquired or not by itself. I don't think that's useful. I think the method being public, it has a good chance to confuse external developers.My belief is that the
AutoLock
should be simply replaced withstd::unique_lock
and/orstd::lock_guard
, as many uses of the class do not calllock
orunlock
. And,isLocked()
should be removed. The only call site should be implemented without that.Aside from all mentioned above, I am trying to compile the code with
--enable-thread-safety-checks
, and the first code that blocked the compilation on Linux was the use ofisLocked()
.