2014 – make it the year of the cloud!

This post is in response to a discussion I had with some folk over the festive period.  We were talking about using cloud for preforming computation normally carried out on the desktop.  I will share it:

The cloud isn’t just for “big data” problems (it certainly is great for solving such problems).  But you shouldn’t think the cloud isn’t for you because you have an average data problem. The cloud also isn’t just for huge scale; it is just as good if you have a smaller scale requirement.  It is really interesting to talk about how your solution can scale to thousands cores and process terabytes of data with a map reduce query.  It gets a lot of press.  However, we need to be mindful that there are smaller use cases that benefit just as well from the flexibility of cloud computing.

My experience for the past few years has been building a grid compute platform in Windows Azure.   The most important thing I’ve learned about the value of cloud computing is flexibility!  The flexibility in having the choice to use 100 cores or 10,000 cores is in the end users hands.  Hardware is being unlocked from the dungeon of cooperate IT departments and it is liberating.  But there are other side affects it had on our development team.  We had no physical servers whatsoever.  We used Azure for build, development and test environments.  We used cloud services for email (Office 365), file sharing (Dropbox), source control (GitHub), password management (LastPass), Kanban board (Trello) and much more.

I think that if a business makes a small step into the cloud they will end up leaping in with both feet very quickly there after.  We did, we set out to build a cloud compute platform and ended up living in the cloud from then on.  Now I’ve moved back to a non-cloud environment I am stuck in the office, using VPN’s, file shares and it taking days rather than minutes for any change to happen.  Instead of flexibility I have constraint – and that’s not what 2014 is about.

So instead of asking yourself if you have a big data problem, ask yourself how much more agile would your organization be if you used the cloud.  In fact, it’s 2014 – don’t ask yourself, just do it (you may not even need to ask IT)!

Advertisements
Posted in Uncategorized | Tagged , | Leave a comment

Sliding session authentication module for WIF

There’s a few examples of this around…  The example in the WIF book doesn’t take into consideration the clock skew.

Here’s one that does:

public class SlidingSessionAuthenticationModule : SessionAuthenticationModule
{
	protected override void OnSessionSecurityTokenReceived(SessionSecurityTokenReceivedEventArgs args)
	{
		var sessionSecurityToken = args.SessionToken;
		var now = DateTime.Now;
		var validTo = sessionSecurityToken.ValidTo.Add(ServiceConfiguration.MaxClockSkew);

		if (now < validTo)
		{
			var timeout = sessionSecurityToken.ValidTo - sessionSecurityToken.ValidFrom;
			var window = TimeSpan.FromSeconds(timeout.TotalSeconds / 2);

			var renewalTime = sessionSecurityToken.ValidTo.Subtract(window);
			if (now > renewalTime)
			{
				args.SessionToken = CreateSessionSecurityToken(
					sessionSecurityToken.ClaimsPrincipal, 
					sessionSecurityToken.Context, 
					now, 
					now.Add(timeout),
					sessionSecurityToken.IsPersistent);

				args.ReissueCookie = true;
			}
		}

		base.OnSessionSecurityTokenReceived(args);
	}
}
Posted in Uncategorized | Tagged | Leave a comment

Thread hanging when using Azure client API

There’s a already a good stack overflow post which covers why the storage client hangs when uploading / downloading and the network cable is removed  http://stackoverflow.com/questions/12803086/azure-storageclient-transient-connection-testing-hanging (there is an issue with the .Net streaming classes it uses under the skin).

This problem isn’t just limited to blobs, we’ve seen it when talking to queues too.  I’m pretty sure it would affect all calls.  We did speak to some folk (informally) and they think that the root cause may be resolved in .Net 4.5 – we haven’t yet tested ourselves (it will be a while before we upgrade our production environment).

It is important you understand this issue, even if you think you won’t have transient networking issues.  It’s a given if you’re on a train that the network connection will be up and down a fair bit.  But it still can happen when you’re on a server in Azure.  We run at large scale in Azure and we notice it from time to time.  The problem is if you don’t address it a thread which you thought was doing useful stuff, let’s say de-queueing and processing messages from a queue, is actually stuck on a network transfer somewhere.  It’s very nasty because that thread will never come back and you get no errors reported.  You’ll then be thinking, why isn’t that bit of our app working and spend a while peering through log files trying to work out what happened poor thread 33.

