Chapter 11. A Portable Settings Class

All the mobile providers allow settings to be stored in an application with their own systems. There is nothing wrong with this, and it works well. The issue with any PCL-based application is that you need to write some form of wrapper around the storage code for entry and retrieval, which also means that you need to know how to use these storage systems.

In this chapter, we will examine:

• How the platforms store their settings

• How to construct an interface for these storage systems

• How to create a unified settings portable class

The native platform storage

Each platform has its own unique way of storing user data and settings. When using a native approach, it is typical for the device to store the individual application settings in the application bundle itself, rather than as a universal settings file. This is primarily not only for security, but also for usability.

Consider a scenario where a user has three messenger applications on their phone. Each of them will have a username and password setting. If there was a universal settings file, there would firstly be no way of knowing which username/password corresponded to which app, and secondly, the other two applications would potentially be able to intercept the incorrect password and use it for nefarious purposes.

The iOS native platform storage

iOS stores settings via a dictionary with the <key><value> format. Here, the type can be of the string, int, bool, or double base types. The data is stored in an app-specific .plist file and may look similar...

Constructing a persistent and cross-platform settings system

Let's consider what we know from our previous examples:

• All the system settings use a key and value system to store the names

• The methods of entry and retrieval are different

• Android cannot store all types of primitive (doubles are excluded), but it can store collections

From the PCL side, we need an interface to the main platform code:

public interface IUserSettings
{
  void SetSetting<T>(string name, T value);
  
  T GetSetting<T>(string name);
}

Unlike the example used with Android, we will not pass an enumeration as a second or third parameter.

After this, the platform implementations are required. The full source for this can be found in the Chapter 11 source code archive. I'll demonstrate how the implementation works for Android. To emulate a real setting, I've created the settings file and added some dummy data.

Creating the initial data

To start with, it's a good idea to start with creating a singleton. This is a single...

Is there an alternative?

What we have here is three different implementations for three different platforms with the same interface name. This is fine and works, but what if we want something that works on all the platforms, but isn't restricted to the limited range that can be loaded and saved. Is this possible?

Yes, it is. It can be performed in one of two ways. The first is an XML-based solution, and the second is part of the SQLite database.

Note

The source code for both of the following section can be found in the accompanying source code file of this chapter.

The XML-based solution

In my first book, Xamarin Mobile Application Development for iOS, Packt Publishing, I mentioned a simple, yet effective XML-based solution (it's in Chapter 13, User Preferences if you want to check it out). The issue with anything XML-based is that it will read and write to and from the filesystem. This is not supported in the PCL part of the application, but it is on the platform side.

As with the examples covered...

Summary

User settings and user data are a vital part of any application and the storage. The user needs to be handle it with care. Data persistence is becoming a much bigger topic now than it was a few years back, and while the objective of using a common language across all platforms has meant that it is possible to have a commonality when it comes to creating some form of persistent system, as you have seen in this chapter, it is far from a simple task.

In the next chapter, we will cover all of the aspects that we looked at until now in one application.