Fixed
Status Update
No update yet.
Comments
jb...@google.com
cs...@supercharge.io
Can you give us the sample app or code that's exhibiting this problem?
jb...@google.com
cs...@supercharge.io
Your examples have an initial delay + a flex time.
So the first instance will be closer to ~30 mins, because you want the periodic work to only be eligible at the end of initial delay + beginning of the flex window.
So the first instance will be closer to ~30 mins, because you want the periodic work to only be eligible at the end of initial delay + beginning of the flex window.
ap...@google.com
No, when `useInitialDelayForPeriodic` is set to `true`, I'm not using a flexInterval... check the code.
cl...@google.com
Sorry, i might have misread that part of the source code.
> BUT I'm not finding that. Let's say that "interval" of the periodic work is 15 mins, and I set an "initial delay" also of 15 mins, and I set this going when the user hits the button. I find that the immediate work is performed at 0 mins (triggered explicitly, not by WorkManager, so that's as expected), then at 15 mins NOTHING happens, and only at 30 mins does the first periodic work actually run.
What do you mean when you say - triggered work explicitly ? [ "I find that the immediate work is performed at 0 mins (triggered explicitly, not by WorkManager, so that's as expected)" ]
Which part of the source code are you referring to ?
> BUT I'm not finding that. Let's say that "interval" of the periodic work is 15 mins, and I set an "initial delay" also of 15 mins, and I set this going when the user hits the button. I find that the immediate work is performed at 0 mins (triggered explicitly, not by WorkManager, so that's as expected), then at 15 mins NOTHING happens, and only at 30 mins does the first periodic work actually run.
What do you mean when you say - triggered work explicitly ? [ "I find that the immediate work is performed at 0 mins (triggered explicitly, not by WorkManager, so that's as expected)" ]
Which part of the source code are you referring to ?
pr...@google.com
MyWorker.java:
static void schedulePeriodicWork(Context context, int appWidgetId, String trigger) {
Log.d(TAG, "schedulePeriodicWork for " + appWidgetId);
// do an immediate update, with periodic work kicking in later (subject to Doze etc)
doSomeWork(context, appWidgetId);
^^^^^^
this bit is where I call doSomeWork() directly, when scheduling the periodic work, to get a guaranteed immediate execution of the first work.
static void schedulePeriodicWork(Context context, int appWidgetId, String trigger) {
Log.d(TAG, "schedulePeriodicWork for " + appWidgetId);
// do an immediate update, with periodic work kicking in later (subject to Doze etc)
doSomeWork(context, appWidgetId);
^^^^^^
this bit is where I call doSomeWork() directly, when scheduling the periodic work, to get a guaranteed immediate execution of the first work.
cs...@supercharge.io
Yeah.. I realized that's the part of the code that you were talking about. Your source code also had OneTimeWorkRequest's being created (but was not being called by anyone) - so was confused.
il...@google.com
Yeah sorry the OneTimeWorkRequest stuff was there as one way of getting the immediate work done, and mostly it's OK, but certainly for some devices in particular the device delays quite some time before running the work, so it's not immediate enough.
ko...@gmail.com
We introduce some drift due to the way we reschedule ENQUEUED work on init (on process death).
I will fix this.
I will fix this.
Description
Version used: 2.8.3
@Serializable
class MyRoute(
val platforms: List<Platform>
)
enum class Platform {
ANDROID, IOS
}
composable<MyRoute> { MyScreen() }
This will result in an exception:
java.lang.IllegalArgumentException: Route MyRoute could not find any NavType for argument platforms of type kotlin.collections.ArrayList - typeMap received was {}
Please support list of enums by default.