Where you monitor for this problem is up to you but the only way to really solve it is to monitor for how long things take and cancel them if they take too long.  If you’re using TPL you could start two tasks and wait either of them, if the timeout task completes then fail (remember to cancel the blocked task just in case it does actually complete).  We opted to not use TPL and abort the blocked thread in attempt to rescue some resources.

Here’s the code we use:

public class MonitoredWorkerPool
{
    private readonly ConcurrentQueue<Worker> _workers = new ConcurrentQueue<Worker>();
    
    public void DoWork(Action work, TimeSpan timeout)
    {
        var worker = _GetWorker();
        worker.DoWork(work);
        if (!worker.Join(timeout))
        {
            worker.Abort();
            throw new WorkerTimeoutException();
        }
        worker.Complete();
    }

    private Worker _GetWorker()
    {
        Worker worker;
        return !_workers.TryDequeue(out worker) ? new Worker(this) : worker;
    }

    private class Worker
    {
        readonly MonitoredWorkerPool _ownerPool;
        readonly Thread _thread;
        readonly AutoResetEvent _workerWaitEvent;
        readonly AutoResetEvent _workCompleted;
        Action _work;
        bool _isRunning = true;

        public Worker(MonitoredWorkerPool ownerPool)
        {
            _ownerPool = ownerPool;
            _workerWaitEvent = new AutoResetEvent(false);
            _workCompleted = new AutoResetEvent(false);
            _thread = new Thread(_WaitForWork);
            _thread.Start();
        }

        private void _WaitForWork(object state)
        {
            while (_isRunning)
            {
                _workerWaitEvent.WaitOne();
                try
                {
                    _work();
                }
                catch (Exception ex)
                {
                    Exception = ex;
                }
                _workCompleted.Set();
            }
        }

        Exception Exception { get; set; }

        public void DoWork(Action action)
        {
            _work = action;
            _workerWaitEvent.Set();
        }

        public bool Join(TimeSpan timeout)
        {
            return _workCompleted.WaitOne(timeout);
        }

        public void Abort()
        {
            _isRunning = false;
            _thread.Abort();
        }

        public void Complete()
        {
            var exception = Exception;
            _work = null;
            Exception = null;
            _ownerPool._workers.Enqueue(this);
            if (exception != null)
                throw exception;
        }
    }
}
Posted in Uncategorized | Tagged | Leave a comment

WinRT non-reentrant async timer ticks – Part II of approaching unit testing in WinRT

In the previous postI highlighted the issues with running WinRT tests on your build server and how we made our life a lot simpler by structuring our solution so we can test using standard .net testing frameworks (much like you would have done in Silverlight).  Here is an applied example of that approach.  It is an example of the dependency inversion principle.  It is also an example to help folk remember that async actions can easily create reentrancy issues.

It is required that our application keeps itself up to date by automatically refreshing the current screen.  From a non-functional perspective the timer must not be reentrant (if the service call exceeds the tick interval it shouldn’t kick off another request).

So we’re going to need a dispatcher timer (we want the callback on the UI thread).  DispatcherTimer is in Windows.UI.XAML, a WinRT only namespace not available in Portable.  We want to keep this code as minimal as possible because it is hard to test (it’s actually easy enough to test, the problem is those tests won’t run on our build box).  We also need to invert the dependency such that other portable code (view models for example) can access the timer.  If you think of the simplest thing you can do you come up with something which fires once after a given interval. You end up with an interface in Portable which looks like this:

public interface IDispatcherTimerFactory
{
    IDelayedAction DelayInvoke(TimeSpan delay, Action action);
}

public interface IDelayedAction
{
    void Cancel();
}

And you have a really simple implementation in WinRT which looks like this:

