Live Mesh Tutorial 2 - Working with Feeds and Entries

In the previous tutorial on Live Mesh , I took a brief look at the process of creating your first Mesh-enabled Web Application using Silverlight. It was a pretty quick tutorial, but the goal was really to whet your appetite for more in-depth Mesh programming.

So now you've got your Hello World application running and you're continually amazed by how cool it is that you've got a Silverlight application that can run from a Mac, Windows, Windows Mobile, and from the Web - and even runs in a way that makes it look like a full-on desktop application. What next?

Next you're going to need to store data in your Mesh application. You've got a couple options here, each with their own very clear purpose:

• Isolated Storage - If you use Isolated Storage, then you will be storing data local to a very specific instance of your application. In fact, it is so specific that I believe you will not be able to share this data between the desktop-launched and web-launched versions of your application because Isolated Storage is domain-silo'd by design and for security purposes. The only reason you would use Isolated Storage with a Mesh application is if you had a very specific reason to store instance-local data that is never synchronized. I've yet to see a use case for this, but I'm not ruling out the possibility.
• Central Storage via Azure - You could either use Azure Storage (remember, this is the Queues, Blobs, and Tables storage) or you could use SQL Data Services. Azure's low-level storage is designed for people who need to store and retrieve data, whereas SQL Data Services maintains things like foreign keys and increases the complexity of maintenance along with the complexity of features. Regardless of whether you choose low-level cloud storage or high-level RDBMS-like cloud storage, choosing cloud storage for your app means that no matter how a person got your app into their Mesh, every user of your application will be sharing the same exact data store. This is a perfectly valid use case and has a lot of potential if you need to distribute an application with a singleton data store.
• Synchronized Storage - If you use native features within Live Mesh such as Feeds and Entries (discussed shortly), then you will be able to take advantage of synchronization features as well as automatically inheriting all of the security, isolation, and social graph features that come with Live Mesh. If you want to build an application that shares data among the people that are using it in a given mesh/social graph, then this is the data storage method for you (and also the one I will spend the most blog entries talking about).
• Sync / Global Hybrid - This is a really interesting possibility that I think is underrated. You could take advantage of the ease of distribution that you get with Live Mesh, and also take advantage of the secured data synchronization you get with Feeds and Entries... but in addition to that, all of the multiple mesh instances of your application could also be accessing a global data store that is shared by every single user of your application, regardless of their mesh membership. There are some fascinating possibilities here and I can't wait to see what people come up with in this space.

Working with Feeds and Entries

One of the most important concepts that a Mesh developer needs to learn is that everything in the Mesh is made up of Data Feeds and Data Entries. You can think of these as RSS feeds and entries within RSS feeds (because they actually ARE news feeds, and can be represented as RSS!). The way Mesh works is it uses a bi-directional news feed synchronization technology called FeedSync to deal with the synchronization of data across multiple devices and applications within your Mesh. In terms of data modeling you can think of a Feed as a collection or a container and an entry as a single piece of data.

Important note: You can attach your own serializable user data object instance to any entry. This allows you to extend the stock news feed model with your own domain-specific data. You can use this feature to extend the resource model to your application, allowing you to store all of your application data in the mesh. Also worth remembering is that the user data attached to entries does NOT have to be the same. Every entry can have its own entirely different user data schema - entries within the same feed need NOT have the same user data type. This can be very powerful, but can also be easily abused.

Before you can manipulate feeds and entries, you need a reference to the Mesh application service, which you can obtain with an extension method provided for Silverlight:

MeshApplicationService mesh = Application.Current.GetMeshApplicationService();

Now that you've got your mesh, you can create a new feed as follows:

DataFeed newFeed = new DataFeed("Cars");
newFeed.Resource.Type = "CarsFeed";
mesh.Feeds.Add(newFeed);

You have the ability to set an arbitrary string as the resource type on the feed. This gives you a way of querying for particular feeds that you want and embedding logic into your application that can give you some heuristics on how to deal with feeds.

And add an entry to that new feed:

DataEntry newEntry = new DataEntry("Aston Martin DBV");
newEntry.Resource.Type  = "Car";
newFeed.Entries.Add(ref newEntry);
 

And finally, if you want to set custom resource information:

CarInfo carInfo = new CarInfo()
{
    TotalMiles = 42660,
    SalePrice = 93100,
    Owner = "Kevin",
};
newEntry.Resource.SetUserData<CarInfo>(carInfo);
newEntry.Update();

I'll be posting more in-depth samples of dealing with data in Live Mesh applications, but this should give you a little bit of an idea of how you can pass around data among instances of your application within a secure, private Mesh without having to worry about the details of how that data gets transmitted - you just worry about what your data looks like and how you want to store that as feeds and entries, and the rest is taken care of for you.

tags: mesh  livemesh  azure  microsoft  cloud  datafeeds  dataentries  

links: digg this    del.icio.us    technorati    reddit