New

Incremental annotation processing for faster builds
Support for Android Jetpack Paging v3 library in new epoxy-paging3 artifact
Model group building with Kotlin DSL (#1012)
Update to Kotlin 1.4.0
A new annotation processor argument logEpoxyTimings can be set to get a detailed breakdown of how long the processors took and where they spent their time (off by default)
Another new argument enableParallelEpoxyProcessing can be set to true to have the annotation processor process annotations and generate files in parallel (via coroutines).

You can enable these processor options in your build.gradle file like so:

project.android.buildTypes.all { buildType ->
  buildType.javaCompileOptions.annotationProcessorOptions.arguments =
      [
          logEpoxyTimings  : "true",
          enableParallelEpoxyProcessing     : "true"
      ]
}

Parallel processing can greatly speed up processing time (moreso than the incremental support), but given the hairy nature of parallel processing it is still incubating.
Please report any issues or crashes that you notice.
(We are currently using parallel mode in our large project at Airbnb with no problems.)

Add options to skip generation of functions for getters, reset, and method overloads to reduce generated code
- New annotation processor options are:
  - epoxyDisableGenerateOverloads
  - epoxyDisableGenerateGetters
  - epoxyDisableGenerateReset

Fixes

Synchronize ListUpdateCallback and PagedListModelCache functions (#987)
Avoid generating bitset checks in models when not needed (reduces code size)
Fix minor memory leak

Breaking

Annotations that previously targeted package elements now target types (classes or interfaces).
This includes: EpoxyDataBindingPattern, EpoxyDataBindingLayouts, PackageModelViewConfig, PackageEpoxyConfig
This was necessary to work around an incremental annotation processor issue where annotation on package-info elements are not properly recompiled
In order to enable incremental annotation processing a change had to be made in how the processor of
@AutoModel annotations work. If you use @AutoModel in an EpoxyController the annotated Model types
must be either declared in a different module from the EpoxyController, or in the same module in the same java package.

Also make sure you have kapt error types enabled.

However, generally @AutoModel is considered legacy and is not recommended. It is a relic of Java Epoxy usage
and instead the current best practice is to use Kotlin with the Kotlin model extension functions to build models.
Removed support for generating Epoxy models from Litho components

epoxy - 4.0.0-beta6

Published by elihart about 4 years ago

PackageModelViewConfig can now be applied to classes and interfaces in addition to package-info.java

epoxy - 4.0.0-beta5

Published by elihart over 4 years ago

Fixes:

An occasional processor crash when the option to log timings is enabled
Incremental annotation processing of databinding models would fail to generate models (https://github.com/airbnb/epoxy/issues/1014)

Breaking!

The annotation that support databinding, EpoxyDataBindingLayouts and EpoxyDataBindingPattern,
must now be placed on a class or interface instead of in a package-info.java file. The interface
or class must be in Java, Kotlin is not supported. This is necessary to support incremental processing.

Example usage:

package com.example.app;
import com.airbnb.epoxy.EpoxyDataBindingLayouts;
import com.airbnb.epoxy.EpoxyDataBindingPattern;
@EpoxyDataBindingPattern(rClass = R.class, layoutPrefix = "my_view_prefix")
@EpoxyDataBindingLayouts({R.layout.my_model_layout})
interface EpoxyDataBindingConfig {}

epoxy - 4.0.0-beta4

Published by elihart over 4 years ago

Fixes:

Synchronize ListUpdateCallback and PagedListModelCache functions (#987)
4.0.0.beta1 generating duplicate method layout(int) #988

epoxy - 4.0.0-beta3

Published by elihart over 4 years ago

Sorts functions in generated kotlin extension function files deterministically to prevent generated sources from changing. Can fix unexpected build cache misses.
Avoid generating bitset checks in models when not needed. Can decrease size of generated code and slightly improve runtime performance.
Add options to skip generation of functions for getters, reset, and method overloads to reduce generated code

New annotation processor options are:

epoxyDisableGenerateOverloads
epoxyDisableGenerateGetters
epoxyDisableGenerateReset

These can also be controlled (and overridden) on a per package level with the PackageModelViewConfig package annotation.

epoxy - 4.0.0-beta1

Published by elihart over 4 years ago

Support for incremental annotation processing as an Aggregating processor (#972)
Removed Litho support
A new annotation processor argument logEpoxyTimings can be set to get a detailed breakdown of how long the processors took and where they spent their time (off by default)
Another new argument enableParallelEpoxyProcessing can be set to true to have the annotation processor process annotations and generate files in parallel (via coroutines).

You can enable these processor options in your build.gradle file like so:

project.android.buildTypes.all { buildType ->
  buildType.javaCompileOptions.annotationProcessorOptions.arguments =
      [
          logEpoxyTimings  : "true",
          enableParallelEpoxyProcessing     : "true"
      ]
}

Parallel processing can greatly speed up processing time (up to 8x), but given the nature of parallel processing it is still incubating.
Please report any issues or crashes that you notice.
(We are currently using parallel mode in our large project at Airbnb with no problems.)

Breaking

In order to enable incremental annotation processing a change had to be made in how the processor of
@AutoModel annotations work. If you use @AutoModel in an EpoxyController the annotated Model types
must be either declared in a different module from the EpoxyController, or in the same module in the same java package.

Also make sure you have kapt error types enabled.

However, generally @AutoModel is considered legacy and is not recommended. It is a relic of Java Epoxy usage
and instead the current best practice is to use Kotlin with the Kotlin model extension functions to build models.

epoxy - 3.11.0

Published by elihart over 4 years ago

Introduce partial impression visibility states (#973)
Fix sticky header crash (#976)

epoxy - 3.10.0

Published by elihart over 4 years ago

Carousel building with Kotlin DSL (#967)
Android ViewBinding: added an example in the sample project. (#939)
Fix setter with default value lookup in kotlin 1.4 (#966)
Change "result" property name in generated model (#965)
Add support for Sticky Headers (#842)
Use measured width/height if it exists in Carousel. (#915)
Add a getter to EpoxyViewHolder.getHolder(). (#952) (#953)
Fix visibility tracking during RecyclerView animations (#962)
Fix leak in ActivityRecyclerPool ((#906)
Rename ResultCallack to ResultCallback in AsyncEpoxyDiffer (#899)
Fix incorrect license attributes in POM file (#898)

epoxy - 3.9.0

Published by elihart almost 5 years ago

Fix reading EpoxyDataBindingPattern enableDoNotHash (#837)
Make EpoxyRecyclerView.setItemSpacingPx() open (#829)
Use same version for Mockito Core and Inline (#860)
Minor documentation and variable name updates. (#870)
Move epoxy-modelfactory tests to their own module (#834)
Remove executable bit from non-executable files (#864)
Various repo clean ups and version bumps

epoxy - 3.8.0

Published by elihart about 5 years ago

Add support for Kotlin delegation via annotated interface properties #812
Fix checked change crash and improve debug errors #806
Remove extra space in Kotlin extensions #777
Update project to AGP 3.5, Kotlin 1.3.50, Gradle 5.6

epoxy - 3.7.0