public class DispatcherTimerFactory : IDispatcherTimerFactory

    public IDelayedAction DelayInvoke(TimeSpan delay, Action action)
    {
        var timer = new DispatcherTimer { Interval = delay };

        timer.Tick += (s, e) =>
        {
            timer.Stop();
            action();
        };
        timer.Start();

        return new CancelableTimer(timer);
    }

    private class CancelableTimer : IDelayedAction
    {
        DispatcherTimer _timer;

        public CancelableTimer(DispatcherTimer timer)
        {
            _timer = timer;
        }

        public void Cancel()
        {
            _timer.Stop();
            _timer = null;
        }
    }
}

Now that’s cool but it doesn’t meet our requirement, we want this to keep firing over and over.  Now we can write that in our Portable namespace.  Here you can test using whatever testing framework tickles your fancy – we’re going to use MSpec.

As you know everything is async in WinRT which is great but you have to remember this when you design your interfaces.  We want to build something which lets someone perform a screen update every 5 seconds or so.  That means they are going to have to fetch some data asynchronously.  The timer mustn’t be reentrant so we don’t want to start the timer until the async call finishes, that at least means the server isn’t constantly handling calls from the client.  We also would like the ability to manually tick the timer.  This has the benefit of providing a refresh button to the user but also makes testing the view models easier because you can force their underlying timer to tick.  There is also the case where the tick action is not async.   With all this in mind we ended up with an interface like this:

public interface ITimerService{
    IAsyncTimer StartRepeatingAsyncTimer(TimeSpan interval, Func<Task> callback);
    ITimer StartRepeatingTimer(TimeSpan interval, Action callback);
}

public interface IAsyncTimer : ITimer
{
    Task AsyncForceTick();
}

public interface ITimer : IDisposable
{
    void ForceTick();
}

Note:  Something to point out is these interfaces were evolved by TDDing functional requirements and refactoring out the infrastructural code as we went along.  For simplicity I’m skipping the process by which we got to these designs as this isn’t so much a lesson in TDD (although the git log for this is quite interesting too).

Here is the implementation (pretty sure the naming sucks) and tests.  Because we’re able to use full .Net to test Portable libraries you have no restrictions on your testing framework.

public class TimerService : ITimerService
{
    readonly IDispatcherTimerFactory _dispatcherTimerFactory;

    public TimerService(IDispatcherTimerFactory dispatcherTimerFactory)
    {
        _dispatcherTimerFactory = dispatcherTimerFactory;
    }

    public IAsyncTimer StartRepeatingAsyncTimer(TimeSpan interval, Func<Task> callback)
    {
        return new AsyncRepeatingTimer(interval, callback, _dispatcherTimerFactory);
    }

    public ITimer StartRepeatingTimer(TimeSpan interval, Action callback)
    {
        return new SyncRepeatingTimer(interval, callback, _dispatcherTimerFactory);
    }

    private class SyncRepeatingTimer : RepeatingTimer
    {
        readonly Action _callback;

        public SyncRepeatingTimer(TimeSpan interval, Action callback, IDispatcherTimerFactory dispatcherTimerFactory) : base(dispatcherTimerFactory, interval)
        {
            _callback = callback;
        }

        protected override void Tick()
        {
            _callback();
            Restart();
        }
    }

    private class AsyncRepeatingTimer : RepeatingTimer, IAsyncTimer
    {
        readonly Func<Task> _callback;
        bool _isTicking;

        public AsyncRepeatingTimer(TimeSpan interval, Func<Task> callback, IDispatcherTimerFactory dispatcherTimerFactory)
            : base(dispatcherTimerFactory, interval)
        {
            _callback = callback;
        }

        async Task _DoTick()
        {
            // Don't worry about thread safety here we always tick on the UI thread
            if (_isTicking)
            {
                return;
            }

            _isTicking = true;
            await _callback();
            _isTicking = false;
            Restart();
        }

        protected async override void Tick()
        {
            await _DoTick();
        }

        public async Task AsyncForceTick()
        {
            Cancel();
            await _DoTick();
        }
    }

