SQLite Database Programming for Xamarin: Cross-platform C# database development for iOS and Android using SQLite.XM

About this book

Conventions used in this book

The following typographical conventions are used.

Fixed width: Used for code listings, including SQL statements. Also used inside paragraphs when referring to program elements such as function names, variable names, environment settings, and keywords.

Bold: Is used (sparingly) to highlight or emphasize some important point or to enhance readability.

Fixed width italic: Used to show text that is to be replaced with user supplied values.

An example code listing is shown below.

public void executeQuery (string command, ArrayList parameterValues)

  {

try

    {

if (command == null)

throw new Exception (ErrorMessages.error [missingSQL]);

if (connCommand == null)

          connCommand = dbConn.CreateCommand ();

else

          releaseDataReader();

1     connCommand.CommandText = command;

connCommand.CommandType = System.Data.CommandType.Text;

2     addCommandParameters (parameterValues);

3     connDataReader = connCommand.ExecuteReader ();

    }

catch (System.Exception ex) 

    {

      logger.log (ex, System.Reflection.MethodBase.GetCurrentMethod ().ToString ());

    }

 }

Code listings are shown with the default color coding used by Xamarin Studio at the time of writing. Paragraphs that explain listings will reference line numbers that are shown in the left column of the listing. Referencing line numbers do not necessarily start on the first line of code. Code listings are mostly devoid of basic error checking, error processing, rudimentary optimizations or anything else that might increase their length or otherwise detract from their primary purpose.

Code formatting

I’ve worked hard to make the code examples as easy to read as possible. Most are very short, so that helps a lot. Unfortunately, the myriad of screen sizes and devices for eBooks makes formatting uncertain at best. Code that displays nicely for one configuration may prove unreadable for others.

It has been my experience that reading this book from a tablet in landscape orientation provides the best view. If you find the code examples difficult to follow due to formatting, you can try changing the font size to see if that helps. Often times, this is enough to set things right.

Who this book is for

This book is designed to be read by mobile app developers that are using or intend to use the Xamarin framework and want to learn how to use the SQLite.XM library. In order to get the most out of this book, you’ll need a basic understanding of C# and have at least some general knowledge of SQL. There is no complex SQL or C# in this book, so a basic understanding of each is sufficient to get you through. Of course, the more you know the better. If you’re a Java developer, you should have no problem with the C# examples. Having a basic understanding of Android or iOS development concepts will also be helpful. Again, there isn’t any complex Android or iOS employed by any of the sample code. For the most part, it’s pretty simple stuff. I try and stay on point and focused on SQLite, SQLite.XM and the best database practices for mobile development.

How to use this book

This book is intended to be more than a simple guide to using SQLite.XM. I try and give advice and make suggestions, and, where appropriate, provide you with a rational for making certain engineering choices. Every project is different, and the choices you make may very well differ from my advice. My hope is that by providing insight into my thinking, I will help you with questioning your own decisions. Sometimes you’ll agree with my advice and suggestions and other times you won’t. Either way, it doesn’t really matter, so long as I promote critical thinking in weighing your own design options, I will have done my job. There is rarely one right way when it comes to coding.

In Part 1 of this book, I spend some time talking in general terms about data persistence along with issues specific to mobile app development. I also spend a bit of time going over the various technologies used in the book to build our data persistence layer. I then go on to discuss database design and challenges specific to designing for mobile apps.

Part 2 is dedicated to explaining how to use SQLite.XM for data persistence on the device. This is the heart of the book. If you have some experience with mobile app development, and know a bit about relational database design, you may choose to skip Part 1 and jump to this section to get right into the specifics of SQLite.XM. If you do decide to skip ahead, be sure to first read the section ‘Platform specific code’ as it has some instructions that you need to be aware of.

Part 3 is where I explain SQLite.XM and cloud replication; how to set up a server-side database and how to get data moved, or copied, from the device to your cloud server. If you don’t need to replicate to a server, you can skip this section.

About the author

I have been a professional software developer since 1986 doing work at IBM, The Nuclear Regulatory Commission, for Bell Laboratories and at a host of smaller firms, including the startup Sezme. I have had the opportunity to work a broad spectrum of computing, from low level embedded systems development in assembler to JVM and .net CLR virtual machine programming in Java and C#. I even had the opportunity to dabble in microcode for a brief period of time. My early career was focused on computer graphics, including OpenGL, digital image processing, and image compression. I developed a proprietary spatial domain compression algorithm intended to be used where traditional cosine transforms proved computationally too expensive. A bit later I was the lead developer for SPG in the creation of the image editor ColorWorks, which was delivered on the OS/2 and Windows platforms. ColorWorks was one of NASAs favored tools for color correcting/enhancing images taken with the Hubble telescope. I later focused my attention on database and Web work for the creation of HotRiot. HotRiot is an SaaS that provides back-end services for mobile and Web applications. I am currently the technical lead in the development of a mobile messaging app for Android and iOS using Xamarin and SignalR.

Personal note

