Machine generated XML doesn’t play nice with version control for views that are even moderately complex. Merge conflicts become more of a nightmare to untangle as your app matures, plus it can make pull requests unintelligible.
This is part of why for apple platform dev, several years ago I abandoned XML-based XIB and storyboard UI design for any collaborative project. Writing it all out in code (even with just UIKit, no SwiftUI) is a lot more pain-free.
I’d like to do the same for Android projects, but Google is hellbent on the XML usage if you’re building with Android Framework… Jetpack Compose improves the situation some but I’ve not used it much yet.
> but Google is hellbent on the XML usage if you’re building with Android Framework
That said, folks rarely use the GUI editor for Android XML and managing merges isn't as painful, or really painful at all, when compared to XIBs/storyboards.
Also, as you mentioned, Jetpack Compose obviates that and every new Android view should use it IMO.
Absolutely. XML is rarely a good solution for any problem, and usually the worst.
> I’d like to do the same for Android projects, but Google is hellbent on the XML usage if you’re building with Android Framework…
For sure the Android API is oriented towards building GUIs in XML, but it's actually quite possible to build your Android GUI in Java code.
When I started developing for Android, I took a look at a few tutorials and said "no way", searched the web for how to build Android GUIs programmatically, and never looked back.
This example shows off the builder style, but since gtk-rs is built on top of GTK, .ui XML files are also supported. You can edit .ui files using the legacy Glade editor (with a conversion script), the newer (but incomplete) Cambalache project, or by hand (it's not that hard and this seems to be the preferred way nowadays)
Speaking from a mobile dev's perspective, the native UI design in 2010s was done by XML based files (storybooks in iOS/macOS, XML layout files in Android) and native code would "connect" with the XML files in various ways. Now the development is moving towards declarative approach using frameworks such as SwiftUI and Compose.
This builder pattern resembles quite a bit of how you would declare UI in SwiftUI and Compose.
> Why not design UIs in an editor that saves layout to XML?
It's funny because that's my personal nightmare. I'm a JS to Rust developer so I'm biased but the likes of React and Svelte have spoiled me with the ease with which you can integrate reactive components into a UI in a way that you simply can't when you're using a separate XML file.
I agree that the example given looks old-school but Rust has a wonderful macro system, I can imagine building a really slick compose method with macros that generates this kind of code underneath.
I've never seen the appeal of those "write your UI in a different language than the logic and deal with the interference layer" style of GUI development. But I also think that UI builders tend to produce bad code and ugly layouts when you go beyond CRUD apps that would have been easy to write in the declarative style anyway.
One argument I've heard for this model is that, by having the UI in a declarative language, the design team can update/experiment with the layout without having to understand the backing logic. I've only been on one team that actually subscribed to this model though.
I've heard this, but in practice it is hard to fully decouple the interface from the logic so experimentation with the front end usually involves work on the back end. Even simple changes like "we want to change this drop down to a set of radio buttons" ends up requiring changes on the back end most of the time.
I think good tooling support is a requirement for this to work; the one project I used this in (a Silverlight app) had first-class support for this. You could specify separate ViewModels for run time and design time, and the latter would just return static values that the designer could work against. I guess this would require some cursory understanding of C# syntax, but I think the ramp-up for adding/modifying a property would be minimal.
In a project with many developers, it's hard to resolve conflicts with generated XML. For example, iOS and Android have been moving towards a declarative approach with Swift UI / Compose.
I really like XML a lot; I've gotten large numbers of people to use XML & XSLT, where I work. XML is dated, and it is gross. Here's the two things the XML ecosystem nailed, which tie me to it:
1. A dedicated tree-based transformation language (XSL); and,
2. Axis-queries (Xpath).
If I could Xpath all-the-things, I'd be a happier human. Although, I also feel like I should be able to SQL all-the-things, too. Maybe I'm just a sucker for structured-data query-languages?
XSLT the syntax leaves a bit to be desired. There's also a number of highly questionable default behaviors that are really unfortunate. OTOH, the concept of a term-rewriting tree-matching language is pretty great.
Replace xml with anything else. You're not writing XML. It's just a format used by a layout editor. The issue with this strategy is merge conflicts and diffs that make little sense to a human reviewer.
