Skip to content

Conversation

@Petrakeas
Copy link
Contributor

No description provided.

A  WebViewactivity that displays a selector has been added.
It can be launched by pressing the button of the first
activity.

This activity can help up reproduce and solve the crash that
occurs when TxNative functionality is enabled and the user
presses the selector of the WebView.
When a new WebView is created, Android automatically updates the Asset Manager
contained in the Resources returned by the current Context:
`Context -> Resources -> Assets`. Resources will point to a new AssetManager
object.

When TxNative is enabled, our wrapped resources still point to the previous
assets object. This can cause a crash as the old assets don't contain
resource IDs needed by a WebView when displaying a select box.

This issue has been already documented at Google's issue tracker and they don't
plan on changing this behavior:
https://issuetracker.google.com/issues/77246450

The way this fix works is that every time `TxContextWarpper#getResources()`
is called, we check if the base resources point to a different AssetManager object
to the AssetManager our `TxResources` point to. If the check succeeds, we create
new TxResources that point to the new AssetManager.
For the fix to work, we need to make sure that our `getResources()` method is
called every time resources are needed.
Unfortunately, the activity caches the resources instead of calling this method
every time. This is why some code had to be placed in our `TxBaseAppCompatActivity` or
`TxBaseActivity`, so that the activity's getResources() method tries to get the
resources from the wrapped context, instead of calling `super.getResources()`,
which will return the cached resources.

TxResources#getWrappedResources() has been renamed to
TxResources#getBaseResources(), to make its use case more clear and avoid
confusion. "Wrapped" resources usually refer to the final wrapped object and
not the object that is being wrapped (as was the case here).

TxResources used to contain methods taken from the ResourcesWrapper of
appcompat: https://androidx.tech/artifacts/appcompat/appcompat-resources/1.6.1-source/androidx/appcompat/widget/ResourcesWrapper.java.html

The following methods were added now as the seem as something that
should be handled by the base resource object:

* public Typeface getFont(int id)
* public int getColor(int id, Theme theme)
* public ColorStateList getColorStateList(int id, Theme theme)
* public float getFloat(int id)

In TxContextWrappingDelegateJava, the following methods that were already
override in the Kotlin version of the file, TxContextWrappingDelegate, were
added:

* public void setTheme(int themeResId)
* public int getLocalNightMode()
This asset was added so that vector support when using
"new TxContextWrappingDelegateJava(super.getDelegate());"
can be tested when deploying on Android 18 and 19.

https://medium.com/androiddevelopers/appcompat-v23-2-age-of-the-vectors-91cbafa87c88
@n1k0sv n1k0sv merged commit d296e4e into transifex:devel Oct 2, 2023
@txsentinel txsentinel mentioned this pull request Oct 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants