Live Framework updated

The Live Framework got an update to April 2009 CTP. Within this release are new versions of the tools and SDK and the Live Framework Client software.

That’s new (quote):

  • Support for side-by-side installation of the www.mesh.com local client and the developer.mesh-ctp.com local client. This means that you can use the production Mesh.com to sync data across all your devices, and develop applications for the Mesh Developer Sandbox that uses the local client—all on the same machine. For instructions on setting up side-by-side, please see this forum post.
  • Support for Windows 7 and Internet Explorer 8
  • Single installer for the Live Framework SDK and the Live Framework Tools for Microsoft Visual Studio.
  • Resource Scripts are now supported in Silverlight applications and with the local Live Operating Environment
  • Public availability of the SDK and Tools on the Microsoft.com Download Center.
  • Improved stability in the client and the cloud Live Operating Environment.
  • Design and performance improvements to the API toolkits
  • Simplified workflow for setting up an account and a Live Framework project on the Azure Developer Portal.

More information on: http://blogs.msdn.com/liveframework/archive/2009/03/11/live-framework-updated.aspx

Live Framework CTP #8: MeshPhotoShare demo app

During the last few weeks I wrote a little meshified photo sharing application, which I want to share with you now.

It’s named MeshPhotoShare (download Version 0.1 beta 1 from here), it’s written under the use of C# 3.0, .NET 3.5 SP1, Silverlight 2 and the Live Framework CTP January SDK.

MeshPhotoShare allows you to:

  • administrate simple unsorted lists of photos: add new photos, delete old ones and modify title and description of a photo as metadata,
  • run the application from the Live Desktop or locally and offline (if you have the Live Framework Client installed),
  • share the application instance with other users over the app sidebar: those users can see and manipulate the same data as you can,
  • edit your photo collection simultaneously with other users: open the application with them in parallel and see changes that they make immediately on your application instance of MeshPhotoShare.

MeshPhotoSahre makes use of the following Mesh features: a) Media Resource for storing photo files, b) UserData for saving the photo’s metadata, c) hooks ChangeNotificationReceived on the DataEntries collection for simultaneous editing experience.

And that’s what MeshPhotoShare currently looks like:

MeshPhotoShare application

There are some issues in the current version, that mainly come from the current Live Framework release. Thus, the application freezes in Internet Explorer, because of the use of ChangeNotificationReceived. Furthermore when run locally, there may be some strange behavior and sometimes you’ll get some exception messages coming from the Live Framework. I hope that this will be fixed in the future, I will do my best to improve the app as well.

I’m happy about your comments and further discussion, thanks!

Download MeshPhotoShare v0.1 beta 1: http://www.leading-edge-dev.de/stuff/Mesh/MeshPhotoShare_v0.1b1.zip

kick it on DotNetKicks.com

Live Framework CTP #7: data handling possibilities

Just a link to a great forum’s post for today. Rajan Dwivedi answered in very detail on my question about data handling possibilities in the Live Framework. Here’s the link.

In short, you can (mainly) handle your data by using:

  • UserData
  • Attribute Extensions
  • Element Extensions
  • MediaResource
  • SyndicationLink

Read Rajan’s great answer and you will learn more about that. I hope that I’ll find some time to blog about this in the near future, but I can’t promise.

Update of the Live Framework Tools: January CTP

Already on the last Friday (January 31th), the January CTP of the Live Framework Tools for Visual Studio have been released and can be downloaded from here. There are a number of major bug fixes and improvements in this release, including (taken from here):

  • Debugging or running a Mesh-enabled Web Application which contains no changes from previous versions immediately launches the application instead of re-uploading the files.
  • Mesh-enabled Web Applications created by the Live Framework Tools now have identical offers to those created through the Azure Services Developer Portal, which are generally less restrictive.  This change removes the need for the workaround mentioned in this thread.
  • Projects created by the Live Framework Tools may now contain periods fixing the issue reported in this bug.
  • Changes to the application’s logo.png file will now be reflected in the icon that appears on the Live Desktop fixing the issue reported in this thread.
  • Error messages and diagnostics have been improved.  In certain error situations additional information can now be located in the application event log.

Thoughts on the Live Services

After meshing for some days now, I took my 8-miles-running-lap today to think about the Live stack as a whole (I love my runs, it’s the only time to think in-depth on some topics). Thus I want to step back away from the bits and bytes for a moment and review the whole Mesh and Live Services thing. So what does it bring for developers and for consumers? What experiences are changing for them? What is it all about in my eyes? Questions, to which I try to find an answer in this blog post.

