Xamarin Forms Best Practices

So I’ve written a few Xamarin projects now, and there have been a few things I’ve found that help keep your code clean. Disclaimer, this is based on my own opinion and you can take it at that.

Naming

It’s important that you do not add the name Xam, Xamarin, or Android to your namespace. Doing so can cause any plugins you add, or dependencies you want have issues. No one likes to have to do the full namespace or have to put the global keyword in. Save yourself some time and effort, just don’t use those namespaces.

Base Plugins

There are few plugins that you just might as well add. They are time savers or just so necessary in most cases, that just do it.

Xamarin.Essentials

This plugin is from Microsoft, and if it’s not already included as a pre-installed Nuget, it should be. This application provides a multitude of cross platform features that you can add. There is little to no reason to invent the wheel, just use this. Features include, but not limited to:

  • Preference Saving
  • Location Services
  • Connectivity Services
  • Battery
  • Device Information / Device Display
  • And more

If this is not included in your project, you can get it from here: https://www.nuget.org/packages/Xamarin.Essentials/

Fody.PropertyChanged

Fast MVVM, really as simple as that. When implemented, any class that implemented INotifyPropertyChanged and has the proper XML setup will automatically implement the required features to handle property updates. This can save a load of time on creating models that update. I can’t recommend this enough.

The Nuget package is available here https://www.nuget.org/packages/PropertyChanged.Fody/

Folder Structure

I find a nice clean structure is important, and I think everyone can agree with that. By default VS does not create any folders for you. So you will need to create your own. Obviously, this is my opinion but I recommend the following:

PCL

  • Controls
    • Store only custom controls you create in here. Give them a good name that will make them easily identifiable. I don’t believe any folders are really necessary inside of this. But if you do, I would recommend separating it out based on where it is used.
  • Helpers
    • I generally store HttpClient classes, IValueConverter’s, Static methods, etc.. Try to bundle things as much as possible here based on their purpose or types.
  • Models
    • Anything that I want to be based of the IPropertyNotifyChanged I store in here. I also make sure that I add a text file for anyone else looking that it must implement the interface or should be moved.
  • Pages
    • I like to store all of my views or pages in here. I always postfix the class name with Page. For example, MainPage, SignUpPage, LoginPage, SettingsPage, etc…
  • Services
    • This is my catch all for anything that can be defined as a service. Such as API Requests, Storage tools, etc… Pretty simple.

Login Flow

Your application flows from your App.xaml/App.cs. What I have found work well when you have a login system is have your Application check first to see if you are logged in, and apply the appropriate page if you are. If not, open the login. When a successful login has occurred DO NOT use a NavigationPage to go past that point. Make a call to your App.cs and have it change to your appropriate page. The reverse of this would also be true for logging out.

Limit your dependencies

If you need to share models from another front end, such as an Asp.Net app, leave your models dependent-less when at all possible.

Why? It is very easy for you to make one reference, that then makes another reference and goes down a chain. Some of the dependencies might be rather large and cause your finally binary to be huge.

Solution? Create a shared project that has only your models / dto’s. They should have no inheritance that can’t be found inside the same project. Then each front end should reference this shared project. Think of it as a bridge project.

Clean styling

Your application can share styling. Either through a css file, or through static or dynamic resources. If you begin to duplicate a style in any fashion, you should instead create a style to replace it.

Doing this will save you a lot of headache when you need to update the visuals of everything built off that style. Furthermore, if you need to apply styling later based on platform, you can lighten the load by using this one point.