Fixed
Status Update
No update yet.
Comments
[Deleted User] <[Deleted User]>
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);
}
yb...@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);
}
}
[Deleted User] <[Deleted User]>
#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.
yb...@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: N/A
In current version of room if I mark method in DAO with @Transaction, and if it uses any disposable e.g. Single, the generated code will throw main thread access exception at runtime.
I would expect one of two behaviours instead:
1. It would be ideal if room could somehow defer start/end transaction to match thread that is used on Disposable, but I can imagine that this can be not possible.
2. To get compile time warning or error that this may be not the correct way of using @Transaction with mix of asynchronous code.
Example of code:
Method in abstract DAO:
@Transaction
open fun upsert(obj: T): Single<Boolean> {
return insert(obj)
.map { true }
.onErrorResumeNext {
if (it is SQLiteConstraintException)
{ update(obj)
.map { true }
} else {
Single.error(it) }
}
.subscribeOn(Schedulers.io()) }
Generated method:
@Override
public Single<Boolean> upsert(Supplier obj) {
__db.beginTransaction();
try {
Single<Boolean> _result = super.upsert(obj);
__db.setTransactionSuccessful();
return _result;
} finally {
__db.endTransaction();
}
}