In Part 1 of this series, we created our Portable Class Library (PCL) project that allows us to access SQLite from different platforms. In Part 2 we added our Windows Store App to the solution. In this post, we will add our Windows Phone App to the Solution. If you want to skip ahead and get the source code, it can be found here.

Adding the Phone App

To add the phone app project, right click on the solution in Solution Explorer and select Add --> New Project. Select Windows Phone and Windows Phone App and click OK.

This will add the phone app project to our solution. Much like our store app project, we need to add our platform specific SQLite assemblies to the Phone project. In the NuGet manager add a reference to SQLite.Net – PCL WindowsPhone8 Platform. This package contains the Windows Phone ISQLitePlatform implementation.

This package will also add a reference to the SQLite.Net PCL assembly and the sqlite-net-wp8 assembly. The sqlite-net-wp8 assembly is a C++/CX wrapper for SQLite functions. This library can be used to interact with sqlite3.dll on the Windows Phone. If you try to build the app at this point, you will probably get a message very much like this:

sqlite-net-wp8 does not work correctly on 'AnyCPU' platform. You need to specify platform (x86 or ARM).

In order to fix this, you will need to change the Platform for the Phone project to x86 if you are going to run this app in the emulator and ARM if you are going to run the app on an actual device.

Now we can add the logic to display our ToDo items from the SQLite database. In my phone app there is already a MainPage.xaml. We'll also add a ToDoItem.xaml. The MainPage.xaml contains a LongListSelector to show all of our ToDo items in descending date order. The ToDoItem.xaml page is used for adding new ToDo items, editing existing ToDo items, and deleting existing ToDo items.

I'm not going to cover all of the logic I used to create the views and how they interact with the code behind, but I am going to cover how we utilize the PCL assembly we created. In the code behind for the MainPage.xaml.cs file we create an instance of our Database class like this:

private Database _database;
 
private async TaskDatabase> GetDatabase()
{
	if (_database == null)
	{
		_database = new Database(new SQLitePlatformWP8(),
			Path.Combine(Path.Combine(ApplicationData.Current.LocalFolder.Path, "todo.sqlite")));
		await _database.Initialize();
	}
 
	return _database;
}

You'll notice that when we create our new Database object we pass in a new instance of SQLitePlatformWP8. This the implementation of the ISQLitePlatform interface for Windows Phone apps that we added from the SQLite.Net – PCL WindowsPhone8 Platform package. Also, we are specifying that the data should be stored in our local App Data folder. We are putting it here because we need the SQLite database to be persistent and local to this device. Then we call the Initialize method, which creates our

ToDo table in the database.

Now that we have an instance of Database

we can use the following logic to perform our CRUD logic. To get a list of ToDo items we do the following:

ToDoList.ItemsSource = await database.GetAllToDos();

To get a single ToDo:

DataContext = await database.GetToDoById(id);

To insert a new ToDo item:

result = await database.AddNewToDo(item);

To update an existing ToDo item:

result = await database.UpdateToDo(item);

To delete an existing ToDo item:

await database.DeleteToDo(item);

If you'll recall from Part 2 of this series, this logic should look exactly the same. In fact it is. The only thing that is different between the applications is what the results are bound to when we are done retrieving them.

We now have all of our logic in place to perform all the necessary operations against our SQLite database from our Windows Phone app. We have just created a cross-platform solution for saving ToDo items in a SQLite database. The only part of the solution that we had to implement in a platform-specific fashion were the views. We could now add a Xamarin iOS implementation, or a Xamarin Android implementation of the same app to this solution and it will work exactly the same way. With this pattern we can reuse much of our code across multiple platforms. The fact that we can reuse so much of our code saves us a lot of time and more importantly money, both from a development and a maintenance perspective. This will also greatly reduce our time to market if we are targeting multiple platforms with our application.