This is my first foray into publishing. I opted to self-publish because I wanted to provide detailed subject matter coverage beyond what is possible in a blog or other shorter venue, but still offer my writing free of charge. This would not have been possible with a publisher. I have been asked a number of times; why free?  It’s true that writing a book, even a shorter one such as this, take a considerable amount of time and energy. Not to mention the work put in by proof readers and tech reviewers. I was surprised by how hard it was to get to a first revision. I have a new appreciation for what authors go through in getting their works published. But I wanted to contribute back into the tech community. Over the years, I have benefited from countless resources made available by others; including blogs, programming help, and open source code. This was an opportunity for me to make a contribution back. If this book is well received, I will follow-up with another. I have learned a lot about mobile messaging with SignalR that I would like to share. If I publish again, I will try to continue to offer my books for free. Thanks for choosing to read this book and I hope you learn and enjoy.

Feedback

If you have any feedback related to this book, for example, errors, suggestions etc., please let me know. I will continuously update the online manuscript as I make edits, this should improve the experience for future readers. Your help with this is greatly appreciated. I’m always happy to assist with SQLite.XM. If you need some help or advice or need something clarified, please drop me a line I’ll do my best to help.

[email protected]

Part 1. Data persistence for mobile apps

The nature of mobile applications

In traditional client-server computing, a client normally connects to a central database server, often through a front-end proxy, for data storage/processing services. If that connection cannot be established, the application is normally unable to run. For the most part, this is okay. The way these applications are designed, packaged, and distributed, this makes sense. This traditional model relies on a continuous connection to a middle tier. For the type of tasks these applications perform, this is all well enough and it helps to simplify their design. Think of any Web based application of significance or any typical enterprise application. It’s true that HTML 5 offers a number of offline storage options, but these are not widely used. The storage technologies that are available are somewhat limited in their capabilities and browser support is non-uniform. Having to deal with the myriad of browser combinations is enough to dissuade most developers from using one of the structured storage solutions offered in HTML.

For mobile applications, a more flexible model is needed. First, network connectivity for mobile devices is much less certain. Not only do connections go in-and-out with much greater frequency, their quality and speed can vary greatly. So, relying on an external database can be sketchy. Also, the type of tasks that mobile apps are called on to perform, along with user expectations, require that they have much more autonomy than their Web or enterprise counterparts. Users will not tolerate spotty service from their mobile apps. With this in mind, mobile applications should be designed to operate without a network connection to the fullest extent possible. This will almost always require some kind of structured data storage solution on the device. Fortunately, a database infrastructure is present on the most popular mobile operating systems. Both iOS and Android ship with a relational database pre-installed: SQLite.

SQLite

SQLite is the most widely deployed relational database in the world, by far. It is included in virtually every iOS and Android device. If you count the number of active devices as measured by Google and Apple, this adds up to several billion. No other database comes close.

Unless the data storage requirements for your app are extremely simple, you’re going to need a storage solution beyond what you can easily implement yourself in a simple key/value structure or basic properties file. SQLite is a very attractive option as there’s no setup required for iOS or Android and its presence is guaranteed on both OS’. This simplifies packaging, deployment and installation for your app, removing any friction that might be caused by installing and managing a separate, embedded database server. Also, knowing that SQLite will be available, allows you to write a common, shared data persistence layer that will work across platforms when using Xamarin. While it is unfortunate that Microsoft doesn’t include SQLite as part of Windows Phone, it is, nonetheless, easy enough to install using NuGet.

Now, you might get the sense that I’m enthusiastic about SQLite simply because it’s convenient. While it is convenient to use, SQLite qualifies as full featured relational database, putting all of the power of a traditional transactional database engine at the disposal of your app. You would be hard pressed to find a better datastore for your mobile application.

I’m not going to go into detail about SQLite beyond what is needed to use our persistence layer, SQLite.XM. However, I encourage you to explore SQLite in more detail. Their website, sqlite.org, has a wealth of information.

Offline, online, and occasionally connected apps

Mobile applications generally follow one of three models:

Pure Offline Application

Pure Online Application

Occasionally Connected Application (OCA)

Pure offline applications don’t require any network connectivity in order to operate. The datastore is local on the device and all data and application logic resides locally. Data that’s generated by the application is not synched with an external or back-end server. These type of mobile application are entirely self-contained and self-supported, and are a bit rare. It is somewhat unusual to see pure offline mobile applications.

In contrast, pure online applications require a network connection in order to function. These apps may include a local database, but this is not a requirement. Even if a local datastore is used, it’s generally limited to such things as configuration information or other metadata. These apps establish regular or continuous communications with a remote server that may, in addition to providing database services, also provide supporting application logic.

An Occasionally Connected Application (OCA) represents a middle ground between the offline and online model. These apps can operate for extended periods without a network connection but eventually need connectivity in order to complete their processing cycle. They almost always include a local database and normally synch their local data with a back-end server. Even though these apps synch their local data, OCAs don’t rely on a remote datastore in order to function. These types of apps are designed to provide a base level of functionality when disconnected with full functionality made available when connectivity is established. OCAs may also rely on a back-end server for supporting application logic. Of the three models, OCA is the most flexible and complex to design and code.

With respect to which of the three models you should choose, the answer is easy if your application truly qualifies as an offline app. In this case, simply use the offline model. This is the easiest of the three to develop and there is little benefit to complicating things. Consider yourself lucky, you don’t need to deal with intermittent connectivity issues, remote communications, synching or any of a host of problems that come along with client server computing.

Unfortunately, it is much more likely that you’re creating an app that follows the online or OCA model. In this case, things can get a bit murky. In most instances, an online mobile application can be designed as