    private abstract class RepeatingTimer : ITimer
    {
        readonly IDispatcherTimerFactory _dispatcherTimerFactory;
        readonly TimeSpan _interval;
        bool _isDisposed;
        IDelayedAction _delayedAction;

        public RepeatingTimer(IDispatcherTimerFactory dispatcherTimerFactory, TimeSpan interval)
        {
            _dispatcherTimerFactory = dispatcherTimerFactory;
            _interval = interval;

            Restart();
        }

        protected bool IsDisposed
        {
            get { return _isDisposed; }
        }

        public void Dispose()
        {
            if (IsDisposed)
            {
                return;
            }
            _delayedAction.Cancel();
            _delayedAction = null;
            _isDisposed = true;
        }

        protected void Restart()
        {
            if (IsDisposed)
            {
                return;
            }
            _delayedAction = _dispatcherTimerFactory.DelayInvoke(_interval, Tick);
        }

        protected abstract void Tick();

        protected void Cancel()
        {
            _delayedAction.Cancel();
        }

        public void ForceTick()
        {
            Cancel();
            Tick();
        }
    }
}

public class when_async_timer_is_stopped_during_async_action_and_then_completes : when_async_timer_is_created
{
    Establish context = () => InvokeTimer();
    Because of = () =>
    {
        _timer.Dispose();
        _taskCompletionSource.SetResult(new object());

    };

    It should_not_restart_itself = () => _createdDelayedActions.ShouldEqual(1);
}

public class when_async_timer_is_manually_triggered_during_async_action : when_async_timer_is_created
{
    Establish context = () => InvokeTimer();
    Because of = () => _timer.ForceTick();
    It should_not_invoke_the_action_again = () => _callCount.ShouldEqual(1);
}

public class when_async_timer_is_stopped : when_async_timer_is_created
{
    Because of = () => _timer.Dispose();
    It should_cancel_delayed_action = () => _delayedAction.Verify(x => x.Cancel());
}

public class when_async_timer_tick_action_completes : when_async_timer_is_created
{
    Establish context = () => InvokeTimer();
    Because of = () => _taskCompletionSource.SetResult(new object());
    It should_restart_timer = () => _createdDelayedActions.ShouldEqual(2);
}

public class when_async_timer_ticks : when_async_timer_is_created
{
    Because of = () => InvokeTimer();
    It should_call_callback = () => _wasCalled.ShouldBeTrue();
    It should_not_restart_timer_as_async_action_not_yet_completed = () => _createdDelayedActions.ShouldEqual(1);
}

public class when_async_timer_is_manaully_triggered : when_async_timer_is_created
{
    Because of = () => _timer.ForceTick();
    It should_cancel_delayed_action = () => _delayedAction.Verify(x => x.Cancel());
    It should_call_callback = () => _wasCalled.ShouldBeTrue();
    It should_not_restart_timer_as_async_action_not_yet_completed = () => _createdDelayedActions.ShouldEqual(1);
}

public class when_async_timer_is_manaully_triggered_async : when_async_timer_is_created
{
    Because of = () => _task = _timer.AsyncForceTick();
    It should_cancel_delayed_action = () => _delayedAction.Verify(x => x.Cancel());
    It should_call_callback = () => _wasCalled.ShouldBeTrue();
    It should_not_restart_timer_as_async_action_not_yet_completed = () => _createdDelayedActions.ShouldEqual(1);
    It should_return_the_incomplete_task = () => _task.IsCompleted.ShouldBeFalse();

    static Task _task;
}

public class when_synchronous_timer_is_stopped : when_synchronous_timer_is_created
{
    Because of = () => _timer.Dispose();

    It should_cancel_delayed_action = () => _delayedAction.Verify(x => x.Cancel());
}

public class when_synchronous_is_manually_triggered : when_synchronous_timer_is_created
{
    Because of = () => _timer.ForceTick();

    It should_cancel_delayed_action = () => _delayedAction.Verify(x => x.Cancel());
    It should_call_callback = () => _wasCalled.ShouldBeTrue();
    It should_restart_timer = () => _createdDelayedActions.ShouldEqual(2);
}

