Remove DelegatingTypeAdapter and NestedChildElementBinder

[sockeqwe]

DelegatingTypeAdapter has already replaced with a purely generated (annotation processing) TypeAdapter. There are some Unit tests using DelegatingTypeAdapter, but really just for convenience reasoning (and / or to test DelegatingTypeAdapter himself).

From the newly implemented TypeAdapter code generator (introduced in version 0.6.0-SNAPSHOT) almost everything can be reused to generated highly optimized ChildElementBinders so that NestedChildElementBinder is not needed anymore

[iNoles]

I have a question for

TypeSpec.anonymousClassBuilder("false")
                .addSuperinterface(nestedChildElementBinderType)
                .addInitializerBlock(initializerBuilder.build())
                .build()

in CodeGeneratorHelper.kt

Should I remove this

addSuperinterface(nestedChildElementBinderType)

line or replace with another variables

[sockeqwe]

I have no clue 😄 I have to look at the code in more detail, but basically DelegatingTypeAdapter and NestedChildElementBinder should not be used anymore by the generated code and therefore these classes could be removed.

[iNoles]

here is code in question

fun generateNestedChildElementBinder(element: XmlElement): TypeSpec {

        val initializerBuilder = CodeBlock.builder()
        if (element.hasAttributes()) {
            val attributeMapType = ParameterizedTypeName.get(ClassName.get(HashMap::class.java), ClassName.get(String::class.java), attributeBinderType)
            initializerBuilder.addStatement("$attributeBindersParam = new \$T()", attributeMapType);
            initializerBuilder.add(generateAttributeBinders(element))
        }

        if (element.hasChildElements()) {
            val childBinderTypeMap = ParameterizedTypeName.get(ClassName.get(HashMap::class.java), ClassName.get(String::class.java), childElementBinderType)
            initializerBuilder.addStatement("$childElementBindersParam = new \$T()", childBinderTypeMap);
            for ((xmlName, xmlElement) in element.childElements) {
                initializerBuilder.addStatement("${CodeGeneratorHelper.childElementBindersParam}.put(\$S, \$L)", xmlName, xmlElement.generateReadXmlCode(this))
            }
        }


        // TODO text content?
        return TypeSpec.anonymousClassBuilder("false")
                .addSuperinterface(nestedChildElementBinderType)
                .addInitializerBlock(initializerBuilder.build())
                .build()
    }

[sockeqwe]

Sorry, I haven't had time to look into this. Not sure if I have time the next 2 weeks.

[lukechi1219]

Hi @sockeqwe ,

I'm using 'com.tickaroo.tikxml:core:0.8.13' & 'com.tickaroo.tikxml:auto-value-tikxml:0.8.13'

and I got auto generated class GetCMSXmlTikXmlValueHolder$$TypeAdapter which has NestedChildElementBinder.

if NestedChildElementBinder is deprecated, does that mean I should not use @'Path' annotation?

public class GetCMSXmlTikXmlValueHolder$$TypeAdapter implements TypeAdapter<GetCMSXmlTikXmlValueHolder> {

....childElementBinders.put("cms:CmsDataSet", new NestedChildElementBinder<GetCMSXmlTikXmlValueHolder>(false) {
....}
}

-- xml pojo --

@Xml(name = "cms:ExchangeData")
@AutoValue
public abstract class GetCMSXml implements Parcelable {

    @Path("cms:CmsDataSet")
    @Element(name = "cms:CmsData")
    public abstract List<CmsData> cmsDataList();
}

[sockeqwe]

Hi, nothing from the public API like @Path has been deprecated.

This GitHub issue is only about internal code generation and that there could be some optimizations done. I.e. NestedChildElementBinder is generated at compile time, but the generated code could be optimized further ...