What is it about

Let’s start with the general pictures again. From a logical view, the Live Services are just one of the building blocks of the Windows Azure Services platform, as shown in our overall present Windows Azure picture…

Windows Azure Overview

Furthermore, the Live Services are providing some core services on the one hand side and a bunch of Mesh Services on the other. That’s shown by the Live Services overview picture…

Live Services Overview

So we got some core services, we got the mesh and services on it and we got applications today, which are using those services: the Windows Live applications, Office Live and Live Mesh as consumer portion of the mesh and taking advantage of the Mesh Services. At the moment, those applications are relatively distinct from each other in the sense of storage, used APIs and information sharing. For example, with Windows Live comes the 25GB SkyDrive, Office Live has its own workspace and with Live Mesh you get 5GB storage today. Those are not interconnected. But there are big things going on!

From the developer’s view, in the current Live Framework CTP you already take advantage of Windows Live functionality. Thus you are able to access your Live contacts and profiles. Furthermore, you can share data from your mesh with your contacts using various roles. In my opinion, Live Mesh will become part of Windows Live on http://windows.live.com, there earning a central stage. In return, perhaps you will be able to access your calendar, mail and other services programmatically through the Live Framework? We’ll see. Bringing all together is desirable in my eyes.

Ok, let’s continue. So what? What are the core conceptions of the Live Services? For me the whole functionality can be broken down into 2 main points:

Connecting

It’s no secret, what the Live Services and especially the Mesh Services are designed for. They bring together devices, applications, data and people, overcoming traditional barriers between them. The container therefore is the Mesh. In fact there is more than one mesh. You got a mesh of your devices, which share common information. On those devices and in the cloud you can have data and applications, which work with this data or on their own (leading us to the terms of data and application mesh). In a next version of Live Mesh you’ll be able to find applications through an application catalogue and install them on your mesh. Integrating Windows Live applications this way would be nice and I’m interested to see if this will happen soon. And with your contacts you have a mesh of people, with whom you can share your information, your data and even applications.

Thus, connecting means connecting your devices, your data and your applications, but what it really is about and what we can’t see today in Live Mesh (ok, we can see a little of it, but this is only the tip of the iceberg) is the non-egocentric perspective. It’s all about community! About sharing your photos, videos, thoughts and knowledge with your friends and like-minded people. The Live Services foundation is all about this aspect of bringing people together and making „community“ easier and more fun. In the end, it’s bringing YOU with your data/applications/devices/thoughts together with the OTHERS in a way, that doesn’t limit you (in contrast to today’s Web 2.0 platforms, which are bound on one or only a few aspects… or are you using one platform that enables you to organize your digital life with all little aspects through rich applications you wrote or which have been written and shared by others?). For me, Live Services in combination with Mesh are not only services. For me it’s a platform for a huge set of new applications, new business models (putting your favorite ad-engine into your apps is not far away!) and a new way to build up your digital life, using your mesh and the applications that fit your needs. Don’t believe me? I didn’t think so, before I got my iPod Touch (Azure on my head 😉 ) and thousands of apps through the AppStore. Small, cute applications and there is no mesh and no community aspect and no sharing over devices behind (on most). But it makes fun and costs are small. Now I’m mapping this to Silverlight, Mesh, the Live Services and the application catalogue and I see a huge potential!

Synchronizing

The second big functionality aspect when talking about Mesh and the services that come with it is synchronization. This can easily be underestimated, but it implies so much. At first, let me explain this point. As consumer, you currently have the Live Mesh application built onto the Live Services stack. You are able to create folders on your Live Desktop in the cloud and share those folders over your devices. The data is automatically hold in-sync over those devices through the Live Mesh client, which looks for changes and in case of change synchronizes data in the background. That is what you see now.