public class when_synchronous_timer_fires : when_synchronous_timer_is_created
{
    Because of = () => InvokeTimer();

    It should_call_callback = () => _wasCalled.ShouldBeTrue();
    It should_restart_timer = () => _createdDelayedActions.ShouldEqual(2);
}

public class when_async_timer_is_created : TimerServiceTests
{
    Establish context = () =>
    {
        _taskCompletionSource = new TaskCompletionSource<object>();
        _wasCalled = false;
        _callCount = 0;
        _timer = _timerService.StartRepeatingAsyncTimer(TimeSpan.FromSeconds(10), _handleTick);
    };

    protected static readonly Func<Task> _handleTick = () =>
    {
        _wasCalled = true;
        _callCount++;
        return _taskCompletionSource.Task;
    };
    protected static IAsyncTimer _timer;
    protected static bool _wasCalled;
    protected static TaskCompletionSource<object> _taskCompletionSource;
    protected static int _callCount;
}

public class when_synchronous_timer_is_created : TimerServiceTest
{
    Establish context = () =>
    {
        _wasCalled = false;
        _timer = _timerService.StartRepeatingTimer(TimeSpan.FromSeconds(10), _handleTick);
    };

    protected static readonly Action _handleTick = () => _wasCalled = true;
    protected static ITimer _timer;
    protected static bool _wasCalled;
}

public class TimerServiceTests
{
    Establish context = () =>
    {
        _timerFactory = new Mock<IDispatcherTimerFactory>();
        _callback = null;
        _createdDelayedActions = 0;
        _delayedAction = new Mock<IDelayedAction>();
        _timerFactory.Setup(x => x.DelayInvoke(Moq.It.IsAny<TimeSpan>(), Moq.It.IsAny<Action>()))
            .Callback<TimeSpan, Action>((t, a) =>

                _callback = a;
                _createdDelayedActions++;
            })
            .Returns(_delayedAction.Object);

        _timerService = new TimerService(_timerFactory.Object);
    };

    protected static void InvokeTimer()
    {
        _callback();
    }

    protected static Mock<IDispatcherTimerFactory> _timerFactory;
    protected static TimerService _timerService;
    protected static int _createdDelayedActions;
    static Action _callback;
    protected static Mock<IDelayedAction> _delayedAction;
}

Posted in Uncategorized | Tagged , | Leave a comment

How we approached WinRT, solution structure and unit testing

I’ve written about a few of the things we’ve implemented in our Windows 8 app but not much about how we actually structured our code or how we approached unit testing.

First thing to say is we are an agile team committed to code quality.  Although the Windows 8 application is not part of our core product code it is still important for it to be maintainable.

The next is we’re developing it in C#.  We had a discussion about whether or not to use HTML and Javascript.  We went for C# because our team had more experience and we thought it would be easier and quicker to develop the application.  Although we did spike using NodeJS to test the Javascript, stubbing our WinRT dependencies.

The thing to remember with Windows 8 development is WinRT isn’t .Net.  From C# it looks and smells like .net but it isn’t.  So you might think the path to least resistance is to use MSTest and test the WinRT code (given your favourite testing framework might not have been ported / portabled yet).  We spent a day trying to get those tests running from build scripts and on our build server and it is far from easy.  We managed to get it working outside of Team City but when you run it from the build agent it complains about non-interactive users (to get this working on Windows Server 2012 you need to hack the registry), then about running as an administrator (again we tried hacking the registry to change the user the service runs under when an in interactive mode but to no avail).  We can change the way Team City hosts its build agent to not be a windows service but we didn’t like that.  We found a better alternative, don’t use MSTest.  (If I have the heart I’ll write about all this in more detail…)

We can actually test the vast majority of our code in .Net if we use portable libraries.  I’d liken this to Silverlight development, you could test using the Silverlight test runner but you’d rather not.  We do still have WinRT specific tests but we only run them locally.  As you’ll see they only test adapters.

