Silverlight - merging detached object back to the attached data context

This is a short post on something that we did in the days of Silverlight 2~3, before we have RIA services.

Consider two method signatures on the service:

  1. public EntityPerson GetPerson(object key);
  2. public void SavePerson(EntityPerson person);

Silverlight gets an EntityPerson object, exposes it via the ViewModel for databinding.  The user hits the save button, and the data is coming back through the wire.

It comes back to SavePerson, but the object is disconnected.

The way we've always done this is this way:

//Update or Insert person:
if (entityPerson.PersonID > 0) //update 
{
    EntityKey key = entities.CreateEntityKey("tblPerson", entityPerson);
    object originalItem;
    if (entities.TryGetObjectByKey(key, out originalItem))
    {
        // merge changes from the client back to the dataset
        entities.ApplyPropertyChanges(key.EntitySetName, entityPerson);
    }
}
else//insert new 
{
    entities.AddObject("tblPerson", entityPerson);
}

ApplyPropertyChanges works very well and takes a lot of the work out of our hands.  You can attach a very simple conflict detection if you have a Timestamp field, and by setting the ConcurrencyMode=Fixed.

Saving Changes and Managing Concurrency
How to: Manage Data Concurrency in the Object Context
Flexible Data Access With LINQ To SQL And The Entity Framework

I was recently involved in a short discussion on this topic, and was intrigued to go digging and get to the bottom of it all.  Hope these links help someone :-)

Silverlight Unit Testing - adding a timeout to EnqueueConditional

Since a lot of Silverlight work is asynchronous in nature, the Silverlight testing framework has many helper functions to essentially do "non blocking wait until something happens"

