Crash with Resources$NotFoundException

[Suvorov-Alex]

Fatal Exception: android.content.res.Resources$NotFoundException
Resource ID #0x0
android.content.res.ResourcesImpl.getValue (ResourcesImpl.java:237)
android.content.res.Resources.loadXmlResourceParser (Resources.java:2293)
android.content.res.Resources.getLayout (Resources.java:1187)
android.view.LayoutInflater.inflate (LayoutInflater.java:532)
io.github.inflationx.viewpump.internal.-ViewPumpLayoutInflater.inflate (-ViewPumpLayoutInflater.java:48)
android.widget.ArrayAdapter.createViewFromResource (ArrayAdapter.java:428)
android.widget.ArrayAdapter.getView (ArrayAdapter.java:419)
OT.getView (OT.java:2)
android.widget.AbsListView.obtainView (AbsListView.java:2472)
android.widget.ListView.measureHeightOfChildren (ListView.java:1421)
android.widget.ListView.onMeasure (ListView.java:1327)
android.view.View.measure (View.java:24777)
android.view.ViewGroup.measureChildWithMargins (ViewGroup.java:6858)
android.widget.FrameLayout.onMeasure (FrameLayout.java:194)
android.view.View.measure (View.java:24777)
android.view.ViewGroup.measureChildWithMargins (ViewGroup.java:6858)
android.widget.FrameLayout.onMeasure (FrameLayout.java:194)
android.view.View.measure (View.java:24777)
com.android.internal.widget.AlertDialogLayout.tryOnMeasure (AlertDialogLayout.java:146)
com.android.internal.widget.AlertDialogLayout.onMeasure (AlertDialogLayout.java:71)
android.view.View.measure (View.java:24777)
android.view.ViewGroup.measureChildWithMargins (ViewGroup.java:6858)
android.widget.FrameLayout.onMeasure (FrameLayout.java:194)
android.view.View.measure (View.java:24777)
android.view.ViewGroup.measureChildWithMargins (ViewGroup.java:6858)
android.widget.FrameLayout.onMeasure (FrameLayout.java:194)
android.view.View.measure (View.java:24777)
android.view.ViewGroup.measureChildWithMargins (ViewGroup.java:6858)
android.widget.FrameLayout.onMeasure (FrameLayout.java:194)
com.android.internal.policy.DecorView.onMeasure (DecorView.java:749)
android.view.View.measure (View.java:24777)
android.view.ViewRootImpl.performMeasure (ViewRootImpl.java:3282)
android.view.ViewRootImpl.measureHierarchy (ViewRootImpl.java:2025)
android.view.ViewRootImpl.performTraversals (ViewRootImpl.java:2354)
android.view.ViewRootImpl.doTraversal (ViewRootImpl.java:1940)
android.view.ViewRootImpl$TraversalRunnable.run (ViewRootImpl.java:8073)
android.view.Choreographer$CallbackRecord.run (Choreographer.java:1227)
android.view.Choreographer.doCallbacks (Choreographer.java:1029)
android.view.Choreographer.doFrame (Choreographer.java:942)
android.view.Choreographer$FrameHandler.handleMessage (Choreographer.java:1151)
android.os.Handler.dispatchMessage (Handler.java:107)
android.os.Looper.loop (Looper.java:214)
android.app.ActivityThread.main (ActivityThread.java:7707)
java.lang.reflect.Method.invoke (Method.java)
com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:516)
com.android.internal.os.ZygoteInit.main (ZygoteInit.java:950)

The most crashes on Samsung, Huawei, Xiaomi, 100% crashes on Android 8 or higher

[B3nedikt]

@Suvorov-Alex Fixed on my version of the lib: https://github.com/B3nedikt/ViewPump

In short you can't use ContextWrappers which overwrite getResources() anymore when you overwrite attachBaseContext(...) like in this original version of ViewPump.

[Fredcopper]

@B3nedikt Can you explain to me why you cannot use the ContextWrappers any longer? Or have a link explaining? I can't seem to find anything about it.

[B3nedikt]

