Runtime

If you remember the last time I talked about Windows 7 Slate development, I mentioned that plain-old .NET WinForms are actually a great choice.  Since every copy of Windows 7 includes .NET 3.51 as part of the image, you might consider targeting that runtime or C++ for friction-free deployment and best performance if it gives you the functionality you’re looking for.  Performance-tuned, Xaml-based apps are also an option as long as you’re not targeting Tablets with low-end CPUs and poor-performing, integrated graphics.  The same advice goes for HTML5 as long as you’re running IE9.

Immersive

Creating an immersive app that takes over the entire screen is step one.  This means that when you design your WinForms in Visual Studio, set them to be Maximized and get rid of the Control Box, Minimize/Maximize buttons, and the Border.

In the Spash Screen below, you can see it completely takes up the entire screen of the Tablet:

UI Element Size

Since some people have been known to have fingers as large as 80 pixels wide, you can no longer get by with the default sizes of UI elements when you drag them from the toolbox.  You need to increase the size of UI elements to be 40+ pixels wide/high as appropriate to users a large hit target for their fingers.

In the Login Screen below, you can see a giant power button icon in the upper-right side as well as a large User selection combo box, Password text box and Login button:

UI Element Spacing

Besides making UI elements larger, you also need to make them farther apart.  I know this flies in the face of you desire to cram as many things on a screen as possible.  Each screen should provide just a single function or idea so keep it simple, uncluttered, and elegant.  The term “fat finger” exists for a reason.  In order to prevent accidentally tapping on the wrong button, space all UI elements at least 20+ pixels apart.

In the Reservations Screen below, you can see a date picker, combo boxes, a button, and check boxes that are easy to touch and give each other breathing room:

Go Big!

Get accustomed to making everything bigger because the presentation paradigm for a Tablet is fundamentally different.  You don’t have the precision of a mouse to click on small hit targets.  You should also pump up the size of things you don’t touch, like the font of text on a screen so it’s clearly visible to the user from any angle.  Large, beautiful, typography as well as iconography is a good thing.

In the Schedule Screen below, you can see a large grid with big cells and text with large font.  The screen title is big and so is the arrow icon used to close and return to the previous screen.

One More Thing

In the touch-first world of mobile devices, you can never assume the use of a keyboard.  That’s why it’s important not to throw lots of empty text boxes at users to fill in.  It’s cumbersome and slow and a user may choose to not use your app.  Give users finger-friendly choices via UI elements like radio buttons, combo boxes and checkboxes where possible.

Now go start building those Touch-First UIs for today’s Windows 7 Slates!

Rob

One way to ensure fast, seamless downloads of your apps is to not take dependencies on large runtimes, installation media, or plugins that may not already be installed on Windows 7 by default.  Silverlight isn’t a big deal because the plugin is very small and should download and install quickly along with your app.  If you’re delivering an app that requires all the power of .NET though, you might consider using version 3.51 since it’s part of the Windows 7 OS image.

Don’t flame me for not recommending .NET 4.0, I use it all the time.  That being said, if the requirments of your WinForm app are met by the features and base class libraries found in .NET 3.51, then don’t unnecessarily take dependency on 4.  Your app will download, install and run without any extra steps.  This is not unlike how most Windows Mobile enterprise customers over the last decade targeted the version of the .NET Compact Framework found in ROM instead of taking advantage of the extra features found in version 3.5.  It frustrated me for a while, but I finally got it.

The Consumerization of IT must drive new behaviors by corporations.  Speed and simplicity of app deployment to employees is one of those behaviors.

Keep Coding,

Rob

In this case, each ObservableCollection represents a table, each object represents a row, and each object property represents a column.  I had you create a Singleton class to hold all these objects in memory to serve as the database.  The fact that Silverlight supports Language Integrated Query (LINQ) means that you can use SQL-like statements to work with the multiple, ObservableCollections of objects. 

If you’re wondering why I have you cache everything in memory in a Singleton, there’s a few reasons.  For starters, it makes it easy to query everything with LINQ with the fastest performance possible for single and multi-table JOINs.  Secondly, I don’t represent a Microsoft product group and therefore wouldn’t engineer an unsupported provider that can query subsets of serialized data from files residing in Isolated Storage.  Finally, I don’t want you to accidentally find yourself with multiple instances of the same ObservableCollection when pulling data down from Azure or loading it from Isolated Storage.  Forcing everything into a Singleton prevents you wasting memory or updating objects in the wrong instance of an ObservableCollection.  An inconsistent database is not a good thing.  Don’t worry, you can control which tables are loaded into memory.