What you will see in the future, when the application catalogue and applications in your Mesh have come to life: not just data, but the applications in your Mesh will be synchronized to your devices! Thus you not only have your data everywhere, but also the apps, which work with the data, including configuration settings etc.. This leads to offline-scenarios for your mesh applications, if those are relying on data in your mesh (I don’t know if it’s planned to synchronize data of your contacts as well and there are imho some issues with that… we’ll see…). That means you can work offline with your applications and if you come online again, you’ll instantly have your data spread around your devices. I’m agog if there will be an offline-capable version of Windows Live Writer, with which you will be able to write your blog posts offline and then it publishes/synchronizes automatically, when you come online. This would need more integration of Windows Live, but as stated above, this is not far away. Ok, this offline-capability is nice, if you want to do some work where you don’t have Internet (for example in an airplane (standard-example through the PDC and later on ^^), in the train or for me at my parents, because they don’t have Internet (well, they are in fact in stone age and eating with fingers and drawing with chalk on stones etc. … sorry, I’m just joking 😉 )). But while Internet access is widely spread, this has not a heavy impact compared with the synchronization (and everywhere/everytime access for you) itself.

Instead, speed of Internet connection is a important point. For loading big chunks of information from your mesh you need a high-speed connection and even in this case you often have to wait some time, before your data is ready to work with. This drops in case you are working with your mesh data. This data is kept in sync with your computer and thereby you are able to work on your local copy of that data, leading you to instantly accessing that data without downloading it before. If you change the data, the Live Operating Environment (LOE) on your local device notifies these changes and automatically performs the synchronization process to other instances of the LOE (other devices and/or cloud).

Automatic synchronization makes a big difference for the developer, too. Instead of worrying about it, he can rely on this functionality. He can connect to the local LOE and work with the published resources. He doesn’t have to worry about network connections, data retrieval or synchronization – the Live Services are dealing with that. This makes a real difference! Let’s get Azure in mind: the developer can concentrate on the core functionality of his application, thus saving time or spending it to have fun and inspiration while realizing his ideas. Attracting the developer community is in my mind the cornerstone for the success of the Live Services.

What are the benefits

After making clear the core functionality of the Live Services, I want to emphasize (from my point of view) the benefits for consumers as well as for developers, who are programming against the Live Framework.

Consumers

  • Removing barriers: The interface barriers between your devices, data, applications and the people/contacts around you are removed. Thus you are able to interact with those from a central point.
  • Synchronizing: Data and applications everytime and everywhere on your devices! That is what synchronization with your mesh is about. Instead of just synchronizing data, you have the ability to synchronize your mesh applications as well.
  • Offline scenarios: While synchronization of applications is enabled, you can work offline with your applications (in your mesh or only mesh-enabled) which rely on data in your mesh. Instantly when you come online again, the changes will be synchronized automatically to your mesh in the background.
  • Community: Interacting with people, sharing data and taking care of your friends and contacts is made easy with Live Services and Mesh. Have access to your contacts, manage your online profiles and share information, knowledge, multimedia contents and general data as well as applications with your friends, granting them specific rights on your mesh objects. Furthermore, this brings collaboration to life.
  • Applications: Have access to many little applications through your mesh and the central application catalogue. Create instances of those applications on your mesh, synchronize these apps to your machine’s desktops or share them with friends.
  • Manage your digital life: With your data in the mesh and on all of your devices and with applications working on your mesh data, you are able to manage your digital life from a central point. Install applications that fit your needs for every purpose you want and have those applications working on all of your devices. Use services from Windows Live as well and share your life with your friends and families.

Developers

  • Easy programming: Programming with the Live Framework is made easy. You can access your data through central collections and don’t have to worry about common challenging programming tasks. You can query your data resources consistently and have the ability to use LINQ in the .NET libraries. CRUD processes on your data are no problem through a consistent resource model.
  • Consistent access: The Live Framework allows you to consistently access your mesh data, your profiles, contacts and later on other Windows Live services and Live entities with associated relationships.
  • Focusing: Many difficult tasks like network access, authentication, community connection and synchronization are abstracted by the Live Services, Live Framework as programming interface and the Live Operating Environment as a device endpoint for your mesh. Thereby you are able to focus your attention on the important things and the consumer experience of your application.
  • Cloud/client symmetric programming model: It doesn’t matter, which instance of the Live Operating Environment you are accessing. Whether it’s in the cloud or on somebody’s device – you will be able to code against it in a consistent way, thus allowing you easily to realize scenarios of your choice.
  • Business model: You’ll be able to include your favorite ad-engine in your apps to make money with your applications, as those are spread throughout the community.
  • Open access: Access to every instance of the Live Operating Environment (single devices or the cloud) and therefore to your mesh is possible with the programming language and operating system of your choice using a RESTful HTTP interface, that relies on open specifications. You can choose your favorite wire format, too (POX, ATOM, RSS, JSON), because data in the Live Framework is entity/collection-based, has no associated behavior and thereby can easily be transformed into an feed-based model. Furthermore, libraries for many languages will not be far away…
  • Scripting: The Live Operating Environment comes with the ability to compile and run so-called resource scripts. Those are similar to stored procedures in the database world. You can run a resource script on your own or let it run as trigger on data manipulation processes.
  • Mesh-enabling: No matter, if you build up a new application or extend an existing one: making use of mesh-functionality (thus mesh-enabling an application) is no problem and can easily be done with existing libraries.

