https://kotlinlang.org logo
Title
d

damian

05/15/2018, 9:21 PM
My Android Studio has been having lots of trouble resolving
kotlinx.android
synthetic extensions lately... I would say that they're just unresolved 80% of the time, which makes editing very difficult. I keep looking at the bug tracker but haven't seen any issues... is this a known or common problem? Has it been fixed in a recent update to something that I'm not aware of? Currently on AS 3.1.2 w/ Kotlin plugin
1.2.41-release-Studio3.1-1
of the plugin 😕
l

louiscad

05/15/2018, 9:32 PM
I recall having the same issue in a project where I use them, but IIRC, the compilation went fine. FYI, I didn't report it, so you should do so on b.android.com and I stopped doing UI in xml, making a View DSL instead, so I don't need all those hacks (but needs to compile for preview): https://github.com/LouisCAD/Splitties/blob/master/viewdsl/README.md
a

adams2

05/16/2018, 12:21 AM
I've had to rebuild my module from time to time
g

gildor

05/16/2018, 12:41 AM
@louiscad Interesting cons and pros. Funny, that many of xml cons can be easily solved by databindings
p

Paul Woitaschek

05/16/2018, 7:18 AM
You have to downgrade the plugin to 1.2.31
l

louiscad

05/16/2018, 7:21 AM
@gildor But then, I'd have to write the cons of databinding. Totally need to get up to date on this BTW, changed a lot since I tried it (and got disappointed by bugs in the early days)
g

gildor

05/16/2018, 7:27 AM
I love databinding, for me looks better than dsl for views, especially with all existing problems (lack of styles and theme support), problems with preview and UI builder support. But of course there are own problem with annotation processing, guys from Android Team hope to solve it at some point and give us real incremental compilation Also, I forgot to ask them but it would be interesting experiment to generate not only bindings, but also code that can inflate views without reflection. Not sure that this worth it, but would be interesting experiment
l

louiscad

05/16/2018, 8:08 AM
@gildor Splitties View DSL supports themes, you can do styles programmatically, and xml styles support is planned, after I see how this works: https://github.com/airbnb/paris
g

gildor

05/16/2018, 8:08 AM
I know that this is possible, but not really pleasant imo
l

louiscad

05/16/2018, 8:09 AM
Preview works on compiled code
g

gildor

05/16/2018, 8:09 AM
I wouldn’t like to do complicated layout in code, xml still looks much better for me, especially with constraint layout editor
l

louiscad

05/16/2018, 8:16 AM
For me it depends. Kotlin code allows you to articulate your logic with much more freedom, allowing to make complicated things simpler in code. It has been more than 6 months that I do UIs in Kotlin rather than xml, including using ConstraintLayout, and I would not go back. Yes, I miss the layout editor, but I can define extensions that move the boilerplate away, and I can compose UIs with extension functions while keeping a flat layout hierarchy. However, if I needed the layout editor, I'd definitely use xml, but I didn't have this need yet
g

gildor

05/16/2018, 8:17 AM
Layout editor for constraint layouts with instant preview is winner for me
and databindings
l

louiscad

05/16/2018, 8:24 AM
I used to like instant preview, and I admit I kinda miss it, but not that much because Kotlin conciseness and features make me need a lot less fine tuning. I usually get what I wanted on the first try. BTW, here's a very simple
ConstraintLayout
example: https://github.com/LouisCAD/Splitties/blob/master/sample/src/main/java/com/louiscad/splittiessample/about/AboutUi.kt#L43 (yeah,
LinearLayout
would be better suited in this case, but you can see the used extensions)
g

gildor

05/16/2018, 8:26 AM
Without habit to write such code looks much worse then declarative xml, but I see of course some advantages of this approach, sure, and even plan to try it with new app, but only because this app has very custom UI and a couple screens, still not sure that this is scales for big apps with a lot of layouts
l

louiscad

05/16/2018, 8:30 AM
In my case, it did scale to a significant app rewrite where I sometimes used two bottom sheets in the same
CoordinatorLayout
p

Paul Woitaschek

05/16/2018, 9:13 AM
Why don't you use anko?
l

louiscad

05/16/2018, 9:17 AM
Because anko is much much bigger, and less easily extensible. Splitties View DSL is built with library size considerations in mind, and is ViewGroup agnostic. Adding support for one is just writing one method for layout params. I also find my approach to be simpler.
Also, there's no need to write any new method to support a "non standard" View. You just call its constructor using a method reference or a lambda, and that's it.
p

Paul Woitaschek

05/16/2018, 11:04 AM
Interesting library
A note: It's paint to use constraintlayout layoutparams from code
For code constrains, ConstraintSet provides a nicer API
l

louiscad

05/16/2018, 11:30 AM
I plan to add support for ConstraintSet too, but I didn't feel pain using the current approach 😄
p

Paul Woitaschek

05/16/2018, 11:34 AM
😉
Also it looks likeContext.wrapCtxIfNeeded is creating ContextThemeWrappers for each single view
l

louiscad

05/16/2018, 11:35 AM
Nope, it's creating it only if you specify a theme
But I plan to provide a function to create a context theme wrapped concisely so you can reuse it for multiple views
without having the child ones to be instantiated using parent's context