4 ms·

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

by m_fayer 11y ago

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 11y ago
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 https://github.com/zserge/anvil http://zserge.com/blog/anvil-2.html http://zserge.com/blog/anvil-2.html Kotlin is supported as well (http://zserge.com/blog/anvil-kotlin.html http://zserge.com/blog/anvil-kotlin.html)
- ericweyant 11y ago
  Anvil looks really promising. I wonder why doesn't it use "linearLayout {}" instead "v<LinearLayout> {}" syntax?
  - EddieRingle 11y ago
    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 11y ago
      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.
- m_fayer 11y ago
  Looks really promising, thanks for the hint. It's on my to-evaluate list along with: http://robobinding.github.io/RoboBinding/ 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 11y ago
    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 11y ago
      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.
- gcb0 11y ago
  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
on_and_off 11y ago
>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 11y ago
  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-android-fragments.html 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 11y ago
    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.

by m_fayer 11y ago

zserge 11y ago

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 https://github.com/zserge/anvil http://zserge.com/blog/anvil-2.html http://zserge.com/blog/anvil-2.html Kotlin is supported as well (http://zserge.com/blog/anvil-kotlin.html http://zserge.com/blog/anvil-kotlin.html)

ericweyant 11y ago
Anvil looks really promising. I wonder why doesn't it use "linearLayout {}" instead "v<LinearLayout> {}" syntax?
- EddieRingle 11y ago
  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 11y ago
    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.
m_fayer 11y ago
Looks really promising, thanks for the hint. It's on my to-evaluate list along with: http://robobinding.github.io/RoboBinding/ 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 11y ago
  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 11y ago
    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.
gcb0 11y ago
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

on_and_off 11y ago

>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 11y ago
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-android-fragments.html 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 11y ago
  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.