[m_fayer]

After a quick skim this seems great, but just one piece of a much bigger puzzle. Android activities, regardless of whether the view is constructed declaratively or in code, seem to always become an untestable mess that does way too much. At least, that's what happens if activities are used as intended. IMO, the bare minimum necessary to fix this is some more elegant alternative to AXML that, crucially, has some kind of declarative databinding support. Roll that into Anko and we're on our way to taming the activity.

[zserge]

You might like Anvil: it's a declarative react-like UI library for Android. I personally use it a lot, and I normally write single-activity applications (e.g. I have my own backstack of views inside a single activity):

https://github.com/zserge/anvil

http://zserge.com/blog/anvil-2.html

Kotlin is supported as well (http://zserge.com/blog/anvil-kotlin.html)

[gcb0]

Apps like that are a pain. No matter how you reach it you end up on a infinite stream of things you don't care anymore and have to keep pressing back.

I think yelp is written as that. And to add insult when they moved to the material hype the home button on top left became yet another back button... they did add shortcuts on the left now. But it's all breaking stuff and adding bandaids on top of bandaids

[m_fayer]

Looks really promising, thanks for the hint. It's on my to-evaluate list along with: http://robobinding.github.io/RoboBinding/

Also, if you're open to Xamarin, there's a great library there called MvvmCross that gives you in-AXML databinding and a general feel similar to Angular.

[zserge]

Thanks!

Unfortunately neither of the data binding libraries for Android worked for me, because they are either too hard to extend or too big/complex.

RoboBinding's idea is nice, but to me it's too implicit. It's really hard to tell what's happening behind the scenes.

As for the Xaramin - I would like to try it, but I run linux on my development machine, and it didn't start with Wine.

[m_fayer]

The "magic" nature of databinding seems unavoidable. Either it's driven by reflection and then it's more or less understandable but the performance suffers. Or, the bindings can be generated through some kind of bytecode weaving or code generation, which are both opaque to some degree. Either way it's hard to debug and possible to screw up performance, and I've yet to see an implementation without such tradeoffs. But in the end I think it's worth it for the architectural wins.

[ericweyant]

Anvil looks really promising. I wonder why doesn't it use "linearLayout {}" instead "v<LinearLayout> {}" syntax?

[EddieRingle]

I'd guess because Anvil began as a Java project, and Kotlin is what provides the sugar that allows Anko to provide a nice DSL.

[zserge]

Almost correct. I never thought of this kind of syntax sugar initially. But technically (and people posted an issue about it) it's possible to generate functions like linearLayout() etc from android.jar for Anvil/Java. This will work with Anvil/Kotlin as well.

I plan to keep v<Class> anyway because it works nice with custom views when there is no generated syntax sugar.

[on_and_off]

>At least, that's what happens if activities are used as intended.

Activities are indeed the piece of the framework I would be most eager to see removed/revamped. I have seen many devs (even supposedly experienced ones) use/encourage to use patterns that lead to leaking the Activity context (like retaining everything, especially the UI). There will always be people writing awful code, but Activities may too hard to grok for many devs (and that's not their only issue by far).

[zserge]

My first candidate for removal would be fragments. They don't help to componentize apps at all (at least not better than plain old viewgroups), but they can make life much harder with weird hidden bugs.

There is brilliant article from Squareup about that - https://corner.squareup.com/2014/10/advocating-against-andro...

In Anvil I try to follow Square's approach, e.g. keep components as viewgroups and use a custom backstack to manage them as needed (e.g. back/home navigation, multi-pane layouts etc). Then you get just one activity per application and it's a big relief.

[on_and_off]

I am not really convinced. Fragments are not very helpful indeed but all the Android engineers I work with know their lifecycle pretty well and I don't even remember the last time I have seen a prod bug coming from them.