Xamarin Forms Best Practices

Author: ptDave

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

Folder Structure

I find a nice clean structure is important, and I think everyone can agree with that.

1 of 3 3/25/2019, 11:07 AM
 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

2 of 3 3/25/2019, 11:07 AM
 on platform, you can lighten the load by using this one point.

3 of 3 3/25/2019, 11:07 AM