Garden management with Azure, Part 2

Add new project ‘Class Library’ for Xamarin.Forms (CicloGardensClient)

• Create the classes GardenOfflineClient.cs andGardenOnlineClient.cs which will implement two different ways to access the backend. With and without offline synchronisation

Add new project ‘Unit Test Project’ (CicloGardensClient.IntegrationTest)

• Add test classes GardenOnlineClientTest.cs and GardenOfflineClientTest.cs
• Add to each a test method ‘InstantiateGardenClient’ and create an instance of the client. You’ll see that you’ll need a project reference to the other project

Add nuget packages ‘Microsoft.Azure.Mobile.Client’ and ‘~.SQLiteStore’ to both projects.

Run the test, and the first setup is done.

First we need a ‘Garden’ class as representation of the stored data in the backend/SQL server. My first thought was to try to use the same class for them, so we could create a dll to be used in the server- and client-implementation. After a closer look, that’s not a good solution, as I will show. Alternatively we could create an interface IGarden, to make sure we implement the same properties and types on both sides. But to be honest, I even abandoned this idea, because of the following reasons:

• Even the interface can’t guarantee an harmonic implementation, because the server- and client-side could be published from different code versions
• When creating complex class structures, and using code-first-migrations from EntityFramework, interfaces can make this business kind of messy.
• The backend classes inherit from ‘EntityData’, which allows the version management and features some specialties of the azure backend sdk. We don’t want this dependency on the client side.
• The client side is frontend oriented, so we should focus that these classes are bindable.
• Real trustworthy compatibility between frontend- and backend-data can only be achieved with good and complete testing, and that’s what we’re going to do

Thinking of bindable frontend classes, brings me to the subject of Prism, which is one of my favorite frontend SDKs. I won’t go into details here, but I’ll use the baseclass ‘BindableBase’ for the class Garden.cs that we need here.

Now it’s time for the client implementations (GardenOnlineClient.cs and GardenOfflineClient.cs), which contains:

• Initialisation of the client and, for the offline version, the local sql database for offline synchronisation.
• Get/Set/Delete functions for gardens

The classes have a property

public Task<bool> Initializer

which can be used to ‘wait’ for the initialisation to finish (and to check the success). Mainly for tests, it’s quite handy.

Now let’s get back to the client classes. Well implement for each 3 functions, including the ‘Instantiate’ test:

• InstantiateGardenClient – let’s just wait for the Initialisation to finish, and make sure it does so with ‘true’ (=success)
• SetAndGetGarden – Save a garden, read it afterwards and make sure the object has been assigned an Id from the service
• DeleteGarden – Save a garden, check for success. Then delete it again and make sure it’s really gone

In the offline version, set/get/delete tests include Sync() calls, to sync the local database against the backend.