IssueTracker

Jake: it says the issue is this is a compile error:

Compile time error:
com.xxxx.databinding:ActivityXXXXBinding.java:34:
error: incompatible types: ToolbarTransparentLayoutBinding cannot be converted to ViewDataBinding
    setContainedBinding(this.toolbar);

Why did you move to "android studio > data binding > editing"? Are we suggesting bad autocompletions?

OP: Can you clarify exactly what the problem is? It's not clear to me from a glance. Can you simplify what's happening and what you expect?

I just moved it to data binding from view binding under the same component hierarchy since it was related to data binding code gen, not view binding.

Ah, got it. I'll move it to the AndroidX component. Yigit, please bounce back if this is an IDE issue.

👍 didn't realize we had jetpack ones

Yes, sorry -- it might have gotten lost in comment #3

OP: Can you clarify exactly what the problem is? It's not clear to me from a glance. Can you simplify what's happening and what you expect?

Can you provide a sample app that reproduces the issue ? I'm not sure what in the layout is triggering this.

I encountered the same issue.

1. I have both data binding and view binding enabled.
2. I have Fragment layout with <layout> tag and data binding set up
3. There is a separate toolbar layout without <layout> tag which is included into Fragment layout. (this might be the issue)

My workaround is tools:viewBindingIgnore="true" for toolbar layout.

Layouts:

Fragment:

<?xml version="1.0" encoding="utf-8"?>
<layout xmlns:android="http://schemas.android.com/apk/res/android"
      xmlns:app="http://schemas.android.com/apk/res-auto">

      <data>

        <variable
            name="viewModel"
            type="***" />
    </data>

    <LinearLayout
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:background="@color/white"
        android:orientation="vertical">

        <include
            android:id="@+id/toolbarLayout"
            layout="@layout/l_toolbar" />

         <***>

    </LinearLayout>

</layout>

Toolbar:

<?xml version="1.0" encoding="utf-8"?>
<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:id="@+id/toolbarLayout"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:background="@color/rgb_26"
    android:orientation="vertical">

    <androidx.appcompat.widget.Toolbar
        android:id="@+id/toolbar"
        android:layout_width="match_parent"
        android:layout_height="@dimen/toolbar_height"
        android:theme="@style/Toolbar"
        app:titleTextAppearance="@style/ToolbarTitleTextStyle" />
</FrameLayout>

I have created sample app. Rebuild fails every time.

ok so here data binding is confusing the ViewBinding generated class or a DataBinding one so tries to set a field that does not exist. seems straightforward, i'll work on a test.

ok this turned to be a lot more complicated than i hoped :(

it is easy to fix the broken code that gets generated but it does not solve the actual problem.

When a data bidning layout includes another binding (view or data), we need to find the binding class generated for it.

For data binding layouts, it relies on DataBindingUtil to get that class :

https://android.googlesource.com/platform/frameworks/data-binding/+/studio-master-dev/extensions/library/src/main/java/androidx/databinding/ViewDataBinding.java#716

https://android.googlesource.com/platform/frameworks/data-binding/+/studio-master-dev/extensions/library/src/main/java/androidx/databinding/ViewDataBinding.java#1209

https://android.googlesource.com/platform/frameworks/data-binding/+/studio-master-dev/extensions/library/src/main/java/androidx/databinding/ViewDataBinding.java#1260

Since there is no central location to inflate a view binding (similar to DataBindingUtil), there is no easy way to fix this. (nor that i would recommend adding it as it adds significant build complexity).

We need to significantly change how data binding inflates layouts or binds to existing layouts to fix this. We probably also need to ditch the optimization that traverses the layout once (which i wouldn't care much).

Either way, this will be a major change that might also break people if they inadvertently relied on how inflation works in data binding.

My recommendation for now, unfortunately, is to either use ignore or use data binding in that included layout as well.

Jake, any recommendations here that i'm missing ?

A possible workaround might be to make generated binding classes treat view binding includes separately such that it can use findViewById to find them and bind instead of using the 1 pass thing. That would keep it consistent for existing use cases at the cost of complicating our own logic (which i'm fine with).

i prototyped a solution where the generated Impl considers the view binding layout like a regular view with id for the purposes of construction and call GeneratedViewBinding#bind after finding views.

It is gross, confusing and some more technical debt but it is probably the best approach to fix this w/o a major change in data binding.

i'll try to cleanup, add more tests and send a CL