CTP limitations

While the potential of the Live Services and Live Framework is big in my eyes, there are some limitations with the current Live Framework CTP, which will hopefully be solved in coming releases. The first came up with the installation of the Live Framework client, that is responsible for background synchronization of your mesh objects. At first it was not possible to install the Live Framework client in parallel to an existing Live Mesh client installation. I worked out a solution for that which works well for me, but I don’t know if there are some issues with that. The fact that there’s a separate mesh for the Live Framework instead of using the consumer mesh is a limitation as well, because you cannot access the same data as in your „productive“ mesh.

Another limitation comes with the functionality of the Live Framework client. At the moment, data synchronization is not possible, which means that files and folders from your mesh are not synchronized with devices running the Live Framework client. The same is true for your profiles and contacts, meaning that you have to connect to the cloud LOE to get access for those. Other limitations are, that you can’t get information about the status of a device and no remote access is possible (but this doesn’t count too much).

When programming against the Live Framework CTP, you are currently not able to traverse hierarchical data directly, thus you have to implement it on your own. Further „comfort functionality“ when accessing media resources is missing, too, but that’s no big deal.

Overall, with Live Services, Mesh, Windows Live and the Live Framework the fundamental stones are set for a new platform of rich applications and experiences for both consumers and developers. We’ll see how the community is reacting on this and where the whole thing will be in two years. Until then: what do YOU think?

kick it on DotNetKicks.com

Live Framework CTP #6 – .NET: WinForms Demo application

In the comments of #4, sitary requested the source code of my little WinForms application. After extending it with a login form and a little more functionality, I want to share it with you.

Currently the following things are implemented:

  • Login form for connecting to your cloud LOE.
  • Instant connection without a form, if you fill in your credentials into MyCreds.cs
  • Top-level information about several LOE objects: Devices, News, Mesh objects (TreeView structure), Contacts.
  • Tab „data“, which allows you to show MeshObjects, DataFeeds and DataEntry’s and to create, modify and delete those. If a data entry is a picture, it’s downloaded and shown in a box on the right.
  • Class library, which is extending the LiveFx’s functionality as explained in #5.

Note: It’s just implemented as „playing-around“ application for myself at the moment. That implies: no documentation, no error handling, no good design. If I got time, I’ll put a little work on that. For the moment please note, that this project isn’t reflecting my coding skills very much…

Normally, you just have to open the solution file in Visual Studio 2008. Please make sure that you’ve installed the Live Framework CTP SDK in C:\Program Files\Microsoft SDKs. Otherwise, you have to add a reference to the LiveFx .NET libraries on your own.

Again: Don’t expect too much 🙂

Sourcecode: MeshDiscoverer_current.zip

kick it on DotNetKicks.com

Live Framework CTP #5 – .NET: Data hierarchies and LiveItem types

Hierarchies of data entries – the problem

As stated before, when programming against the Live Framework libraries in .NET, all data entries are located on one level below the according data feed. This very often doesn’t correspond with a programmer’s expectations, when he has a hierarchy of data entries, e.g. a hierarchy of data folders and files. As programmer you want to have a tree-like view on this data to work with it. Unfortunately, in the current LiveFx CTP this was not made possible directly.

Extending DataFeed and DataEntry

The solution for this is not far away. A data entry’s resource has got an Id and a ParentId as properties, over which one can identify and associate an entry’s parent and its child entries. A „root entry“ has got the ParentId "urn:uuid:00000000-0000-0000-0000-000000000000" or it is null. This information is sufficient to write some extension methods on DataFeed and DataEntry for getting hierarchical information. Thus I’m starting to make a little class library, which I will further work on and extend it. First I’ve got a little class named „MeshConstants„. There resides the ParentId for a root data entry:

public static class MeshConstants
{
    public const string RootDataEntryId = "urn:uuid:00000000-0000-0000-0000-000000000000";
}