The curious one to me is EnqueueConditional(Func<bool> conditionalDelegate

This one essentially waits until the condition is true - so you can call a method to populate your view model with data, and then wait until data.Count > 0

But the method has no support for timeout.  It can, and will, hold the unit testing framework in progress forever.

Here's my little tweak to the method.

        public override void EnqueueConditional(Func<bool> conditionalDelegate)
        {
            DispatcherTimer timer = new DispatcherTimer();
            timer.Interval = new TimeSpan(0, 0, 5);
            timer.Tick += delegate
            {
                // remember to stop timer or it'll tick again
                timer.Stop();
                throw new TimeoutException();
            };
            EnqueueCallback(delegate
            {
                timer.Start();
            });
            base.EnqueueConditional(conditionalDelegate);
            EnqueueCallback(delegate
            {
                timer.Stop();
            });
        }

Here's the unit test to go with it

        [TestMethod]
        [TestProperty("TestCategory", "Silverlight")]
        [Asynchronous]
        [ExpectedException(typeof(TimeoutException))]
        public void Test_Timeout()
        {
            EnqueueConditional(delegate
            {
                // return?  never!
                return false;
            });

            EnqueueTestComplete();
        }

And one more tweak in the App.xaml.cs

        private void Application_UnhandledException(object sender, ApplicationUnhandledExceptionEventArgs e)
        {
            if (e.ExceptionObject is TimeoutException)
            {
                e.Handled = true;
                // stop any timeoutexception here or it'll bubble to the DOM
                return;
            }

            ...
        }

Here's the result picture:  Running just slightly over 5 seconds.

image

 

Updated: added a result picture.

Silverlight first asynchronous test run twice

I'm observing a pretty odd behaviour - the first test of my MVVM is running twice.

Exhibit Original code:

 
    [TestMethod, Asynchronous]
public void VMConnectTest() { ViewModel clientVM = CreateVM(); #region connect clientVM.Connect.Execute(null); base.EnqueueConditional(delegate { return clientVM.IsConnected; }); #endregion base.EnqueueTestComplete(); }

I have a break point in CreateVM - and it's firing twice, off the same line.

Changing the code to:

    [TestMethod, Asynchronous] 
public void VMConnectTest() { ViewModel clientVM = null; #region connect base.EnqueueCallback(delegate { clientVM = CreateVM() clientVM.Connect.Execute(null); }); base.EnqueueConditional(delegate { return clientVM.IsConnected; }); #endregion base.EnqueueTestComplete(); }

And now the CreateVM only runs once.

I suspect the Asynchronous test has a bug regarding mixing which thread is suppose to be creating the VM.  In this case, it's running twice.  Throwing everything onto the test stack seems to have fixed this, but makes the code look more complex than usual.

Silverlight Unit Testing Framework - modify/remove Tag Expressions dialog

The default Silverlight Unit Testing framework project has a lovely Tag Expressions welcome dialog that lets you decide (within 5 seconds), whether you want to run a subset.

How do you get rid of it?

image

 

Turns out it's pretty easy:

        private void Application_Startup(object sender, StartupEventArgs e)
        {
            UnitTestSettings settings = UnitTestSystem.CreateDefaultSettings();
            settings.StartRunImmediately = true;
            settings.ShowTagExpressionEditor = false;

            RootVisual = UnitTestSystem.CreateTestPage(settings);
        }

Use UnitTestSystem.CreateDefaultSettings() to get you started quickly, if you create your own UnitTestSettings class you will have to set up your own Test Harness or you'll face this Exception:

 

Test harness was not specified on test harness settings object. If a test harness settings object was passed in, please verify that it contains a reference to a test harness.

Develop and deploy Silverlight + SharePoint 2010 Solutions (part 3 - light it up)

A quick summary of part 2:

  1. How to attach debugger, check network traffic with Fiddler
  2. Do your VIEWFIELDS, FILTER and SORT on the server
  3. LINQ is converted to CAML beneath the hood - but you can avoid CAML…  almost
  4. Trim your service call

Part 3 is all where we Light up SharePoint and take it beyond the browser.  And see why SL + SP is just pure awesome.

 

OUT OF BROWSER

There's one change in Code necessary for Out-of-browser.

        public SharePointChart()
        {
            InitializeComponent();
            sharepointContext = ClientContext.Current;

            if (sharepointContext == null)
            {
                sharepointContext = new ClientContext("http://colt-sp2010/sites/Home/");
            }

            DispatcherTimer timer = new DispatcherTimer();
            timer.Interval = new TimeSpan(0, 0, 5);
            timer.Tick += new EventHandler(timer_Tick);
            timer.Start();
        }

When you are running Out of Browser you don't have a ClientContext.Current.  No worry, we create one by giving it the Site URL.

(NOTE: this will disable our "mock-data" code, since sharepointContext won't be null anymore)

 

image

Tools in VS.NET 2010 has really improved on this front.  Making Silverlight work out of browser is simply just ticking this one check box.

Which is great - because it means I can pack more stuff into my demo :-)

image

I don't actually need to change any Out-of-Browser settings.  But the one to take note is the "Require elevated trust".  Some features of Silverlight will require full trust in OOB.

Anyway, compile the solution again, and XAP-Deploy to SharePoint document library again.

 

image

Right click to install to computer.

image

Run this from the Computer.

 

DEPLOYMENT CONSIDERATIONS

While XAP-document-library-deployment looks awesome in a demo, there are drawbacks that must be taken into consideration:

  1. Do you leave your end-users to manage versions?  Will they copy your SharePoint Silverlight component and deploy it to 20 document libraries, leaving you no way to centrally upgrade them as a single unit?
  2. In many cases, it is much better for developers to build Silverlight + SharePoint solutions as Sandbox Solutions.  You do this by adding a SharePoint project into your VS.NET, and then configure the xap file to be added to SharePoint as a feature module
  3. Finally, if you want to grant Silverlight additional capabilities that involves additional services deployed on the server, you may need to go back to full Farm-Solutions.  I don't see this as a common scenario.

So the summary version:

XAP document library deployment:

Great for IT PRO who doesn't have permissions.
Not great for version control.

 

Sandbox Solutions:

Great for site collection administrators.
Centralized deployment and good version control capabilities.

 

Farm Solutions:

Useful if you need to deploy server-side stuff, like an extra WCF service.
Build to target Sandbox.

 

SILVERLIGHT INIT-PARAMS

A question in the question time:  Can parameters be specified for Silverlight so that I don't have to hard-code the list internal name.

Yes it can:

Silverlight has a property initParam (think of void Main(string[] args))

The way you access it in code is during the Silverlight app startup.

image

In the application startup event - read the initialization parameters.

image

SharePoint web part configuration lets end-users specify the InitParams in this settings box.

 

This concludes the 3-part Silverlight + SharePoint solutions blog-series.  Let me know what you guys think and if I've made any blunders in the blog.

 

FUTURE IDEAS

A quick brain dump of the future of Silverlight + SharePoint

Silverlight Features

  • Local storage
  • Access Groove as offline storage
  • Camera or mic
  • Local event notification
  • COM access

SharePoint + Silverlight Features

  • "SharePoint-Repair" Silverlight tools
  • Dynamic Language Runtime + SharePoint <- this is going to be super awesome
  • Adding additional farm services

Development (unfortunately not written yet)

  • Full Sandbox Solutions demo
  • Full REST interface demo
  • Full old-WCF services demo