Intro
I recently wrote an Android app using a framework called Xamarin.Forms. Xamarin.Forms is a cross-platform UI framework that enables developers to share code across all major mobile platforms (IOS, Android, and Windows Phone) that’s written in C# and XAML. After implementing this app, I would like to report my findings.
Test Automation
Writing an Android app using Xamarin.Forms allowed me to leverage my existing C#, XAML, and test automation skills. Hence, improving my craft with tools that I’m already proficient in is very important. I once dabbled with Android Studio and quickly realized that I was both spoiled and more productive with Visual Studio. Working within Visual Studio enables me to stay in rhythm by depending on test automation to send feedback about my code’s integrity during code construction. Android Studio did not recognize unit tests as a first-class citizen to the IDE. Therefore, I found myself having to research how to configure basic unit tests to run. As a result of me spinning my wheels, I decided to return back to Visual Studio and its amazing support for test automation out the box. However, I did learn that the Portable Class Library does not support the “ExcludeFromCodeCoverage” attribute. Not having this support obscures the code coverage that matters to me. Hence, I could simply place the ExcludeFromCodeCoverage attribute over my code-behind class which would improve my code coverage report based on actual business logic being tested versus UX logic.
XAML
Xamarin.Forms uses a different dialect of XAML. Yes, there is still databinding, styles, data templates, and controls. However, there are subtleties when leveraging their form of XAML that differs from Windows’ XAML. For example, as of now, there’s no MultiBinding or RelativeSource binding. These binding types are extremely convenient for presenting a UI that reflects a number of factors. Also, I still haven’t observed useful intellisense within their XAML editor even though they claim that intellisense is supported within their framework. In addition, some basic properties are still not supported as an abstraction for the major platforms. For example, custom logic (i.e. custom renderer) is required for each platform to set an editor’s background color and foreground. This means that you cannot declare an editor in XAML and set the editor’s background to yellow and it’s foreground to blue. I also learned that there’s a bug where multi-line editors that are set to read-only will put all of the content within that mode to just one line. This means that a read-only editor does not show multiple lines of content. A read-only editor will only show one line.
Visual Designer
Xamarin.Forms does not support a visual designer yet. As a result, I added a WPF project to my solution to mock my view layouts and then leveraged the structure of that XAML to build a UI under my Xamarin.Forms project.
Deployment
I still am unable to deploy my Xamarin app to Google’s Play store. I receive an error every time I attempt to upload my app. I’m sure that if I keep trying, eventually I will get the support that I need to get the app deployed to the store.
Conclusion
In conclusion, I recently wrote an Android app using a framework called Xamarin.Forms. Xamarin.Forms is a cross-platform UI framework that enables developers to share code across all major mobile platforms (IOS, Android, and Windows Phone) that’s written in C# and XAML. I have summarized my findings of building an app with this framework. Overall, I see huge potential with this framework. Unfortunately, I believe it is somewhat risky to leverage this framework within its current state to build UX intensive applications. The application that I wrote can be found on GitHub.
NOTE:
Scott Nimrod is fascinated with Software Craftsmanship.
He loves responding to feedback and encourages people to share his articles.
He can be reached at scott.nimrod @ bizmonger.net