So what is this article all about and what are the “improvements” I’m talking about?

This time around, I’m going to focus on saving, loading and deleting the serialized ObservableCollections from Isolated Storage.  In that last article, I showed you how to serialize/de-serialize the ObservableCollections to and from Isolated Storage using the XmlSerializer.  This made it easy for you to save each table to its own XML file which sounds pretty cool.

So what’s wrong with this?

Saving anything as XML means that you’re using the largest, most verbose form of serialization.  After hearing me preach about the virtues of doing SOA with WCF REST + JSON, using the XmlSerializer probably seems out of place.  Luckily, the DataContractJsonSerializer supported by Silverlight on Windows Phone 7 gives you the most efficient wire protocol for data-in-transit can also be used to save those same .NET objects to Isolated Storage.  So the first improvement in this article comes from shrinking the size of the tables and improving the efficiency of the serialization/de-serializing operations to Isolated Storage using out-of-the-box functionality. 

While going from XML to JSON for your serializing might be good enough, there’s another improvement in the way you write the code that will make this much easier to implement for your own projects.  A look back to the previous article reveals a tight coupling between the tables that needed to be saved/loaded and the code needed to make that happen.  This meant that you would have to create a SaveTable and LoadTable method for each table that you wanted to retrieve from Azure.  The new code you’re about to see is generic and allows you to use a single SaveTable and LoadTable method even if you decide to download 100 tables.

Enough talk already, let’s see some code.  Launch your ContosoCloud solution in Visual Studio and open Database.cs.  I want you to overwrite the existing code with the code shown below:

using System;
using System.Net;
using System.Windows;
using System.Collections.Generic;
using System.Collections.ObjectModel;
using System.IO.IsolatedStorage;
using System.Runtime.Serialization.Json;

namespace ContosoPhone
{
    sealed class Database
    {
        //Declare Instance
        private static readonly Database instance = new Database();

        //Private Constructor
        private Database() { }

        //The entry point into this Database
        public static Database Instance
        {
            get
            {
                return instance;
            }
        }

        //Serialize ObservableCollection to JSON in Isolated Storage
        public void SaveTable<T>(T tableToSave, string tableName)
        {
            if (tableToSave != null)
            {
                using (IsolatedStorageFile store = IsolatedStorageFile.GetUserStoreForApplication())
                {
                    using (IsolatedStorageFileStream stream = store.CreateFile(tableName + ".txt"))
                    {
                        DataContractJsonSerializer serializer = new DataContractJsonSerializer(typeof(T));
                        serializer.WriteObject(stream, tableToSave);
                    }
                }
            }
            else
            {
                throw new Exception("Table is empty");
            }
        }

        //Deserialize ObservableCollection from JSON in Isolated Storage
        public T LoadTable<T>(T tableToLoad, string tableName)
        {
            using (IsolatedStorageFile store = IsolatedStorageFile.GetUserStoreForApplication())
            {
                if (store.FileExists(tableName + ".txt"))
                {
                    using (IsolatedStorageFileStream stream = store.OpenFile(tableName + ".txt", System.IO.FileMode.Open))
                    {
                        DataContractJsonSerializer serializer = new DataContractJsonSerializer(typeof(T));
                        return (T)serializer.ReadObject(stream);
                    }
                }
                else
                {
                    throw new Exception("Table not found");
                }
            }
        }

        //Delete ObservableCollection from Isolated Storage
        public void DropTable(string tableName)
        {
            using (IsolatedStorageFile store = IsolatedStorageFile.GetUserStoreForApplication())
            {
                if (store.FileExists(tableName + ".txt"))
                {
                    store.DeleteFile(tableName + ".txt");
                }
                else
                {
                    throw new Exception("Table not found");
                }
            }
        }

       
        //Declare Private Table Variables
        private ObservableCollection<Customer> customerTable = null;

        //Customer Table
        public ObservableCollection<Customer> Customers
        {
            get { return customerTable; }
            set { customerTable = value; }
        }
    }
}

