The Two Roads
Xamarin forms development offers form construction either via XAML mark up or via code. I've been experimenting with both to see what route I would recommend to anyone building cross platform mobile applications with Xamarin.
What I've determined is that, for me, there isn't a clear winner. Both have positives and negatives that pretty much balance out. So in this post I will review each and give my perspective on when one might be more appropriate than the other. My hope is this will give you the information you need to answer for yourself and your scenario which option is the best choice.
The XAML Road
Extensible Application Markup Language, XAML, offers Xamarin developers a means to separate presentation from code. It allows you to develop your interface in an XML schema that is used to render the screens your users interact with within your mobile application.
The Positives
- XAML fully separates presentation from code. This contributes to your applications becoming more loosely coupled with leads to greater maintainability in future iterations.
- Designers don't have to learn .Net code to work with XAML. It is strictly a Markup language that will feel familiar to designers that have worked with HTML in the past.
- It provides fine grained control over the User Experience, UX. Designers can build the exact presentation they want directly in the Markup
The Negatives
- To build with XAML you must know XAML. It is it's own syntax. If your designer does not have experience with it they will have to get up to speed before they are able to produce designs with it.
- It will have to be wired up to back end code. This isn't hard to do but it is going to require clear and ongoing communication between the designers and the developers. If this isn't a strength for your team you will need to address it or be faced with a painful implementation process.
- You are going to need designers and developers. XAML is a separate skill from development. Your developers can learn it, but while they are building with XAML they are not writing code.
The C# Road
In Xamarin, C# can be used to accomplish the construction of the screens your users will interact with. They are simply built with code instead of Markup in the case of XAML. If managed properly this architecture can work as well as XAML, however, it does have the potential to create a maintenance disaster if you don't have a strategy and stick to it.
The Positives
- Developers can build the presentation layer without learning a new “Language”. C# has the objects needed to construct all the screens and interactions users will experience within the application.
- A developer can take the place of a designer. Their construction of the features of the application can be expanded to include the design of the screens as well as the back end processing of the application.
- Since dependencies on markup are removed from the construction process some time can be saved and a working version of the application can often be delivered more quickly.
The Negatives
- If strict care is not taken to architect the presentation objects so they are loosely coupled with the business tier objects the application will quickly become tightly coupled and difficult to maintain in the future. This architecture can be achieved but requires a high amount of focus up front and constant vigilance to maintain.
- Developers are not necessarily the best designers for the UX of your application. They have a knack for delivering a feature or function of the application but not typically in a pleasing or on brand way.
- Designers would have to learn C# code to construct presentation objects if you wanted them to do it instead of designers. If you are fortunate enough to have a designer with the ability to code in C# this won't be a problem but finding a designer like that is rare and expensive.
My perspective
If you are building out a small application that will remain relatively static feature wise, then you most likely will not have trouble with construction of the UX with C#. Your team can stay small, developers only, and you can contain the cost and timeline of construction fairly easily. Understand though that if the desire ever arises that this application will start to change on a more frequent basis or there is ever a need to change the technology components of it maintenance will be burdensome.
On the other hand, if the application you are building will be changing frequently and has undefined future capabilities the XAML construction approach leaves you open to building what is needed without maintenance headaches. However, you are going to need diverse skill sets which usually translates to more team members, increased cost, and longer time lines. Depending on your budget constraints for money and time this might or might not be of concern.