So rather than just explain our assembly structure (WinRT Tests  -> WinRT -> Portable <- .Net 4 Tests) let’s walk through an example.  The next post shows how we implemented a non re-entrant dispatcher timer to keep our app up to date.  It is a good example because it’s a simple concept and shows the dependency inversion on WinRT specific APIs not available inside Portable libraries.

Posted in Uncategorized | Tagged | Leave a comment

C# 5 async – Limiting concurrent calls to the server on user interactions

In windows 8 everything is unashamedly async – which is a good thing for responsive apps. What’s even better is it comes with the release of C# 5 with all the syntax goodness to make async something much more palatable to deal with.

Something to remember though is that the user can go a bit nuts asking for loads of stuff at once – which although doesn’t have much of a performance impact on the client will make your sever wish it wasn’t connected to the network.  A classic example of this is holding the down button on a list to get to the bottom.  As you go down the list your selected item changes.  If you decide to update your detail view on property change then you’ll go get data for each selection changed event (if you have 100s of items and you go top to bottom that’s 100s of calls).

That’s bad enough.  But who’s saying the last request you get back is the last one you sent?  In the asynchronous world it might not be.  This can get more interesting when you’re polling for updates, who says you aren’t half way through a poll for the previous selected item?

This is not much fun because it’s a bugger to track down later on, it may not even get noticed (it’s less likely on a nice fast local network too).  Now you could lock the UI whenever you’re doing something, but that would be missing the point.

Here is the code to do this in C# 5 (tests are at the end of the post if you’re interested).

public class AsyncActionSynchronizer<TResult>
{
    readonly Func<Task<TResult>> _asyncAction;
    int _requestedUpdates;

    public AsyncActionSynchronizer(Func<Task<TResult>> asyncAction)
    {
        _asyncAction = asyncAction;
    }

    public event EventHandler<SynchroizedActionCompletedEventArgs<TResult>> UpdateCompleted;
        
    public async void Update()
    {
        await _UpdateAsync();
    }

    private async Task _UpdateAsync()
    {
        if (Interlocked.Increment(ref _requestedUpdates) > 1)
        {
            return;
        }
        var result = default(TResult);
        Exception exception = null;
        try
        {
            result = await _asyncAction();
        }
        catch (Exception ex)
        {
            exception = ex;
        }

        if (Interlocked.Exchange(ref _requestedUpdates, 0) > 1)
        {
            Update();
            return;
        }
        if (exception != null)
        {
            _OnErrored(exception);
        }
        else
        {
            _OnSuccess(result);
        }
    }

    private void _OnErrored(Exception exception)
    {
        var handler = UpdateCompleted;
        if (handler != null) handler(this, new SynchroizedActionCompletedEventArgs<TResult>(exception));
    }

    private void _OnSuccess(TResult result)
    {
        var handler = UpdateCompleted;
        if (handler != null) handler(this, new SynchroizedActionCompletedEventArgs<TResult>(result));
    }
}

public class SynchroizedActionCompletedEventArgs<T> : AsyncCompletedEventArgs
{
    private T _result;

    public SynchroizedActionCompletedEventArgs(T result) : base(null, false, null)
    {
        _result = result;
    }

    public SynchroizedActionCompletedEventArgs(Exception error) :  base(error, false, null)
    {
    }

    public T Result
    {
        get
        {
            if (Error != null)
            {
                throw Error;
            }

            return _result;
        }
    }
}

public static class AsyncActionSynchronizer
{
    public static AsyncActionSynchronizer<T> Create<T>(Func<Task<T>> asyncAction)
    {
        return new AsyncActionSynchronizer<T>(asyncAction);
    }
}

Notice that we do not return a Task on Update.  We could, but it would make things more complicated.  What do you do if you are one of the callers who is ditched?  Do we return a cancelled task?  Do we complete it straight away?  Do we wait for the update to complete then return with that result attached?  Each have their pros and cons.  But to be honest the simplest thing to do is use an event, you ask to Update and we will raise an event when the Update completes.  This works for our use case nicely, we only ever update the UI for the latest result regardless of the number of calls.  Also, our timer which is updating the screen can call Update and then wait for any Completed before resetting himself.  Would be interested in other views though, it feels like we’re mixing the old async world with the new (notice I’m using AsyncCompletedEventArgs).

