https://kotlinlang.org logo
Join Slack
Powered by
<@UAYSNLD7T> I may be biased, but I think XML is b...
# android
l
@nwh I may be biased, but I think XML is bad because it splits your UI code into at least 2 tightly coupled files, and usually, it's not straightforward to change it, I feel like it's throwaway code, that doesn't play well with UI A/B testing for example. That's why I made Splitties Views DSL (after I gave a try to Anko but found it not flexible and lightweight enough): https://github.com/LouisCAD/Splitties/blob/master/views-dsl/README.md
d
You are biased and your pros vs cons is also incorrect -- I'm all for custom views and using XML (and therefore also pro Splitties Views DSL), but your reasoning is off by a lot because you don't consider a lot of functions actually available, including custom views, appcompat properties and the fact that a lot of code invocations in views actually are visible in the layout preview even though your document acts like it's not.
r
The term tightly coupled is a wrong term to use. XML is the standard, so it gets alot of support from Google. Features Like databinding , the improved design tool / Constraint Layouts, help improve the experience. Android Extenstions to save people time from adding findViewById boilerplate. And its only going to get better.
g
well, I once convinced a team to use databindings. I still feel like I need to find them and apologize 😬. But everything else stands: IDE support + synthetics seals the deal for me. Idk were it's coming from, this "splits your code" argument, but I never felt the urge to have it in one file, so I can finally have a mixed, react style code. Quite the opposite. Maybe Flutter will change my mind, tho..
r
Databinding is Great if you ask me. Especially when put together with the android Lifecycle component, makes things so much better... Maybe you mean back in the day when databinding was first released. because the Team at Google has made drastic improvements since than
For a framework like Flutter it makes sense,because its UI driven.
@ghedeon I would say try databinding again, with the new v2 compiler, im sure you will like it
v
@louiscad Great effort, XML needs to go. It would be dope if splitties supported serialization/deserialization to some portable format e.g. json, then you could send UI changes via e.g. remote config.
K 1
s
@Derk-Jan Karrenbeld Splitties Views DSL also have preview as far as I can see
✔️ 1
@rkeazor in my day to day experience I rarely to almost never use design tool, even for Constraint Layout.
🍻 1
l
@Derk-Jan Karrenbeld Custom functions wrote in Kotlin, functions, higher order functions, extension functions, and more are not xml and are therefore not available in xml. I'm biased because I made the library and I've been using it practically exclusively for more than a year for all the projects I've been working on, but my arguments in the docs stand, I just don't talk about databinding because I'm not used to it, so my comparison would miss some accuracy. I tried databinding back in time, when it was brand new, with rough edges and had a bad experience because of compilation issues, and the fact that it was not natural to me to mix xml with code that needed to be escaped to fit into xml. I know there's been improvement, but I prefer to use Splitties Views DSL, and I know it opens a lot of new perspectives to further reduce the amount of code (yes, xml is more verbose, and I hate it because it's all useless noise that I can avoid in Kotlin)
d
Your comparison document is needlessly destructive of XML views and also holds menu falsehoods. You probably don't need the selling points like that.
l
@Derk-Jan Karrenbeld Please quote what you think are falsehoods.
r
I think most people who complain about databinding having really given a full try. They come in with this bias that code cant be in XML, because that's what they are used to. But it's quite the opposite. Databinding allows you to encapsulate UI logic in XMl and all business logic in code. That's why it fits so perfectly with MVVM architecture. Before we had to handle UI logic in code. That ment writing no need to write unnecessary boilerplate like a setTextView method , setButtonSize , setTextColor ect... We all know those 3 line methods what literally annoying.
Databinding handles all that, and like I said the v2compiler, with improvements to code generation, and errors make it nice, I would encourage you to make it nice. I have been opportune to work on production projects with and without databinding and I def prefer with
l
@vishna Splitties doesn't prevent you to use #serialization or anything that can be done with Kotlin. It's "low level", allowing you to do the same as xml, plus using the java/Kotlin APIs. You are free to mix it, compose it, wrap it, it's as flexible as it can be, and you can surely control it with Firebase Remote Config, although it's better to not tight couple Firebase APIs and your UI code, and use a thin abstraction layer between the two.
r
As far View DSLs. XML is a DSL to lol, but the only difference its supported by Google since day 1 lol... See there is something that happen to the android community when Kotlin came out. With the ability to create DSL like structures(a feature that I love), Developers starting going overboard with it lol... I see thousands of DSL libs now. DSL libs for every single thing😅... testing, ui, networking,sharedpref, you name it. And dont get me wrong, it's really cool. But it doesnt mean we have to throw the old things away lol... XML is very suitable, and has great tooling support. Yes there is a design tool for Anko as well, but would you really compare it to the design tool that ships with android studio?
d
- Repeating app/android leads to hardly readable code. It doesn't, and if you must you can use a and b, but no one I work with has ever complained about either repetition nor the readability. In fact it helps with autocompletion and separating standard properties from custom ones. - ..You can't preview them... Yes you can, if you have a grey box then your code is either not compiling or not compiled at least once yet. You actually name this a PRO of Splitties, so this entire point is just there to make your library look "better" when you actually disprove this to be true by implementing it correctly in your library. - UI code is split over at least 2 files Yes: HOW it works in one file and WHERE it is placed in another file. I think this is actually a pro and not a cons. You want composition to be decoupled from function. - If you support API 16 and lower, LTR support is subpar Has nothing to do with XML, the same is true if you set these properties through code. Furthermore, if you use a dimens value, which you should, you don't need to keep them in sync, because it's automatic. - You can't take advantage of Kotlin extensions and other Kotlin features.: What are you talking about? Why do you want kotlin extension functions in xml? You can use extensions just fine when layouting with XML. - If you want to make your UI dynamic, you need to use code, and xml is not really code, so you need to split your UI logic, being more error-prone in the long run. This is the same argument as before: composition vs function. - Reusing parts of UI is hard and verbose, because you can only include other files, but there's no things like functions for example. Use custom views, and do composition in XML and function in the code. Same as before. I agree that it's not always straightforward to do and 
includes
have caveats, but these limitations actually help you to separate between... again composition and function. And then in your pros of splitties, your arguments are again not equivalent. Splitties DSL is more concise because you're basically building custom views. Compare custom views with custom views, not out of the box XML configurable views with custom view builders. You can only reuse it better because you don't know how to do reusable components with XML, which is clear from the document. More apples and oranges comparisions here.
I actually like splitties views, but I completely am against the way you make everything an "us" vs "them". Your pros and cons sound like a marketing strategy. If the library is that good, you don't need these at all, and especially don't need the points that aren't even true.
l
@rkeazor When you use Kotlin Android Extensions for xml imports, your Activity or Fragment is tightly coupled to the xml file. I prefer to have the UI logic in one place (abstractions and utilities aside), makes it easier to read IMO.
r
@louiscad guess what , wherever you put your UI Logic , your activities and fragments will be tightly coupled to it hahah. That's why I said that statement doesnt make no sense
❎ 1
I can put my UI views in another Kt file. My activity and Fragment will be coupled to that file lol
❎ 1
Or what create a whole interface for the file. That would not be useful
o
it’s not a feeling really, clean code dictates this
it’s auto-wrong
s
Use custom views, and do composition in XML and function in the code. Same as before.
Can hardly agree with that. Even if you will do your custom TextView, you always have write <MyTextView android:blablabla android:blablabla /> in order to include it onto another layout and set android:text for example, right? But if you use your custom view as a function, you simply have to write myTextView(text="bla"). And I am not even talking about all the hussle when you want to create your custom attributes.
r
Databinding makes making custom attributes , simple lol
@louiscad Why the negative square, you don’t believe lol?
Do you want the android development to be more like Java Swing Development lol
Not me lol
l
@Derk-Jan Karrenbeld I'm quoting the xml vs Splitties Views DSL doc and replying to you:
Some things that affect your Views can only be done from code, leading to 2 problems: You can't preview them, and your UI code is split over at least 2 files.
When using xml, any UI stuff that needs code (beyond what xml can offer) is done in the Activity or Fragment, which needs to be run on the device, which may mean going deep into the app, possibly with login, unless you find a workaround or have a special way to preview with code using the xml layouts. When using Kotlin code, and preview system like Splitties Views DSL has, you preview everything, except code not tied to the UI. So I think that stands true. If you want to clarify this point, you can fork the project, create a branch based on 
develop
and submit a PR.
You repeat android and app over and over, cluttering the code, resulting in hardly readable code.
Don't get me wrong, I can read xml, it's just more characters than when I use Splitties Views DSL, which makes it longer/harder to read. I didn't spend time doing thorough comparisons regarding metrics, but I remember migrating several files, resulting in half the lines of code, not even counting the number of characters decrease. Maybe "hardly" isn't the best word, yes, you can also submit a PR for this if you want.
If you support API 16 and lower, LTR support is subpar.
And it is true. Did you read what's stated below? And it has to do with the tools given by Google for xml layouts. With Kotlin, you make an extension function/property (which are provided OOB in Splitties) and forget about it. With xml, you have to specify left+start and right+end. I'm now replying to the rest of your message: I'm comparing what Kotlin and Splitties Views DSL allow vs XML alone. Apart from 
<include/>
, there's no such thing as reusable xml, it's all custom views with Kotlin or Java code, or bytecode. You completely missed the point I think. Anyway, as said above, feel free to submit PRs if you want to make things more specific. Finally, remember Google Pixel, iPhone, Java, Kotlin and many other great things would ne nowehere near they are without what you call "marketing". I tried to make something objective, and I'm happy to receive contributions. Doing the thing and designing the API is already (free) time consuming. Writing the docs only adds up, and I'm the only maintainer for now. If you want to debate the docs further, please open an issue, or submit a PR directly if you know how you think it should be edited 🙂
@rkeazor lol?
g
@rkeazor Nope, not buying it again) Expectations about Databindings don't meet reality. As a concept, it plays nicely with MVVM, that's something I'd say on a conference. But it's a cognitive illusion to automatically imply that android implementation is good. It's was always shit and it's still shit. Without thinking about theoretical abstractions, my expectation is that I have fewer headaches after I move to DB. And I'm not getting this feeling of something light and smooth in my project. It's the opposite. Chains of 
notifyProperty
, 
notifyall
, another Observable interface in the project (like the third one?), BR files, stupid behaviour like this one, that you can debug for months without knowing what's going on https://stackoverflow.com/questions/46680862/android-databinding-onlongclick-not-working. Terrible IDE support, yeah, yeah, it's getting better, but my layout is still red unless I compile/recompile 10 times. Compilation errors because of broken compatibility with gradle plugin. Bad navigation from xml to source (to adapters). Sometimes it's possible, sometimes not. And with kotlin you don't need adapters at all, because it's basically an extension. The difference is that kotlin extension is better from any point of view and adapters are hard to debug. You can't easily copy & paste layouts, because they're coupled with models.. etc, etc. I prefer to think of my UI as of something very thin and static. With DB I'm getting something liquid, heavy, buggy, non-debuggable... something is happening somewhere. Reminds me of EventBus days a little.
➕ 2
l
Do you want the android development to be more like Java Swing Development lol
@rkeazor I'm more inclined to dance with #tornadofx than with Swing 😉
r
Man are you two selling books on Amazon haha
@ghedeon , one thing, android implementation is good. Its not perfect no ,could it be better probably(Who’s code couldn’t), but its definatly not crap… The developers at Google have really been trying over the last couple of years, and I am very impressed with the improvements that have done and will probably continue to do in our ecosystem. Secondly, I can tell you from experience that Databinding is good. Don’t trust Stackoverflow users completely, a-lot times its because they wrote bad code lol. I have worked on a project with databinding , and without databinding. And I can tell you from first person experience databinding is better…
l
@rkeazor Let's get constructive:
I can put my UI views in another Kt file. My activity and Fragment will be coupled to that file lol
I have some (unfortunately non open source) projects where my Activity overrides the 
onCreate
method and calls a single 
suspend fun
from a launched coroutine. And that's all. If I need to trt an alternative implementation, I just have to call another function. The function can create and set the UI, and start all the logic. I'm looking forward showing examples of this in an open source project, but my time is limited, so it won't come tomorrow morning.
@rkeazor Databinding in xml layouts is probably better than xml layouts without it, sure, but aren't we talking about Splitties Views DSL in this thread?
r
Im sure the library is nice.No Doubt. But in production I would still go with XML.Its the standard for android development. . Also when motion layout comes out, your not even going to take advantage on the new design tool. Also I do not want a swing style way of coding… And no matter where you put your UI, your Activity and Fragment will need it, so saying your activity is coupled to its views doesn’t make sense
l
@louiscad guess what , wherever you put your UI Logic , your activities and fragments will be tightly coupled to it hahah. That's why I said that statement doesnt make no sense
As I said above, you can have UI code less coupled to the host Fragment and Activity. If you doubt it and want to be proven wrong, read Splitties Views DSL docs (especially the part about the 
Ui
interface) and give it a try to see the difference.
r
Show a small code example.lets see what you mean by less coupled
small simple code example
l
@rkeazor Splitties Views DSL is just a Kotlin library using the public Android SDK. You don't need further Google support when you're already using the official SDK, right?
@rkeazor I'll grab my laptop and show an example in minutes
r
This is just like the argument between Dagger and Koin lol
Like in a production app I will always go with Dagger, because one its back by Google. Its been proven to scale..
l
I'm not used to Dagger, nor Koin or other DI library/framework, so I can't tell
@rkeazor Do you want Google to write your own code so it can be proven to scale? LOL!
d
I'm not going to send a PR for your biased unnecessarily hostile documentation. Again, I like your library, I don't like your marketing because it's both off-putting and I think bad service to juniors who take your writing as fact.
r
hostile documentation?
s
Do you want the android development to be more like Java Swing Development lol
Me personally want React-like style UI programming in Android
d
"XML is bad, my library is good: here are reasons that are purely based on my personal experience and since I feel this way, it's factually true that xml is bad."
r
lol Thats what Flutter is for
🙂 1
d
When using xml, any UI stuff that needs code (beyond what xml can offer) is done in the Activity or Fragment, which needs to be run on the device, which may mean going deep into the app, possibly with login, unless you find a workaround or have a special way to preview with code using the xml layouts.
This just proves to me you don't understand custom views. No need to do anything in the activity or fragment, and if you MUST have special handling, the 
View.isInEditMode
solves that for you. Most of the other argumentation you give can be solved exactly the same, and that's that.
r
lol no need to be mean guys, it was just a debate… I understand his view point. But I dont think its all the way valid in why XML is bad
l
@Derk-Jan Karrenbeld I think qualifying my doc as "hostile" is an overstatement, but we have different points of view I think. Also, it's factually true that most xml layouts are more verbose than what you can do with Kotlin, so you can try to summarize it as you wish, but this is not constructive IMO. Consequently, I'll stop this debate that I find a poor use of my time, not spent improving the docs, the library, or working on other projects. Issues and PRs are the place for this kind of discussion.
@Derk-Jan Karrenbeld Custom views are not XML!
Custom views are code + xml, or just code. And I dislike to have code + xml for one thing across to files that are not even in the same directory. This is an opinion, and use what you want. I said from the beginning I'm biased, just like everyone is because of personal experience.
r
Lol Im not biased, I’ll try everything atleast once. never tried splitter views but maybe one of these days. However I am agianst the idea of saying xml is a FrameWork design flaw…
XML is just a DSL like everything else . Just like the Kotlin DSL your trying to promote
l
I think xml was good when Kotlin was not a thing, and that's when Android started. However, I think Kotlin can offer more than XML now, and that's been my experience for months, from my point of view.
s
Thats what Flutter is for
That fact that Flutter chose React-like paradigm for building UI is telling something... Why do Android community can't adopt same patterns? Only because Google advocating on xml? Those Google that made fragments and were advocating to write all your logic in Activities and Fragments?
r
Everything turns into code in the end lol. But the fact that Google, handles that code generation and there are is a hugh team of deciated talented devs activity getting paid high salaries just to improve it. Yea I will go with XML
Google built Flutter to. And the reason why , they choose that style ,is because the leads of the project were seasoned web devs lol
Thats why lol
Im sure it also gain inspiration from React Native, being thats its major competitor
But thats a UI driven multiplatform framework…its used case is completely different
You should compare android development to IOS development. in which IOS has there own XML files, and design tool. But Android just did it better🕺
s
What do you mean "UI driven multiplatform framework"? How it is different to Android?
r
thats a longer conversation lol. Android Framework , is a native framework. Which means its API’s are not all UI focused. Thats why you have access to device component natively. Local Storage, Bluetooth, Sound ect… Sure Flutter now is getting alot of 3rd party libraries to handle that, but that is not its use case
Why would google create another framework to compete with there current framework . Why would they spend alot of resources adopting Kotlin, when they can just use dart. Because the two framework, don’t have the same usecase, AirBnB thought they did , and quickly found out they were wrong😂
g
Does it take ages to see your xml edits applied on iOS as well? simple smile Instant Run is proven to be inconsistent and doesn't matter how hard I smash that 
Reload
button I'm not getting a reliable preview in design ToolView. So, the UI development cycle on big projects is "move the button 2dp to the left, recompile, go for a smoke, check reddit, see the result. Repeat". I actually caught myself avoiding ui tasks because it's irritating and you can't stay in the flow with such delays. Hot reload from Flutter sounds like heaven, but that's probably another discussion about advantages of having direct access to your VM (DartVM)...
r
lol Instant run was a failed attempted, i agree lol. But thats because its really hard to accomplish such a feat with the level Code Generation in the Android Framework.. And Flutter is great, but its usecase is different
l
iOS developers also have their xml, which is worse, but with an editor of comparable quality. iOS developers are making UIs with Swift code too, more than in the Android because their xml is worse (and is hard to deal with when collaborating, possible hard merge conflicts), and probably because making UIs with a good programming language like Swift (which is quite like Kotlin) is enjoyable or more productive.
r
Android is better so we don’t have to do all that
s
iOS developers are making UIs with Swift code too
This is true in my experience, my iOS collegues dropped XIBs and do all UI stuff programmatically
@louiscad Speaking of
Preview requires a build (but you're less likely to need preview thanks to additional type safety and more expressive UI code).
As far as I know, if your layout completely in code, then full build is not required, but only "compileKotlinDebug", which is much much faster then full build. The only downside of this is that you have to run this task and refresh preview manually
👍 1
n
Well, this turned into quite a discussion. FWIW, I actually don't find the "preview" feature of XML very useful at all. With most of my layouts, it doesn't really offer a meaningful preview. So I definitely don't feel like I'm losing anything there. I also like the idea of @louiscad's DSL (which I had seen before) because I can inter-mix it. For some views, XML just doesn't cut it, and having a view DSL is a nice alternative to relying on custom Views.
l
@nwh FYI I make custom views with Splitties Views DSL too. You can see a few examples in the "Material Lists" module in Splitties.
@sngrekov Very nice suggestion! I'll add it to the documentation
@rkeazor Here's a rough example of an Activity less tightly coupled to its UI:
Copy code
class SomeActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        val ui: SomeUi = SomeUiImpl(this)
        setContentView(ui)
        coroutineScope.launch { // coroutineScope is an extension on a subclass of the enclosing class.
            doSomething(ui) // This is a cancellable suspending function that never resumes because
            // it is either working, or waiting for user input/interaction
        }
    }
}
The `doSomething`function could be called 
displayNotesListAndAwaitForUserActions
in the main Activity/Fragment/Whatever of a notes app like Google Keep.
👍 1
n
Good to know, thank you. At one point I did try using your ConstraintLayout DSL but I had some trouble with it (although I gave up quite quickly). I'll give it another shot and contact you if I have problems.
l
One point I find important to add: A lot was discussed that 
android
and 
app
are not pollution. I do believe they are indeed. 
(
& 
)
are also readable and understandable; 
;
is readable and understandable... But Kotlin does what it can for you to not use them.
get
and 
set
everywhere are also understandable, but are also considered visual pollution
Any block of letters that your brain must decipher to understand something is a cognitive effort that you may not notice, but exists. So reducing the amount of syntax necessary is good, even if the alternative is not that bad
➕ 1
r
ConstraintLayout DSL? @louiscad I see what your saying. Fair enough. I would still go with XML tho. I just don’t find it useful to create another DSL, when there already is one in which of the UI in the android framework is based on upon . If I need a reusable layout ill just create a custom view or use<include> … But thats just me l. If you like it better, go for it..
get and set are not considered visual pollution lol
@LeoColman
If that was true, than every keyword would be consider visual pollution
thats abit overboard lol
They are O(1) in thinking Time Complexity 😂
l
@rkeazor Leonardo is not referring to the 
get
and 
set
keywords in Kotlin, but to the prefixes in Java 
getSomething
and 
setSomething
, compared to the less visually polluted property syntax that Kotlin offers.
r
Thats not visual pollution either lol
You guys are wild lol😂
The property syntax I like it better , its def an improvement. But Java doesn’t force you to create getters and setters, you guys do know that right. You guys litterally type the prefix yourself
thats like saying a function called fun isFun() is visual pollution
l
Even when thinking about it is easy, and they're not complex at all, they're something your brain will have to focus. When everything is added together, and you have 20 lines of setters in a row, it gets hard for you to understand everything.
➕ 1
l
@rkeazor Every noise like xml namespaces (e.g. 
android:
), verbosity (e.g. SAM anonymous classes), etc, add to the effort your brain needs to do to read and understand some code (just like a book, an article or anything that can be read or seen). That effort is felt when first encountered, but over time, while you stop noticing it, you still get tired more as this is consuming a bigger part of the unconscious side of your brain resources, that are not used to read faster, understand better the point, have it fell like it's simpler…
r
🤦‍♂️
lol
l
That's not even counting the limited space taken on screen
But if you enjoy noise while trying to understand lyrics in a new sound, then, go for it, it's your choice.
r
You guys are going overboard… For instance, if you want to consider thinking complexity, than one if statement , is probably equal to 100 function names with get and set in them lol
Let alone tenary statement
Let alone Elvis operator
Let along nullability questionmark
What Kotlin improved on was verbosity
l
You said that verbosity is ok because it's O(1) thinking. If you escalate that to 100 times per class, 100 classes per project...
It's still O(constant), but the constant is so big that it matters
r
But to go overboard and say function names with get and set prefix caused more cognitive pollution than normal function names is overboard… To be honest prefix helped because they normally tell they return type of the function they are using. So you can compare it to memoized algorithm vs a normal algorithm 😂😂
So the original is a MiniMaxAlgorithim and with prefix is AlphaBetaPruning… And property syntax, says hey forget that, just assign it directly lol
l
The point that I was trying to say is that functions with 
get
and 
set
vs property access with no get and set and no 
()
is better
r
Yea property syntax is better. I def agree. but I just don’t agree that a function with a get or set prefix caused any cognitive issues lol
l
One verbosity sure doesn't cause significant issue, but as Leonardo said, it's O(n), so when they are all over the codebase, it becomes very significant. Maybe you never feel this issue, or you have a dedicated part in your brain to overcome verbosity with ease, but that's not a generality, and less verbosity is always better as long a stuff stay explicit enough. But, this is drifting off topic, right?
Open in Slack
PreviousNext
Powered by