As I've promised - here is my experience with two cool libs: Splitties DSL and Conductor. They combine pretty good with each other, and deliver strong feeling that this approach should be standard for Android development. Here are main benefits: 1. Single activity, no fragments, zero lifecycle management. 2. Cool direct navigation between Controllers without activity listeners and all that stuff. 3. Cool and fast UI generation without xml. 4. Very simple implementation of MVP - imo best approach in case of generated UI. Here is some sample code I've extracted and refactored for simplicity (one piece of code is better than thousand words :))

class ItemsUi(override val ctx: Context,
              private val displayHelper: DisplayHelper) // Any other stuff for abstraction from platform...
    : Ui {

    /**
     * Holder for buttons.
     */
    val content = verticalLayout {
    }

    /**
     * Root of Ui. Should be below all other properties for correct initialization order.
     */
    override val root = verticalLayout {
        background = resources.getDrawable(android.R.color.white, null)

        add(content, lParams {
            width = matchParent
            height = matchParent
        })
    }

    /**
     * Creates UI based on data.
     */
    fun createUi(items: List<Item>?) {
        content.apply {
            for (item in items) {
                add(createButton(item), lParams {
                    width = matchParent
                    height = matchParent
                })
            }
        }
    }
}

class ItemsPresenter(ownerScope: CoroutineScope,
                     private var view: View?,
                     private val loadItemsCommand: LoadItemsCommand) : CoroutineScope by ownerScope {
    interface View {
        fun showItems(items: List<Item>?)
    }

    fun loadItems() = launch(<http://Dispatchers.IO|Dispatchers.IO>) {
        val items = loadItemsCommand(null)

        withContext(Dispatchers.Main) {
            view?.showItems(items)
        }
    }

    fun stop() {
        view = null
    }
}

class ItemsController : Controller(),
        CoroutineScope,
        KoinComponent,
        ItemsPresenter.View {

    private val itemsPresenter: ItemsPresenter by inject { parametersOf(this, this) }
    private lateinit var itemsUi: ItemsUi

    override fun onCreateView(inflater: LayoutInflater, container: ViewGroup): View {
        itemsPresenter.loadItems()

        val displayHelper: DisplayHelper by inject()
        itemsUi = ItemsUi(container.context, displayHelper, ::onItemSelection)
        // or, alternatively, you can do something like that:
        // itemsUi.button.onClick {
        //            val pushHandler = FadeChangeHandler(false)
        //            val popHandler = FadeChangeHandler()
        //
        //            router.pushController(RouterTransaction.with(ItemDetailsController())
        //                    .pushChangeHandler(pushHandler)
        //                    .popChangeHandler(popHandler))
        //        }
        return itemsUi.root
    }

    override fun onDestroyView(view: View) {
        super.onDestroyView(view)
        itemsPresenter.stop()
    }

    override fun showItems(items: List<Item>?) {
        itemsUi.createUi(items)
    }

    private fun onItemSelection(itemId: Int) {
        val pushHandler = FadeChangeHandler(false)
        val popHandler = FadeChangeHandler()

        router.pushController(RouterTransaction.with(ItemDetailsController())
                .pushChangeHandler(pushHandler)
                .popChangeHandler(popHandler))
    }

    override val coroutineContext: CoroutineContext by lazy {
        (activity as MainActivity).coroutineContext
    }

}

@ispbox I use xml defined ids. The IDE even has an intention to create them from code

R.id.not_existing_yet

.

Thank you very much! Looks very promising. Probably it's better than reinvent the wheel. For styling, ids and maybe some other things xmls are still valid 🙂

Well, having the wheel reinvented will probably prove better in the future with #compose 😅

https://kotlinlang.slack.com/archives/CJLTWPH7S/p1565104213110100?thread_ts=1565101902.109300&cid=CJLTWPH7S I like this comment 🙂

Compose is more akin to coroutines but for trees instead of long running/waiting code. I thought the same as you at first, but going beyond that, it seems promising, and I can't wait to try it with coroutines!

@louiscad, do you mean that compose will generate UI in background? Is that possible? But actually I don't see this as a main problem for android development 🙂 As for your second question, I'm really excited with Conductor, and wish I had known it earlier. It is written in Java, but that is not a problem at all. It is so pretty simple and really awesome in functionality! I see no reason to use any available extensions (not in Kotlin as well ;), it works pretty good with MVP pattern without any Mosby or other stuff.

I mean a

@Composable

function requires to be called from another one, much like

suspend

functions. Regarding building part or all of the UI on a background thread, they are considering it and have to test if that has good outcomes in practice.

I treat all that extra annotations as Java-world old-fashioned trash 🙂 Actually using Kotlin there are not so many use-cases for annotations. That's why I prefer Koin over Dagger, or Spek over JUnit, for example. I'm more or less OK with annotations in Firebase Performance (it is really convenient), but elegancy of composing UI in Splitties or Anko is better for me 🙂

Compose is looking for just letting us have conditions (`if`/`else`, `when`…). Don't get fooled by it's annotation processor look, the

suspend

keyword is actually an annotation for the compiler, just like

@Compose

is. They thought about making it a keyword (

compose fun

), but they're not certain it's the right thing to add a keyword. An annotation is more library space and doesn't conflict with others in the project unless there's a fundamental clash.

Compose is looking for just letting us have conditions

And what's the problem now? 🙂 Kotlin already has this 'magic' 🙂

Compose is in Kotlin, that's why it'll work in Compose with nothing added from them. It's like suspending functions, all language features work with them.

Compose is in Kotlin, that's why it'll work in Compose with nothing added from them.

And the same applies to Splitties. Why are you so pessimistic? You already have a library, and Google has to work for maybe 1 or 2 years to get that in production.

I'm not pessimistic, I'm enthusiastic! Splitties is not going away, it's close to the best we can get with

android.view.View

IMO. However, despite that, there's a need for a lot of fine tuning, and many things are very complicated. The current state makes me want to be a backend mobile developer only (not deal with how the app will actually look). Compose promises to make this dramatically easier, so I can only hope for it to come.

Actually, with Conductor and Splitties my life became much, much better! 🙂 Beautiful animations are included in Conductor, while Splitties provide cool UI generation. Maybe my UI is not so complicated, but I see no real obstacles to solve with Compose 🙂 What I would really like to have from Compose is support for multiplatform Kotlin development. But I don't believe in success with that in the near future 😞

Compose will allow to make things that are not even UI, so you can be sure to see an iOS implementation of Compose UI at some point, and for other Kotlin targets too, including JVM. Regarding multiplatform, I've thought about porting SnapKit or an equivalent in Kotlin/Native, so I can then use coroutines in full Kotlin UI. Can you confirm Conductor allows you to keep using

DialogFragment

without issues?

To make multi-platform UI really valuable you have to make its API 100% equal on all supported platforms. Currently afaik only js-based frameworks give that opportunity, all others have more or less differences. As for me, it would be cool to have Splitties for iOS backed by Kotlin Native 🙂 But I guess there is a very long road for that (and for Compose as well). As for Conductor - yes, they have DialogController (not Fragment), and it is not only fully-functional - it also supports cool animation for showing and hiding 🙂 Just take a look at their sample app.

100% is not needed. It's only a dream that is impossible if you use UIKit and Android Views