With this it’s easy to extend DataFeed with a method GetRootDataEntries(), which delivers only the data entries on the top level of the hierarchy:

public static ICollection<DataEntry> GetRootDataEntries(this DataFeed feed)
{
    return (from entry in feed.DataEntries.Entries
            where entry.IsLoaded && entry.IsRootEntry()
            select entry).ToList();
}

This method accesses IsRootEntry() of DataEntry, which is an extension method, too and indicates, if a data entry is on the root level (has no parent) or not:

public static bool IsRootEntry(this DataEntry entry)
{
    if (String.IsNullOrEmpty(entry.Resource.ParentId))
        return true;

    return entry.Resource.ParentId.Equals(MeshConstants.RootDataEntryId);
}

Another extension method for DataEntry gives us the child entries in return:

public static ICollection<DataEntry> GetChildEntries(this DataEntry entry)
{
    return (from child in entry.GetDataFeed().DataEntries.Entries
            where child.Resource.ParentId == entry.Resource.Id
            select child).ToList();
}

This makes use of the method GetDataFeed(), which is needed for getting the data feed, this data entry is associated to. Unfortunately, the .NET libraries of the Live Framework CTP don’t come along with this possibility innately:

public static DataFeed GetDataFeed(this DataEntry entry)
{
    return (from feed in
                (from meshobj in entry.LiveOperatingEnvironment.Mesh.MeshObjects.Entries
                 select meshobj.DataFeeds.Entries).Aggregate((fl1, fl2) => fl1.Union(fl2))
                 where feed.DataEntries.Entries.Contains(entry)
            select feed).Single();
}

Example: traversing the hierarchy

Now we’ve got all together for traversing a hierarchy of data entries recursively. We just need a recursive method, which executes the wanted action for a data entry and then recursively calls itself for all child entries. The following example method builds up a WinForms TreeView structure by adding TreeNode elements recursively:

private void addTreeNodesForChildDataEntries(DataEntry parentEntry, TreeNode parentNode)
{
    foreach (var childEntry in parentEntry.GetChildEntries())
    {
        var childNode = new TreeNode(childEntry.Resource.Title + ": " + childEntry.Resource.Type);
        parentNode.Nodes.Add(childNode);
        addTreeNodesForChildDataEntries(childEntry, childNode);
    }
}

The result is shown below exemplarily:

Live Framework - Recursing TreeView example

Types of LiveItem elements

The resources of MeshObject, DataFeed and DataEntry have an associated Type property, over which you can distinguish different types of objects. Furthermore, Type is a string and thus allows you to define your own application-specific object types. But the Live Framework comes with some standard types by default, where the most important are:

MeshObject.Type:

  • "LiveMeshFolder": Top-level folder, which can contain further (data entry) folders and files.
  • "ApplicationInstance": Instance of an application, which has been installed through the Live Application Catalogue.

DataFeed.Type:

  • "LiveMeshFiles": Indicates the feed as container for file and folder data entries.

DataEntry.Type:

  • "Folder": Data entry is a folder, which can contain further data entries.
  • "File": Data entry is a file, which may contain your data.

Based on that information (and the extension methods above), I’ve written some more extension methods on the several classes to filter the child elements accordingly:

public static class MeshObjectTypes
{
    public const string LiveMeshFolder = "LiveMeshFolder";
    public const string ApplicationInstance = "ApplicationInstance";
}

public static class DataFeedTypes
{
    public const string LiveMeshFiles = "LiveMeshFiles";
}

public static class DataEntryTypes
{
    public static string File = "File";
    public static string Folder = "Folder";
}

public static class MeshExtensions
{
    public static ICollection<MeshObject> GetApplicationInstanceMeshObjects(this Mesh mesh)
    {
        return (from meshobj in mesh.MeshObjects.Entries
                where meshobj.Resource.Type == MeshObjectTypes.ApplicationInstance
                select meshobj).ToList();
    }

    public static ICollection<MeshObject> GetFolderMeshObjects(this Mesh mesh)
    {
        return (from meshobj in mesh.MeshObjects.Entries
                where meshobj.Resource.Type == MeshObjectTypes.LiveMeshFolder
                select meshobj).ToList();
    }
}

public static class MeshObjectExtensions
{
    public static ICollection<DataFeed> GetFilesChildFeeds(this MeshObject meshobj)
    {
        return (from feed in meshobj.DataFeeds.Entries
                where feed.Resource.Type == DataFeedTypes.LiveMeshFiles
                select feed).ToList();
    }
}

