The identity of an Android application consists of its package name, its label, and its icon. In a Xamarin.Forms Android application, these are specified in the AndroidManifest.xml file and as an attribute on the MainActivity class. So how would you create a build configuration with a different value for these three properties? For example, if you are creating a white-label application.
When I tried to build my Xamarin.Forms app for Android in App Center with my existing build configuration, it failed. This was odd, as the project could be built on my local machine without any problems.
I recently spent a considerable amount of time looking for a reason why the data binding in one of the Xamarin.Forms pages was not working. When I found the cause, it made perfect sense. But it was not easy to identify it.
There is no built-in support for rendering SVG images in Xamarin.Forms, but there are a few NuGet packages you can use to add this functionality. Xamarin.Forms.Svg has worked well for me. It can create an ImageSource from an SVG so that it can be rendered by Image view just like other image formats.
Navigation in Xamarin.Forms Shell is based on URIs. Parameters are passed between pages in the query string. I just recently learned that as an alternative to using the QueryProperty attribute, you can also implement the IQueryAttributable interface. I also didn't realize that you don't necessarily need to implement either of them in your page class. They work just as well in the class assigned to the page's BindingContext, which is typically your view model.
Thanks to Xamarin, C# developers can use a lot of their existing knowledge even when interacting with native Android (and iOS) APIs. However, some APIs still break the idioms we're used to in .NET. When I recently had to integrate Firebase Cloud Messaging into a Xamarin application, I encountered an asynchronous call that couldn't be awaited. The method even returned a Task. It just wasn't the right Task.
Toasts are a common way to non-intrusively show information to the user. Unfortunately, there's no built-in control for them in Xamarin.Forms. I also couldn't find a dedicated third-party library with a customizable cross-platform implementation. So I ended up implementing them using the more general-purpose Rg.Plugins.Popup library.
Xamarin.Forms Shell navigation seems well documented but either I don't understand the documentation correctly or it isn't accurate.
Xamarin.Forms Shell makes navigation in Xamarin.Forms apps much simpler by using URL based routes instead of the NavigationPage-based hierarchical navigation. It works well even for modal pages. However, there's no proper support for returning values from modal pages.
In Xamarin.Forms Shell, the flyout header is always positioned at the top of the flyout even if not all menu items fit on the screen and scrolling is required. It's a great place to show an application logo or the avatar of the logged-in user. On iOS, it is by default rendered in the safe area, making sure that it is not obscured by the device notch or the status bar.
Custom controls are the most common way for reusing parts of markup in Xamarin.Forms. When displaying collections, data templates can often serve as a simpler alternative with less overhead. For displaying individual objects, control templates can be used instead.
When following the MVVM pattern and using a view model for a Xamarin.Forms page, most of the bindings will simply bind to the view model properties. However, there are still cases when that's not enough and a reference by name to another element is required.
The default Picker view for Android in Xamarin.Forms includes an underline. To get rid of it, a custom renderer is required. However, the new control might have another undesired side effect in rendering.
The Button view has an IsEnabled property that can be used to disable it. However, when a command is bound to it, the button is initially enabled no matter the value of the IsEnabled property. This can introduce a subtle bug that's not always easy to notice.
The Xamarin.Forms Entry view has a flag for password input. However, there's no built-in way to allow the user to look at the password to make sure it was entered correctly. This is becoming a norm in mobile applications. Fortunately, it's not too difficult to implement.
Font Awesome is a great collection of icons packaged in a font file. There are multiple blog posts about using them or other custom fonts in a Xamarin.Forms application. But at the rate Xamarin.Forms are evolving, none of them is fully accurate anymore. So I decided to document the steps I followed to get it working in my project.
During long-running blocking operations such as login, the application UI should be disabled and the user should get visual feedback that some processing is in progress. Although there is an ActivityIndicator in Xamarin.Forms, there's no easy built-in way to create an overlay.
If you create a new Xamarin.Forms Shell project based on the Flyout template, it's already going to include some boilerplate for the login process. To make it work for my use case, I had to make some improvements to it.
The Moq mocking library in version 4.13.0 added support for matching generic type arguments when mocking generic methods. The documentation doesn't go into much detail but thanks to additional information in IntelliSense tooltips and the originating GitHub issue I managed to quickly resolve the no implicit reference conversion error which I encountered at first.
The Enterprise Application Patterns using Xamarin.Forms book by David Britch is available as a free download on the Microsoft's .NET Architecture Guides website. It's a good introduction to MVVM. It can also serve as a refresher for someone with past MVVM experience who hasn't worked with Xamarin.Forms before. Although the sample code uses Xamarin.Forms, it's almost just as useful to WPF and UWP developers.
The book is a great first step into the world of Xamarin.Android for a seasoned .NET C# developer with no previous development experience on Android. It's definitely enough to get you started and makes it much easier to decide whether this is the right way to build Android applications or not.