Epoxy: Remove dependency on Butter Knife (R2)

Created on 12 Sep 2019  路  1Comment  路  Source: airbnb/epoxy

Butter Knife is going away in favor of new Android ViewBinding. Using Epoxy with defaultLayout in library project require R2 (from Butter Knife Gradle plugin).

A simple solution would be to deprecate / delete the defaultLayout attribute in Epoxy annotations. What do you think ? Is there something I am missing ?

edit : However, it may be challenging for the @ModelView annotation when the view is not a ViewGroup.

Most helpful comment

Well, the Butterknife library will still be usable, so I don't think there is a big reason to stop using the Butter Knife Gradle plugin just because ViewBinding is replacing its normal usage.

However, using layout resources as annotation processors is the main blocker to making Epoxy support incremental annotation processing, since the compiler hack we use to lookup the layout resource violates the requirements of incremental processing.

That alone is a good enough reason to get rid of it, so I was planning to do it anyway for that reason.

We could make a 4.0 version with this breaking change. In addition to the annotations you mentioned, EpoxyDataBindingLayouts also has layout resources as parameters.

We can work around this by using the global configurations to match layouts by pattern - PackageModelViewConfig and EpoxyDataBindingPattern.

We can also keep support in the existing annotations by having the R.class and the string name of the layout as parameters.

At airbnb we don't use layouts at all anymore, since we only use @ModelView in combination with Paris for styling (and auto layout).

>All comments

Well, the Butterknife library will still be usable, so I don't think there is a big reason to stop using the Butter Knife Gradle plugin just because ViewBinding is replacing its normal usage.

However, using layout resources as annotation processors is the main blocker to making Epoxy support incremental annotation processing, since the compiler hack we use to lookup the layout resource violates the requirements of incremental processing.

That alone is a good enough reason to get rid of it, so I was planning to do it anyway for that reason.

We could make a 4.0 version with this breaking change. In addition to the annotations you mentioned, EpoxyDataBindingLayouts also has layout resources as parameters.

We can work around this by using the global configurations to match layouts by pattern - PackageModelViewConfig and EpoxyDataBindingPattern.

We can also keep support in the existing annotations by having the R.class and the string name of the layout as parameters.

At airbnb we don't use layouts at all anymore, since we only use @ModelView in combination with Paris for styling (and auto layout).

Was this page helpful?
0 / 5 - 0 ratings