public static class DataFeedExtensions
{
    public static ICollection<DataEntry> GetFileDataEntries(this DataFeed feed)
    {
        return feed.GetFileDataEntries(false);
    }

    public static ICollection<DataEntry> GetFolderDataEntries(this DataFeed feed)
    {
        return feed.GetFolderDataEntries(false);
    }

    public static ICollection<DataEntry> GetFileDataEntries(this DataFeed feed, bool onlyRootEntries)
    {
        var entries = onlyRootEntries ? feed.GetRootDataEntries() : feed.DataEntries.Entries;
        return (from entry in entries
                where entry.Resource.Type == DataEntryTypes.File
                select entry).ToList();
    }

    public static ICollection<DataEntry> GetFolderDataEntries(this DataFeed feed, bool onlyRootEntries)
    {
        var entries = onlyRootEntries ? feed.GetRootDataEntries() : feed.DataEntries.Entries;
        return (from entry in entries
                where entry.Resource.Type == DataEntryTypes.Folder
                select entry).ToList();
    }
}

public static class DataEntryExtensions
{
    public static ICollection<DataEntry> GetFileChildEntries(this DataEntry entry)
    {
        return (from child in entry.GetChildEntries()
                where child.Resource.Type == DataEntryTypes.File
                select child).ToList();
    }

    public static ICollection<DataEntry> GetFolderChildEntries(this DataEntry entry)
    {
        return (from child in entry.GetChildEntries()
                where child.Resource.Type == DataEntryTypes.Folder
                select child).ToList();
    }
}

kick it on DotNetKicks.com

Live Framework CTP #4 – .NET: LOE and data basics

Instead of creating new Silverlight applications, which run in your mesh and use the data, you can furthermore mesh-enable your existing .NET applications or create new mesh-enabled .NET applications from scratch. That’s pretty easy and in the following post I will show you some basics…

The Live Operating Environment (LOE)

First there is the Live Operating Environment, being the center point of all your operations to the mesh. With an object of type LiveOperatingEnvironment you can connect to your online mesh or to your local mesh storage sync or async and perform any operation you want. But that’s just the developer’s point of view. In fact, the LOE (every instance of it) is an agent component, responsible for providing an efficient cache and for background synchronization of data on your device to other devices (other instances of the LOE on those devices) in your mesh, including the „special“ LOE in the cloud. Running an LOE means exposing data through a RESTful interface at port 2048 of your machine – one could check the presence of this and either connect locally or to the cloud.

Connecting to your online/cloud LOE means that you have to provide your credentials on connect, whereas you can connect locally without those. I like to work on my local storage, it’s fast and safe. But there are some limitations (at the moment?) there. Due to the lack of file synchronization, files as data entries are not available from the local storage, so you have to connect to your online LOE instead. Furthermore you only get your local device in the Devices collection of your LOE and it’s not possible to have a look at your contacts and profiles for instance. What I expected first or want to have for the „final“ version of the Live Framework: just one connection method, which takes local data if it’s available and instead connects to the cloud LOE. It should be no problem, because the various LOEs (loal, cloud) are taking responsibility over synchronization… or have I forgotten to consider something?

Well, let’s take a look to connecting to your (online) LOE. Just create an instance of LiveOperatingEnvironment and connect via the Connect() method (local LOE: use ConnectLocally() instead). You have to pass your credentials as a parameter, which could come from a secure source or from user input:

var creds = new NetworkCredential("username", "password", "https://user-ctp.windows.net");
var loe = new LiveOperatingEnvironment();

loe.Connect(creds);

https://user-ctp.windows.net is the fixed base URI when connecting to your cloud LOE. After you’ve been connected, you get access to your mesh items (shown before) and can start meshing 🙂

Mesh Objects, Data Feeds and Data Entries

A mesh object is a container for concrete data in your mesh. There are several types of mesh objects and you are allowed to create your own application specific types, which your applications can work with. Mesh objects can be files, folders, applications, custom objects etc.. You have access to the mesh objects via loe.Mesh.MeshObjects.Entries and have the possibililty to easily iterate over them in this way.

