I’m trying to write some code against the Live Framework SDK and I was trying to avoid hanging my UI so I figured that what I’d do is to use all the async options within the object model.

So…as a for instance – if I have data backed by 5 MeshObjects on the screen and the user selects 3 of them and presses Delete then I’d want to delete those items and I’d want to do it asynchronously.

However…more than one “in flight” async operation against the current Live Framework object model seems to hit you with a;

“Concurrent Operations are Not Supported”

error so this post is just a word of warning if you encounter this.

It’s tricky for me because I have other instances where I want to display N images on the screen. These are data-bound with WPF and the original intention in the property accessor that supplies the Image was something like this;

public BitmapImage Image
    {
      get
      {
        if (image == null)
        {
          MeshData.GetMediaStreamForPhotoAsync(this,
            s =>
            {
              image = new BitmapImage();
              image.BeginInit();
              image.StreamSource = s;
              image.EndInit();
              FirePropertyChanged("Image");
            });
        }
        return (image);
      }
      set
      {
        image = value;
        FirePropertyChanged("Image");
      }
    }

So, you can see that I lazily load the image asynchronously from the Mesh ( GetMediaStreamForPhotoAsync is my function but I’m sure you get the picture regardless of whether you’ve seen the Live Framework object model or not – note that the callback provided as a lambda above is marshalled back to the Dispatcher thread  ).

This works brilliantly until WPF calls the Image property on object 1, gets a null ( causing an async operation to begin ) and moves on to object 2 where it causes another async operation to begin and the Live Framework object model can’t handle that in its current incarnation.

What to do? I figure that I can either;

1. Work synchronously and hang the UI. Not acceptable! 🙂
2. Work synchronously but put some “background thread”  in place and call all the synchronous functions from that thread, somewhat like BackgroundWorker.

I think I’ll go for 2, pity I’d written such a lot of code before I realised it wouldn’t work 🙂