Fixed
Status Update
No update yet.
Comments
yb...@google.com
ya...@google.com
ya...@google.com
Can you give us the sample app or code that's exhibiting this problem?
gm...@gmail.com
ya...@google.com
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.
gm...@gmail.com
No, when `useInitialDelayForPeriodic` is set to `true`, I'm not using a flexInterval... check the code.
ya...@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 ?
ap...@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.
Description
Version used: 2.0.0
Devices/Android versions reproduced on: Wileyfox Swift (API 25)
Not reproduced on Android Emulator API 15 (probably due to different SQLite version).
SQLite constraint violation on method annotated with @Insert(onConflict = OnConflictStrategy.ROLLBACK) causes SQLiteException instead of SQLiteConstraintException.
Stack trace example:
E/AndroidRuntime: FATAL EXCEPTION: Thread-8
Process: gmk57.roomtest, PID: 2152
android.database.sqlite.SQLiteException: cannot rollback - no transaction is active (code 1)
at android.database.sqlite.SQLiteConnection.nativeExecute(Native Method)
at android.database.sqlite.SQLiteConnection.execute(SQLiteConnection.java:555)
at android.database.sqlite.SQLiteSession.endTransactionUnchecked(SQLiteSession.java:439)
at android.database.sqlite.SQLiteSession.endTransaction(SQLiteSession.java:401)
at android.database.sqlite.SQLiteDatabase.endTransaction(SQLiteDatabase.java:524)
at androidx.sqlite.db.framework.FrameworkSQLiteDatabase.endTransaction(FrameworkSQLiteDatabase.java:90)
at androidx.room.RoomDatabase.endTransaction(RoomDatabase.java:266)
at gmk57.roomtest.DataDao_Impl.insertRollback(DataDao_Impl.java:99)
at gmk57.roomtest.MainActivity.violateRollback(MainActivity.java:67)
Taking into account that
1) Room wraps methods annotated with @Insert, @Update and @Transaction in explicit transaction, and
2) ABORT, FAIL and ROLLBACK all throw SQLiteConstraintException, effectively rolling back this transaction
- the broader question is: is there any reason to provide FAIL and ROLLBACK options at all?
I also think the documentation should clearly describe the behavior of each strategy in specific case of Android + Room (e.g. which strategies throw an exception and which do not), instead of just linking to partly irrelevant SQLite documentation.
Sample project attached.