@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

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.

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.

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..

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

@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.

@Derk-Jan Karrenbeld Splitties Views DSL also have preview as far as I can see

@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)

Your comparison document is needlessly destructive of XML views and also holds menu falsehoods. You probably don't need the selling points like that.

@Derk-Jan Karrenbeld Please quote what you think are falsehoods.

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.

@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.

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?

- 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.

@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.

@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

it’s not a feeling really, clean code dictates this

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.

Databinding makes making custom attributes , simple lol

@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 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.

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 😉

Man are you two selling books on Amazon haha

@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.

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

@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.

Show a small code example.lets see what you mean by less coupled

@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?

This is just like the argument between Dagger and Koin lol

I'm not used to Dagger, nor Koin or other DI library/framework, so I can't tell

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.

hostile documentation?

Do you want the android development to be more like Java Swing Development lol

Me personally want React-like style UI programming in Android

"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."

lol Thats what Flutter is for

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.

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

@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.

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…

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.

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?

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

What do you mean "UI driven multiplatform framework"? How it is different to Android?

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

Does it take ages to see your xml edits applied on iOS as well? 😒imple_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)...

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

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.

Android is better so we don’t have to do all that

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

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.

@nwh FYI I make custom views with Splitties Views DSL too. You can see a few examples in the "Material Lists" module in Splitties.

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.

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.

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..

@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.

Thats not visual pollution either lol

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.

@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…

🤦‍♂️

That's not even counting the limited space taken on screen

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

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...

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 😂😂

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

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

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?