A few months back, I was interviewing for a job - the one I'm currently at now - and the resident Xamarin expert informed me that he doesn't use XAML for building user interfaces. I was pretty shocked. I mean, can you imagine how tedious it would be to construct a UI in code? All of that object creation, property setting and sub-view adding? It just sounded gross.
Let's face it, most visual UI builders are less than ideal. Xamarin Preview is slow, buggy and you have to go to great lengths to create fake data for it to be useful. On the iOS side, Interface Builder is also buggy and fiddly as hell. I haven't used Android Studio's UI tools, so I can't say much there but I'm sure it's a similar story. Despite the short comings of UI builders, we use them. We rely on them. We do this because building a UI in code is just gross.
Why Try Code Only
The idea of building a UI with only code was planted in my mind from that co-worker months back and I couldn't shake it, as repulsive as it originally sounded. He spoke of how much more control he had. He could conditionally display different views at runtime without rendering anything un-necessary. With Xamarin Forms, we have control over pretty much every possible property in XAML, but when building a UI for iOS, it ends up in a mixture of Interface Builder and setting properties in code because they're not all accessible in IB. Anyway, here are my reasons for deciding to build my latest UI with code instead of UI tools (this is for an iOS UI):
- I gain total control of the user interface at the deepest level.
- I can show conditional views without rendering anything unnecessarily (using XAML or IB you would have to show/hide these views).
- When building a UI for iOS, I don't end up with a mix of Interface Builder and setting UI properties in code.
- When building a UI for iOS, I don't have to use visual Autolayout tools, I can use a library that handles Autolayout in a much more user-friendly manner.
- When working with other developers, there are fewer merge conflicts related to IB files.
Is it Worthwhile?
Again, my impressions are coming from an iOS UI as I haven't done a code only UI with Xamarin Forms...yet. First impression: I love it. At first it wasn't easy. It did feel a bit gross, but I got over that. I found that the level of control afforded by building the UI in code was worth the shift in thinking and the initial learning curve.
The app that I'm working on has a very specific design and my job is to build the iOS UI exactly to the spec. If I had used a UI builder for this, it would have been much more difficult. Because I built the UI with code, I have fine control over every sub-view without dragging/dropping and fiddling with property dialogs.
I was concerned about how the code would read, with all that newing-up of sub-views and setting properties, but it turns out to be very readable. With some common sense code organization, it flows really well. I made sure to create and add each sub-view in order of appearance, so there's no question about where any UI element appears.
So far, I'm quite happy with my decision.
Of course, there are some negative aspects, not many, but a few.
- Because you have no preview of the UI, you have to run the app to view any changes you make. I found that after a while, this wasn't a big issue. I got into a rhythm and would do a lot of layout before running and viewing to make things more efficient.
- Developers who inherit your app might hate you for building the UI in code. This is purely subjective but true. Building a UI in code isn't for everyone.
- There's a lot more code, that's just an inherent truth. You'll have a lot more code for your views but it can be organized in a way that flows very nicely and reads well.
While at first I was completely turned off to the idea of building a UI with just code, the idea marinated in my little mind for a while and I just had to try it. Given that the project I'm on requires very tight control over the UI for iOS, I thought it would be a good time to do it. I have no regrets and I would definitely do it again for an iOS app. I'm not sure that the advantages are there for a Xamarin Forms app given the control that XAML provides. I still might try it anyway.