Fixed
Status Update
No update yet.
Comments
yb...@google.com
ya...@google.com
ya...@google.com
[Comment deleted]
gm...@gmail.com
We're still trying to work out if we can work around this in the library.
In the mean-time, if you know that you are going to create a WebView in an Activity, you can do the following:
protected void onCreate(Bundle savedInstanceState) {
if (Build.VERSION.SDK_INT >= 24) {
new WebView(this);
}
super.onCreate(savedInstanceState);
}
In the mean-time, if you know that you are going to create a WebView in an Activity, you can do the following:
protected void onCreate(Bundle savedInstanceState) {
if (Build.VERSION.SDK_INT >= 24) {
new WebView(this);
}
super.onCreate(savedInstanceState);
}
ya...@google.com
alternatively you were able to get it to work by capturing the configuration prior to inflating a webview and restoring it after
Configuration oldConfig = getCurrentConfig();
//**inflate webview here**
restoreConfig(oldConfig);
Configuration getCurrentConfig() {
return new Configuration(activity.getResources().getConfiguration());
}
void restoreConfig(@Nullable Configuration configuration) {
//if the config isn't null, a webview was inflated and we should update the configuration to
//the previous one to prevent nightmode from being reset by webview inflation
if (configuration != null) {
activity.getResources().updateConfiguration(configuration, null);
}
}
Configuration oldConfig = getCurrentConfig();
//**inflate webview here**
restoreConfig(oldConfig);
Configuration getCurrentConfig() {
return new Configuration(activity.getResources().getConfiguration());
}
void restoreConfig(@Nullable Configuration configuration) {
//if the config isn't null, a webview was inflated and we should update the configuration to
//the previous one to prevent nightmode from being reset by webview inflation
if (configuration != null) {
activity.getResources().updateConfiguration(configuration, null);
}
}
gm...@gmail.com
#3: That can work, but you don't want to do that on EVERY WebView inflate, only the first. My workaround is #2 is a one-time call.
ya...@google.com
We have webviews in recycler view. Until we wrapped every call we would get zebra stripping on recycling. Thanks for looking into issue overall!
ap...@google.com
Any updates or more details on this Issue?
We were stuck for a few days trying to implement DayNight via AppCompat within our app. On API 24+ our Main activity, which hosts a ViewPager, was not being properly themed. We had inconsistent behavior on the inner fragments within the view pager hosting recycler views where they were either not themed for night mode or some items where partially getting themed. It was not until I found this issue that I was able to connect the dots as our ViewPage hosts a WebView within one of the fragments.
After adding the work around for the onCreate, we are now able to take advantage of this Support Lib feature but would like to know more about what is going on and what should we watch out moving forward. Specially as we have some devices already running Android O beta and the night theme for reasons unknown yet was not applied to some textviews.
further details are much appreciated.
We were stuck for a few days trying to implement DayNight via AppCompat within our app. On API 24+ our Main activity, which hosts a ViewPager, was not being properly themed. We had inconsistent behavior on the inner fragments within the view pager hosting recycler views where they were either not themed for night mode or some items where partially getting themed. It was not until I found this issue that I was able to connect the dots as our ViewPage hosts a WebView within one of the fragments.
After adding the work around for the onCreate, we are now able to take advantage of this Support Lib feature but would like to know more about what is going on and what should we watch out moving forward. Specially as we have some devices already running Android O beta and the night theme for reasons unknown yet was not applied to some textviews.
further details are much appreciated.
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.