@Fredcopper Of course you can still use ContextWrappers, but as I have written above not in the way used in this version of ViewpPump. I can´t think of any link that explains the issue well in full, but a second of googling brings up this stackoverflow post which explains it at least in part. For details I can only recommend looking into googles git yourself, code is the best documentation ;)

[Fredcopper]

@B3nedikt thank you, that stack overflow post is sufficient.

[ashu5398]

Hi @B3nedikt I didn't find any such context wrapper in code. Can you please specify the file name?

[B3nedikt]

This repository uses one here.
It does not overwrite getResources() though, so only if you use a library in combination with ViewPump which does this, you will get the crash in this issue. Just using my version of the lib or using app compat <1.2.0 will fix it though.

[dahaidadavid]

I have this crash in my app too, than i new a webview object in application ,this crash fixed for me.

[dahaidadavid]

I have this crash in my app too, than i new a webview object in application ,this crash fixed for me.

when i use viewpump to dynamic load string res,i found when i wrap a context in attachBaseContext,when the page hava webview,long press and use select tag may case crash, this becasue webview will load resource on webview first init,to fix this problem,to fix this problem have two ways:1:init webview before use it. 2:load webview resource by ourself.

[ZacSweers]

PRs are welcome, disappointed to see a fork that never attempted to contribute improvements back

[B3nedikt]

@ZacSweers To be clear I did create a PR which tried to contribute improvements back: #60

However this PR did not receive any comment after a whole week, the repository had tons of open issues without any maintainer answering, and even the github release version was not up to date with what is on maven central.

So obviously I assumed this original version of this lib is no longer actively maintained, and I created my own version which follows a very different approach. It builds on the appCompat library to intercept view inflation, and only relies on a custom view inflater when absolutely necessary. I found this approach to be much more stable.

I understand your disappointment, but it was certainly not my intent to in any way keep my improvements only to myself. You can also just merge them back in if you want, however understand that they follow a very different approach, and have a slightly different interface. It really depends on the future direction you have intended for your version of this library.

[ZacSweers]

I assume you meant to link this: #57

Didn't see that before, so I apologize for suggesting no effort had been made as I admittedly only checked open PRs.

You're right that this library hasn't seen much development as the API is stable and doesn't need much work, but expecting a one week turnaround on a volunteer project in 2020 of all years seems... misguided.

I took a look at the PR. 90% of it is unrelated build and refactoring noise, but the rest seems more or less hardcoded for your use case. We may solve it that way, but probably not quite like that.

[B3nedikt]

Yes, I meant this PR :) I obviously don't expect a one week turnaround of a volunteer project, more like the combination of factors made me think it is likely not worth to try to reach out to contribute. But anyway, I think this is more of a general discussion.

I think @dahaidadavid summarizes the issue well, the problem is that a web view needs to load resources dynamically after inflation. Thanks to the way appCompat works since version 1.2, dynamically loading resources will fail when trying to provide a custom Resources instance through a custom LayoutInflater like this version of ViewPump does. This is due to the fact that the inflated WebView will have the wrong context. We need the context after is has been processed by attachBaseContext2, not the one before it has been processed.

I think there are three ways around this:

• Just inflate all web views with a context wrapped using attachBaseContext() manually. Downside is that this requires users of this library to have some insights into how appCompat works behind the the scene to understand why this is necessary. However you don't need to change anything with this library.

• Just overwrite the context of WebViews after they have been already initialized with the correct one, the changes to enable this are done in my PR linked above. Works, but is somewhat hardcoded...

• Use appCompat directly in ViewPump to provide a custom appDelegate which just uses the correct context by default. This is done in my version of ViewPump. However as this is a very different approach to your version of ViewPump which has some implications on its own this may not be what you want.

I think this issue can be solved with anything from adding a bit more documentation to the Readme to changing the entire behavior of the library xD

[drakeet]

I have used both the InflationX and @B3nedikt versions for a long time, especially B3nedikt's version. When I encountered various issues with the InflationX version, it was B3nedikt's version that saved me. It is very stable and reliable, and the source code looks simpler, which I think is a better implementation. Anyway, I very thank InflationX for proposing such a programming method and API, and also very thank @B3nedikt for providing a perhaps better solution in a timely manner. You are both our heroes.