Fixed
Status Update
Comments
il...@google.com <il...@google.com>
jb...@google.com <jb...@google.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.
jb...@google.com <jb...@google.com> #3
This looks like a hack, instead of just adding setInitialDelay method on the periodic worker that will just run once.
ap...@google.com <ap...@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.
il...@google.com <il...@google.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.
Description
When using the new state manager released in fragment 1.3.0-alpha08, if you manually (without using the hide/show fragment transactions) set the visibility state of your view after the SpecialEffectsController has started any animations/transitions on your view, the visibility changes are ignored.
The reason this happens is because the new state manager saves the visibility state of the view in
onViewCreated()
as the final state and then restores that visibility state once the special effect completes afteronStart()
. This means that any changes made by the user to the view visibility state betweenonViewCreate()
andonStart()
are completely ignored.This becomes apparent in two particular cases:
There is a fragment that is always added, but has its visibility state updated based on some internal data (i.e. an error screen that is set to
View.INVISIBLE
when there is no error andView.VISIBLE
when there is one). If the view state changes toINVISIBLE
inonStart()
, the fragment should not be shown once the add transaction completes.A entering fragment is postponed and while it is postponed, its view visibility state is set to
View.INVISIBLE
. Even once the fragment is no longer postponed, its view should still beINVISIBLE
until the user changes it again manually.The new state manager should defer view visibility state control to the user no matter when the state is changed. Doing so would ensure that the user always has the source of truth for their Fragment's view visibility.