In this second part of this series, let’s talk about the application definition files storage. As I mentioned in the introduction of this series, what a better way to store the application definitions, then the great Sterling database library.
It is pretty easy to setup the Sterling database:
- Create an instance of the Sterling Engine
- Activate the engine
- And register the application database with its table(s)
Then using the database it is also pretty easy:
- Query the database and load your objects using the LazyValue for loading
- Save your objects by using the Save and Flush methods.
I don’t want to go into the details of the Sterling database usage because Jeremy Likness, Jesse Liberty and some other people already explained that. What I’m going to talk is about the issues I’ve found when using it and how to work around them.
There is some issue on how the Sterling database handles the data types caching to speed up the load and saving of your application objects, but this issue may not be visible to most of the Windows Phone 7 applications using Sterling. Let me explain this:
InputStudio applications can have data entities with different attribute data types.
From the previous image examples:
- The Bank Accounts Management application has the Transaction data entity made up from decimal, datetime, integer, string and listofstring data types.
- The Northwind application has the Products data entity made up by the same data types as the Transaction data entity plus the image data type.
From the previous two application examples; even when all applications share the same data type as the base class for all data entities which is registered as the TableDefinition data type in Sterling; the actual object instances of these two applications contain different data types in its attributes. This causes a runtime exception in Sterling saying “Index out of range” when switching between applications while executing each of the sample applications.
The solution to this issue was to manually add all possible serializable types of my application to the _typeMaster list in the PathProvider.cs class of Sterling
and comment out the _typeMaster.Clear() call to avoid clearing the manually added types and also check if the type is not in the list when adding the available types; all of this in the _InitializeTypes() method.
Another issue with Sterling was when trying to use Background workers to load asynchronously the application objects and this objects contained the WriteableBitmap type; this because the WriteableBitmap can only be created in the UI thread. The solution was once again, change a little bit of code when adding the WriteableBitmap type to the _serializers dictionary in the constructor of the ExtendedSerializer.cs class.
After this small fixes, Sterling and the app worked just smooth without any issue at all.
Well my friends, this was Sterling for storage handling, lets see what SQL-CE for Mango has for us…