You could solve this problem with RX.  We decided not to use any RX to limit the number of things someone has to know to maintain the code.  If there were 100 problems RX solved for us then we’d use it at a drop of a hat.  There is a lot to be said for carefully picking your dependencies, even if the author is Microsoft.  If there is a bug in the code below we can fix it quickly and we can understand the consequences.  That is a luxury you don’t have even with open source (unless you’re an author or contributor).

public class when_there_is_an_exception : AsyncActionSynchronizerTests
{
    Establish context = () =>
    {
        _expectedException = new Exception();
        var tcs = new TaskCompletionSource<object>();
        tcs.SetException(_expectedException);
        _taskCompletionSources.Add(tcs);
        _asyncActionSynchronizer.UpdateCompleted += (s, e) => _expectedException = e.Error;
    };

    Because of = () => _asyncActionSynchronizer.Update();

    It should_raise_an_event_containing_the_error_and_not_throw = () => _expectedException.ShouldNotBeNull();

    static Exception _expectedException;
}

public class when_updating_via_async_synchronizer : AsyncActionSynchronizerTests
{
    Establish context = () =>
    {
        _expectedResult = new object();
        _taskCompletionSources.Add(Task.Factory.CompletedTaskCompletionSource(_expectedResult));
    };

    Because of = () => _asyncActionSynchronizer.Update();
    It should_pass_result_to_update_action = () => _results.ShouldContainOnly(_expectedResult);
    static object _expectedResult;
}

public class when_multiple_updates_do_not_inter_leave : AsyncActionSynchronizerTests
{
    Establish context = () =>
    {
        _firstResult = new object();
        _secondResult = new object();

        _taskCompletionSources.Add(Task.Factory.CompletedTaskCompletionSource(_firstResult));
        _taskCompletionSources.Add(Task.Factory.CompletedTaskCompletionSource(_secondResult));
    };

    Because of = () =>
    {
        _asyncActionSynchronizer.Update();
        _asyncActionSynchronizer.Update();
    };

    It should_contain_both_results = () => _results.Count.ShouldEqual(2);
    It should_contain_results_in_correct_order = () => _results[1].ShouldEqual(_secondResult);

    static object _firstResult;
    static object _secondResult;
}

public class when_async_synchronizer_update_is_not_completed : AsyncActionSynchronizerTests
{
    Establish context = () => _taskCompletionSources.Add(new TaskCompletionSource<object>());

    It should_not_block_waiting_for_task = () => { };
    It should_not_invoke_action = () => _results.Count.ShouldEqual(0);
}

public class when_the_first_update_completes_but_second_update_is_pending : when_there_are_concurrent_updates
{
    Because of = () => _firstUpdate.SetResult(new object());

    It should_not_yet_have_a_result = () => _results.Count.ShouldEqual(0);
}

public class when_the_second_update_completes_after_the_first_update : when_there_are_concurrent_updates
{
    Because of = () =>
    {
        _firstUpdate.SetResult(_firstResult);
        _secondUpdate.SetResult(_secondResult);
    };

    It should_throw_away_first_result = () => _results.Count.ShouldEqual(1);
    It should_handle_the_second_result_second = () => _results[0].ShouldEqual(_secondResult);
    It should_have_made_two_async_calls = () => _asyncActionCallCount.ShouldEqual(2);
}

public class when_the_second_update_completes_before_the_first_update : when_there_are_concurrent_updates
{
    Because of = () =>
    {
        _secondUpdate.SetResult(_secondResult);
        _firstUpdate.SetResult(_firstResult);
    };

    It should_only_contain_the_last_result = () => _results.ShouldContainOnly(_secondResult);
}

public class when_there_are_multiple_updates_pending : when_there_are_concurrent_updates
{
    Establish context = () =>
    {
        _asyncActionSynchronizer.Update();
        _asyncActionSynchronizer.Update();
        _asyncActionSynchronizer.Update();
        _asyncActionSynchronizer.Update();
        _asyncActionSynchronizer.Update();
    };