Every mesh object consists of DataFeeds, Members, Mappings and News, as stated before. Interesting at this point are the data feeds. Those are further containers for the real data entries. Why this abstraction? Over data feeds you can group your data together, separating logically distinct data. Every DataFeed object finally contains a DataEntries collection, which gives you access to the underlying data and information about that. Note: there is no obvious possibility to store hierarchical data entries at the moment. There is one level of data entries and a data entry can’t contain other data entries. So that’s a drawback at this point and I don’t like/understand it much. The solution for that is: every data entry contains a parent ID and over that you can identify top level data entries and those, who are child entries of another data entry. But that’s not a good solution, isn’t it? Hopefully there will be done some work on that…

Well, a nice little .NET console application would be to show us the titles of all mesh objects, of their data feeds and data entries in there. That’s no problem and leads to the following little program:

var creds = new NetworkCredential("username", "password", "https://user-ctp.windows.net");
var loe = new LiveOperatingEnvironment();
loe.Connect(creds);
if (loe.IsRunning())
{
    foreach (var meshobj in loe.Mesh.MeshObjects.Entries)
    {
        Console.WriteLine("- " + meshobj.Resource.Title);
        foreach (var feed in meshobj.DataFeeds.Entries)
        {
            Console.WriteLine("  + " + feed.Resource.Title);
            foreach (var entry in feed.DataEntries.Entries)
                Console.WriteLine("    * " + entry.Resource.Title);
        }
    }
}
Console.ReadLine();

Create, Update, Delete

The creation, update and delete of all the three entities MeshObject, DataFeed and DataEntry is made really easy. Just call the Add() and Remove() methods of the particular collections. The rest is done automatically by the Live Framework. The update process isn’t problematic, too. Just change your entity and then make sure to call the Update() method of this entity. Because everything in your Live Operating Environment has LiveItem as base type, you have an integrated and consistent CRUD process.

Little example

The following screenshot shows a little WinForms application, that connects to my mesh and over which I can perform the CRUD process on my mesh entities. Further on I can navigate through my mesh and if I got images as data entries, those are downloaded automatically as media resource stream and then shown up at the picture box on the right. In the screen below is shown the (IKEA-powered 😉 ) couch corner of my little apartment…

Live Framework .NET WinForms example application

In upcoming blog posts I want to show you more information about handling data entries, media resources and hierarchical data. So stay tuned 🙂

kick it on DotNetKicks.com

Live Framework CTP #3 – .NET: the developer’s Resource Model

There seems to be a lack of information on the web about the Live Framework Resource Model from a developer’s point of view, that means how can I address my mesh objects and more from my .NET code. Some Blog-Entries describe it more from a user’s standpoint respectively describe what is unveiled through the web services of the Live Operating Environment, but as .NET developer with the LiveFx libraries at hand that’s not interesting me much. Thus I want to briefly describe the resource/data model which you’re programming against in .NET (it has some similarities to the real class diagram) through the following article. Later on, in other posts I will go in depth on some of them.

The following diagram shows many (while not all) aspects of what you as developer should be worried about when juggling with Live Framework objects:

Live Framework Resource Model

First things first: every collection shown above is a LiveItemCollection<TMeshItem, TResource>, where TMeshItem is of type MeshItem and TResource is of type Resource. Normally you get data out of the Resource, which can be extracted from the LiveItem via YourLiveItem.Resource.

Now I want to shortly describe the individual components.

LOE: the Live Operating Environment is the root of all functionality. Here you can connect to your Mesh and get all the information you need (In fact it’s much more than that, but this should be deferred at the moment).

  • Contacts: Collection, which holds your contacts. One contact can contain some profiles and has many relevant contact data (Name, adresses, job title, profession etc.) connected to it.
  • Mesh: Represents your whole mesh and the data, that it contains.
  • Profiles: Respresents your personal profiles. The following kinds of profiles are available: General, AboutYou, ContactInfo, WorkInfo, Interests. Those profiles come from your Windows Live account, so Windows Live is basically integrated with some functions at the moment. I’m sure that there will be more interaction and features including Mesh and Windows Live in the future.

Mesh:

  • Devices: Collection, that represents the different kinds of devices belonging to your mesh. Those are the same devices that are shown on the device ring in your browser. From a device object you can gather information like the online status, if it’s a local device or if it has an active remote connection.
  • MeshObjects: Everything, which can contain data (data feeds) in your mesh. This can be folders (Type: LiveMeshFolder) and applications (Type: ApplicationInstance) for example.
  • News: Collection of NewsItem objects, which represent global news in the mesh. There are several kinds of existing News types: LiveMesh.FileAdd, FolderAdd, MemberAdd, AppInstanceCreate, AppInstanceMemberAdd, UserMessagePost and more. But you’re not limited by these, because you can create news of your own type…

