Think Big, Act Small, Fail Fast and Learn Rapidly


Xamarin Diaries – Offline by default

Xamarin Diaries

Hi All!

In this new chapter of Xamarin Diaries will dive into one of the top three questions we got in Xamarin forums: How can I take advantage from offline capabilities with Xamarin Forms?

When we develop a mobile application there are some things we can do to boost up the UX. The one I like the most is offline capabilities. If you think about it, although mobile network are faster than ever and coverage is getting bigger day by day, it is still very common to get into a situation with poor or null connectivity (subway, a trip to the mountains, inside an industrial area…). In that situation we find two kind of applications:

  • The ones that get stuck on loading spinner until a timeout fires and then turn blank or block us from using the app.
  • The ones that manage cache data and connectivity and show you latest information loaded and even allow you to do some functions with it.

In this entry we will give you some tips on how to build applications in the second category.


If you have read or watched any of our posts or videos you already know we build our Xamarin apps using MVVM pattern for the UI. This allows us to decouple representation from behaviour.

Also we use a classic MVC to decouple view (MVVM) from services (we’ll cover ti in future posts).



Xamarin.Forms helps us to reach our goal by providing us with some good resources:

  • Data bindings
  • Commands

Data binding is the way we have to link an interface item (label) with some viewmodel property:

  1. <Label Text=”{BindingFruit.Name}”/>

Command allows to execute some action in the viewmodel from the view:

  1. <Button Text=”Send” Command=”{BindingSendCommand}”/>

We will take advantage from both of them to get offline functionality. How? Keep reading.

Asynchronous working

Take a look to the following picture:

MVVM implementation

In ViewModel you can see we define two command methods in the viewmodel: One to load items stored in our local repository (typically a sqlite database or json files) and other to refresh those items with remote information (from an api rest for example).

We call these two commands from two differents methods in view’s code behind.

  • Local load is launched from constructor, what of course happens the first thing in page’s lifecycle.
  • Remote refresh is called from OnAppearing method. OnAppearing is fired when all the elements have been rendered. This in practice gives local load some time to complete.

Both local and remote loads inject retrieved items in the same items collection.

ObservableCollection vs List

This item collection has to implement observable interface to be able to update items in the view when they are refreshed by invoking PropertyChanged event (if you don’t know what i am talking about you need to take a deepful look to MVVM Pattern, specially to INotifyPropertyChanged). Usually we use ObservableCollection:
  • The main disadvantage of using it is it needs an adhoc update process. The reason for that is it binds every individual element with its listview representation and you cannot just clear all the thing up, assign it again and hope everything will work. You need to loop through all the items in the collection, find the differences and call PropertyChange on each of them.
  • The main advantage of doing what for me is the best solution is that the User will see that a first list is loaded and that once the remote data is retrieved, the elements are updated in a fluid way, without flickering.

If you want to do it quicker or simply it is enough for your app, you can just use a List instead of an ObservableCollection. In a List, we can call Clear, assign the whole list again and call Propertychange for the whole list. We will see a little flickering in the UI, but from my experience, most of the times it is good enough.

So the process is like this:

  • On page’s constructor we call loadlocalitems. It takes few time as it is just a local access to the repository and populates items list.
  • This items list is usually represented in the UI with a ListView. Local items get represented in the UI.
  • On page’s OnAppearing method we call refreshremoteitems. It could be a long asynchronous call to an api rest. Nevermind, as you are using async funtions, UI won’t get stuck.
  • When it finishes it updates items list and updated items get represented in the UI.

Here is where we introduce Connectivity check.

Offline working

For this purpose we will use the following plugin: from James Montemagno

It provides a simple way to check if there is connectivity:

  1. if (!CrossConnectivity.Current.IsConnected)
  2. {
  3. return;
  4. }

We integrate it in the refresh remote load to check at the beginning if there is connectivity. If there is not, you just need to cancel it. As the local data has already been prompted to the user, we don’t need to do any further operation.

It is recommended, anyway, to prompt the user somehow when there is no connection. We can use IsConnected status to show the user a tag or a red color. Also we can use connectivity event provided with connectivity plugin to alert the user when a change in connection is fired.


We have learnt how to build robust apps by providing them with and offline ready architecture. We have also learnt how to take advantage of the resources Xamarin Forms give us to make that architecture possible.