    Because of = () =>
    {
        _firstUpdate.SetResult(_firstResult);
        _secondUpdate.SetResult(_secondResult);
    };

    It should_skip_intermediate_updates = () => _asyncActionCallCount.ShouldEqual(2);
    It should_contain_the_last_updates_result = () => _results.ShouldContainOnly(_secondResult);
}

public class when_there_are_concurrent_updates : AsyncActionSynchronizerTests
{
    Establish context = () =>
    {
        _firstResult = new object();
        _secondResult = new object();

        _firstUpdate = new TaskCompletionSource<object>();
        _taskCompletionSources.Add(_firstUpdate);

        _secondUpdate = new TaskCompletionSource<object>();
        _taskCompletionSources.Add(_secondUpdate);

        _asyncActionSynchronizer.Update();
        _asyncActionSynchronizer.Update();
    };

    protected static TaskCompletionSource<object> _firstUpdate;
    protected static TaskCompletionSource<object> _secondUpdate;
    protected static object _firstResult;
    protected static object _secondResult;
}

public class AsyncActionSynchronizerTests
{
    Establish context = () =>
    {
        _currentTask = 0;
        _asyncActionCallCount = 0;
        _taskCompletionSources = new List<TaskCompletionSource<object>>();
        _results = new List<object>();
        _asyncActionSynchronizer = AsyncActionSynchronizer.Create(_AsyncAction);
        _asyncActionSynchronizer.UpdateCompleted += (s, e) => _Update(e);
    };

    private static Task<object> _AsyncAction()
    {
        _asyncActionCallCount++;
        return _taskCompletionSources[_currentTask++].Task;
    }

    private static void _Update(SynchroizedActionCompletedEventArgs<object> e)
    {
        if (e.Error == null)
        {
            _results.Add(e.Result);
        }
    }

    protected static List<TaskCompletionSource<object>> _taskCompletionSources;
    protected static List<object> _results = new List<object>();
    protected static AsyncActionSynchronizer<object> _asyncActionSynchronizer;
    protected static int _asyncActionCallCount;
    static int _currentTask;
}
Posted in Uncategorized | Tagged , | Leave a comment

ICommand implementation with a little bit of async in WinRT

So the RelayCommand or DelegateCommand (whichever name you prefer) is a well known chap.  We created an AsyncRelayCommand which essentially disables the command while an async action is running.  This is useful because commands may call services (which are async) and during that call you’d rather the user not do it again.

This is nothing new, but it is a cool example of how easy stuff like this is now you have the async keyword.  It’s also been rather handy to sprinkle the async commands around our code as it simplifies the can execute logic.

Here’s the code:

public class AsyncRelayCommand : IAsyncCommand
    {
        readonly Func<object, bool> _canExecute;
        bool _isExecuting;
        readonly Func<object, Task> _action;

        public event EventHandler CanExecuteChanged;

        public AsyncRelayCommand(Func<object, Task> action)
        {
            _action = action;
        }

        public AsyncRelayCommand(Func<object, Task> action, Func<object, bool> canExecute)
            : this(action)
        {
            _canExecute = canExecute;
        }

        public bool CanExecute(object parameter)
        {
            var canExecutResult = _canExecute == null || _canExecute(parameter);
            return !_isExecuting && canExecutResult;
        }

        async void ICommand.Execute(object parameter)
        {
            await Execute(parameter);
        }

        public async Task Execute(object parameter)
        {
            _ChangeIsExecuting(true);
            try
            {
                await _action(parameter);
            }
            finally
            {
                _ChangeIsExecuting(false);
            }
        }

        private void _ChangeIsExecuting(bool newValue)
        {
            if (newValue == _isExecuting)
            {
                return;
            }
            _isExecuting = newValue;
            _OnCanExecuteChanged();
        }

        void _OnCanExecuteChanged()
        {
            var handler = CanExecuteChanged;
            if (handler != null)
            {
                handler(this, EventArgs.Empty);
            }
        }
    }
Posted in Uncategorized | Tagged , , | 7 Comments