MeshObjects:

  • DataFeeds: Collection of container items for data, that is included in the mesh object. Every data feed can have many data entries.
  • Mappings: Collection, that contains mapping objects. Those indicate the devices this mesh object is mapped to.
  • Members: Individuals, who have permission to this mesh object. There are several role type for mesh object members: Full, Author, Reader, Writer. With those the core Live services and your applications can handle access to mesh objects.
  • News: Every mesh object can have several news, that are related to this object. As the global news, this is a LiveItemCollection of NewsItem objects.

DataFeeds:

  • DataEntries: Data entries are everything that contains data in a data feed. This can be files or folders or user-specific data. A data entry can contain a media resource, with which a file (image, video, audio, word document, …) can be viewed and converted automatically.

These are just some first thoughts and introductionary information about the resource model from a developer’s view. As said before, I will blog later on specific topics of that, going more in depth…

kick it on DotNetKicks.com

Live Framework CTP #2 – Silverlight: Hello Mesh

I recently created my first little mesh applications. And yeah, I like it! One of those was a simple „Hello Mesh“ Silverlight application, only to get familiar with the mesh application creation and deployment process.

Fist I created a new „Silverlight Mesh-enabled Web Application“, which can be chosen through the new „Live Framework“ project type, (comes with the Live Framework Tools for Visual Studio).

New Live Framework Project Type
New Live Framework Project Type
This results in the following project structure:
Silverlight Mesh-enabled Web Application project structure

There is a main application project „MeshApp1“, whose icon indicates that it’s mesh-enabled. Furthermore it contains a page that is hosting the Silverlight application „MeshApp1Silverlight“. I’ve heard that there are some problems, if you want to adopt this project structure to your custom needs. Some people seem to have problems when adding new references and projects, making the Silverlight application not work on a machine’s desktop. I’m sure that Microsoft is working on that, don’t forget we just have a CTP at the moment 😉

In Blend I’m layouting „Hello Mesh“ a little bit, so that my Mesh in the cloud is getting happy when it sees my application. Back in Visual Studio and ready to run, I make a thing which I call F5 deployment, regarding the effect of pressing the F5 key in my solution. So what’s going on? When you press F5 the first time, a dialog is popping up that is showing you some information about deploying your app:

Deployment dialog for a mesh-enabled web application

At present you have to make some handwork on this. With the Live Framework you can create up to 25 projects at the moment, this should be enough for some playground experiences. The dialog is showing you the way: you have to go to your Azure developer center and create a new project. In return you get an application self-link (the URI for the application), which the dialog wants from you. With this, Visual Studio knows where to deploy the application automatically, when you press F5 the next time. My opinion on this is that this kind of handwork could be made a little smarter or more automatic, but remember: you have to make it only once, so it is quite ok for me. 

What I think about this: that is how cloud application development and deployment should look like! Easy development with respect to your existing skills and easy deployment of your applications. Furthermore, with the application’s self-link, Visual Studio is able to debug your applications in the cloud. That’s great! No competitor of Microsoft gives you these possibilities and in my opinion it’s making a big difference and will contribute much to the success of Microsoft’s cloud strategy. Attracting developers is the core of all.

Aehrm, where have I been? Oh yeah… well… when you press F5, your Silverlight application will start in the cloud. The Live Desktop will open up and your Silverlight application will get a shortcut on it. It starts on your Live desktop, showing the overwhelming „Hello Mesh“ result:

Silverlight Mesh Application on the Live Desktop

If you run the „Live Framework Client“, this app automatically creates a shortcut on your machine’s desktop to the MeshApp1 Silverlight application. And in the background, it automatically synchronizes the application to your machine. Now try the following (it works!): disconnect from the Internet, click on the shortcut at your desktop and the application runs! Without connection, on your desktop. This really impresses me and I will try some more complex scenarios later on…  Here’s the local desktop result:

Silverlight Mesh-enabled Web Application on the local desktop

First conclusion: I like/love my first experiences with the Live Framework and that I can use my existing development skills. The deployment process is intuitive and easy and brings my expectations to life. I will go on with some more topics during the next days and weeks.

kick it on DotNetKicks.com