Make use of reified type parameters for View DSL to allow factories installation

[LouisCAD]

Here's some inspiration: https://helw.net/2018/08/06/appcompat-view-inflation/

Here's how it could look: v<TextView>(…) { … }, and it'd check the type and delegate instantiation to installed factories. There could also be a way to scope View types delegates (not the same as Kotlin property delegates).

[LouisCAD]

The textView(ctx: Context) and similar methods currently in the viewdsl-appcompat-styles split could be deprecated, before their name is reused to be an alias of v<TextView>, that would be agnostic to whether AppCompat and/or Google Material Design library are used.

[LouisCAD]

Part of the prototype:

import android.content.Context
import android.support.annotation.IdRes
import android.support.annotation.StyleRes
import android.view.View
import splitties.viewdsl.core.NO_THEME
import splitties.viewdsl.core.Ui
import splitties.viewdsl.core.wrapCtxIfNeeded

inline fun <reified V : View> Context.v2(
        @IdRes id: Int = View.NO_ID,
        @StyleRes theme: Int = NO_THEME,
        initView: V.() -> Unit = {}
): V = V::class.java.getConstructor(Context::class.java).newInstance(wrapCtxIfNeeded(theme)).also {
    it.id = id
}.apply(initView)

inline fun <reified V : View> View.v2(
        @IdRes id: Int = View.NO_ID,
        @StyleRes theme: Int = NO_THEME,
        initView: V.() -> Unit = {}
) = context.v2(id, theme, initView)

inline fun <reified V : View> Ui.v2(
        @IdRes id: Int = android.view.View.NO_ID,
        @StyleRes theme: Int = NO_THEME,
        initView: V.() -> Unit = {}
) = ctx.v2(id, theme, initView)

[LouisCAD]

Maybe add a second optional parameter for style. This could be used for different button styles, maybe also for text appearances and more. There would be a need to define a behavior when the style is not recognized BTW. Also, how to avoid errors where a style is applied to the wrong type while allowing extensibility? Maybe it could also be used with interface types?

How would it work with interface types?
What could it be with interfaces instead?
And with inline classes?
And what about multiplatform support? Could abstracting Views and ViewGroups away allow sharing more code?

[LouisCAD]

The view factories could be put in the Context as a system service so it can then be accessed from any View Context with proper scope.

In fact, that's how the LayoutInflater is retrieved.

[LouisCAD]

Any help on the API design is welcome

Discussion is open

[LouisCAD]

We can avoid reflection (that is normally used in layout inflater) by having the factories use the real constructors directly instead.

[LouisCAD]

Released in 2.0.0-alpha6 (and also alpha5)