Looking from top to bottom, the first change you’ll notice is the new SaveTable method where you pass in the desired ObservableCollection and table name in order to serialize it as JSON using the DataContractJsonSerializer.  The next method down the list is LoadTable where you pass in the same parameters as SaveTable but you get back a de-serialized ObservableCollection.  The last new method in the Database Singleton is DropTable which simply deletes the serialized table from Isolated Storage if you don’t need it anymore.

So how do you call this code?

Bring up MainPage.xaml.cs, and find the click event for Save button.  Delete the existing XmlSerializer code and replace it with the following:

try
{
    Database.Instance.SaveTable<ObservableCollection<Customer>>(Database.Instance.Customers, "Customers");
}
catch (Exception ex)
{
    MessageBox.Show(ex.Message);
}

The code above shows you how to call the SaveTable method in the Singleton with the appropriate syntax to pass in the ObservableCollection type as well as actual ObservableCollection value and name.

Now find the click event for the Load button, delete the existing code and paste in the following:

try
{
    Database.Instance.Customers = Database.Instance.LoadTable<ObservableCollection<Customer>>(Database.Instance.Customers, "Customers");
}
catch (Exception ex)
{
    MessageBox.Show(ex.Message);
}

This code looks pretty much the same as the SaveTable code except that you set Database.Instance.Customers equal to the return value from the method.  For completeness sake, drop another button on MainPage.xaml and call it Drop.  In its click event, paste in the following code:

try
{
    Database.Instance.DropTable("Customers");
}
catch (Exception ex)
{
    MessageBox.Show(ex.Message);
}

For this code, just pass in the name of the table you want to delete from Isolated Storage and it’s gone.

It’s time to hit F5 so you can see how things behave.

When your app comes to life in the emulator, I want you to exercise the system by Getting, Adding, Updating and Deleting Customers.  In between, I want you to tap the Save button, close the app, reload the app and tap the Load button and then View Customers to ensure you’re seeing the list of Customers you expect.  Keep in mind that when you Save, you overwrite the previously saved table.  Likewise, when you Load, you overwrite the current in-memory ObservableCollection.  Additionally, Saving, Loading, and Dropping tables that don’t exist should throw an appropriate error message.

So what’s the big takeaway for these tweaks I’ve made to the in-memory database?

While switching serialization from XML to JSON is a great improvement in size and efficiency, I truly believe that making the SaveTable and LoadTable methods generic and reusable will boost developer productivity.  The new ease with which you can Save and Load 1, 10 or even 1,000 tables makes this more attractive to mobile developers that need to work with local data.

So where do we go from here?

You now have some of the basic elements of a database on Windows Phone 7.  You don’t have ACID support, indexes, stored procedures or triggers but you have a foundation to build on.  So what should be built next? 

To help ensure database consistency, I would add an AutoFlush feature next.  SQL Server Compact flushes its data to disk every 10 seconds and there’s nothing to prevent you from using the SaveTable method to do the same.  A timer set to fire at a user-specified interval that iterates through all the ObservableCollections and saves them will help keep your data safe from battery loss and unforeseen system failures.  The fact that your app can be tombstoned at any moment when a user taps the Back button makes an AutoFlush feature even more important.

Anything else?

At the beginning of this article I mentioned RDA which is a simple form of data synchronization.  It’s simple because it only tracks changes on the client but not the server.  To find out what’s new or changed on the server, RDA requires local tables on the device to be dropped and then re-downloaded from SQL Server.  With the system I’ve built and described throughout this series of articles, we already have this brute force functionality.  So what’s missing is client-side change tracking.  To do this, I would need to add code that fires during INSERTS, UPDATES, and DELETES and then writes the appropriate information to local tracking tables.  To push those changes back to SQL Azure, appropriate code would need to call WCF REST + JSON Services that execute DML code on Windows Azure.

I hope with the improvements I’ve made to the in-memory database in this article, you’ll feel even more empowered to build occasionally-connected Windows Phone 7 solutions for consumers and the enterprise.

Keep coding!

-Rob

With the tidal wave of mobile and wireless technologies sweeping across both the consumer and enterprise landscapes, I believe MEAP offerings give us a glimpse of a new standard for designing all future infrastructures.

-Rob