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)!

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

Retrying with .net WebAPI client

We’ve been building a prototype Windows 8 dashboard to show management information on our Azure application.

One thing we were conscious of was unreliable mobile network connections so we wanted to make some attempt to retry if we get a failure.

We achieved this with a custom HttpMessageHandler.  We extend the DelegatingHandler so we can pass on to the real HttpClientHandler – this usefully also allows us to resend requests (if you try and send the same request twice you’ll get an exception when not using a delegating handler).  It’s pretty simple but seems to work ok (it doesn’t have any back off or handle specific types of errors – it is the simplest thing we can get away with right now).

    public class RetryingMessageHandler : DelegatingHandler
    {
        const int MaximumRetries = 10;

        public RetryingMessageHandler(HttpMessageHandler httpMessageSender, IEnumerable<IHttpResponseInspector> inspectors)
            : base(httpMessageSender)
        {
            Inspectors = inspectors;
        }

        public IEnumerable<IHttpResponseInspector> Inspectors { get; private set; }

        protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
        {
            Exception lastExcpetion = null;
            int i;
            var maxRetries = MaximumRetries + 1;
            for (i = 0; i < maxRetries; i++)
            {
                var retryRequired = false;
                HttpResponseMessage result;
                try
                {
                    result = await base.SendAsync(request, cancellationToken);
                }
                catch (Exception ex)
                {
                    lastExcpetion = ex;
                    continue;
                }
                foreach (var inspector in Inspectors)
                {
                    var inspectionResult = await inspector.Inspect(result);
                    if (inspectionResult == InspectionResult.Retry)
                    {
                        retryRequired = true;
                        if (inspector.MaxRetries < maxRetries)
                        {
                            maxRetries = inspector.MaxRetries + 1;
                        }
                    }
                }
                if (!retryRequired)
                {
                    return result;
                }
            }

            throw new ServiceRetryLimitExceededException(string.Format("Retry count exceeded, attempted call {0} times", i), lastExcpetion);
        }
    }

You’ll see you can pass in your own ‘Response Inspectors’ which can vote as to whether they want to retry or abort the call.  We use this to handle seamlessly re-logging in a user when their cookie expires.  Something which would be good to do is have different max retries for different inspectors – but we haven’t needed it yet.

We wrapped this up in a simple factory for creating a HttpClient.

public class HttpClientFactory : IHttpClientFactory
{
    private readonly CookieContainer _cookieContainer = new CookieContainer();

    public HttpMessageHandler CreateHandler()
    {
        return CreateHandler(new IHttpResponseInspector[0]);
    }

    public HttpMessageHandler CreateHandler(IEnumerable<IHttpResponseInspector> responseInspectors)
    {
        return new RetryingMessageHandler(_CreateHttpClientHandler(), responseInspectors);
    }

    HttpMessageHandler _CreateHttpClientHandler()
    {
        return _ConfigureClientHandler(new HttpClientHandler());
    }

    private HttpClientHandler _ConfigureClientHandler(HttpClientHandler handler)
    {
        handler.CookieContainer = _cookieContainer;
        handler.AllowAutoRedirect = false;
        return handler;
    }
}

public static class HttpClientFactoryExtensions
{
    public static HttpClient Create(this IHttpClientFactory httpClientFactory)
    {
        return new HttpClient(httpClientFactory.CreateHandler());
    }
}

All in all it’s pretty simple to extend the WebAPI and the delegating handler is a simple AOPish method for adding generic behaviour to all service calls.

Posted in Uncategorized | Tagged , , | Leave a comment

Handling gestures in C# WinRT using a behaviour

We’re using the WinRTBehaviors as WinRT doesn’t have them built in.  Behaviours (with a u sorry, I am English) are great and I’m really pleased that someone has ported them across – one less thing for us to do – thanks!

So gestures are cool but not massively easy to add in.  It isn’t complicated but it’s repetitive event wire up stuff.  It would be nice to wire up a cross swipe to a command on the view model.  To facilitate this we created a behaviour to encapsulate the gesture event wire up and expose a command for each gesture we support (at present we only need cross swipe and tap).

Note:  The cross swipe gesture ends in a tap event so if you want to do one thing on tap and another on cross swipe then you’ll have to do all the event handling via the gesture otherwise you will always run the tap action when cross swiping.  This is why it is useful for us to encapsulate all gestures in a single behaviour.

Here’s the behaviour:

public class GestureBehavior : Behavior<FrameworkElement>
{
    GestureRecognizer _pageGesture;

    public static readonly DependencyProperty CrossSwipeCommandProperty =
        DependencyProperty.Register("CrossSwipeCommand", typeof(string), typeof(GestureBehavior), new PropertyMetadata(default(string)));

    public static readonly DependencyProperty TapCommandProperty =
        DependencyProperty.Register("TapCommand", typeof(string), typeof(GestureBehavior), new PropertyMetadata(default(string)));

    public string CrossSwipeCommand
    {
        get { return (string)GetValue(CrossSwipeCommandProperty); }
        set { SetValue(CrossSwipeCommandProperty, value); }
    }

    public string TapCommand
    {
        get { return (string)GetValue(TapCommandProperty); }
        set { SetValue(TapCommandProperty, value); }
    }

    protected override void OnAttached()
    {
        AssociatedObject.AddHandler(PointerPressedEvent, (PointerEventHandler)_OnPointerPressed, true);
        AssociatedObject.AddHandler(PointerReleasedEvent, (PointerEventHandler)_OnPointerReleased, true);
        AssociatedObject.AddHandler(PointerMovedEvent, (PointerEventHandler)_OnPointerMoved, true);
        AssociatedObject.AddHandler(RightTappedEvent, (RightTappedEventHandler)_OnRightTap, true);
        base.OnAttached();
    }

    protected override void OnDetaching()
    {
        if (_pageGesture != null && _pageGesture.IsActive)
        {
            _CompleteGesture();
        }
        AssociatedObject.RemoveHandler(PointerPressedEvent, (PointerEventHandler)_OnPointerPressed);
        AssociatedObject.RemoveHandler(PointerReleasedEvent, (PointerEventHandler)_OnPointerReleased);
        AssociatedObject.RemoveHandler(PointerMovedEvent, (PointerEventHandler)_OnPointerMoved);
        AssociatedObject.RemoveHandler(RightTappedEvent, (RightTappedEventHandler)_OnRightTap);

        base.OnDetaching();
    }
    private void _OnPointerPressed(object sender, PointerRoutedEventArgs e)
    {
        _pageGesture = new GestureRecognizer
        {
            CrossSlideHorizontally = true,
            ShowGestureFeedback = true,
            CrossSlideThresholds = new CrossSlideThresholds { RearrangeStart = 0, SelectionStart = 5, SpeedBumpStart = 0, SpeedBumpEnd = 0 },
            GestureSettings = GestureSettings.CrossSlide | GestureSettings.Tap
        };
        _pageGesture.CrossSliding += _PageGestureOnCrossSliding;
        _pageGesture.Tapped += _TappedButDidNotSwipe;
        _pageGesture.ProcessDownEvent(e.GetCurrentPoint(AssociatedObject));
    }

    private void _OnPointerMoved(object sender, PointerRoutedEventArgs e)
    {
        if (_pageGesture != null)
        {
            try
            {
                _pageGesture.ProcessMoveEvents(e.GetIntermediatePoints(AssociatedObject));
            }
            catch
            {
                _CompleteGesture();    
            }
        }
    }
        
    private void _OnPointerReleased(object sender, PointerRoutedEventArgs e)
    {
        if (_pageGesture != null)
        {
            try
            {
                _pageGesture.ProcessUpEvent(e.GetCurrentPoint(AssociatedObject));
            }
            catch
            {
            }
            finally 
            {
                _CompleteGesture();
            }
        }
    }
        
    private void _CompleteGesture()
    {
        _pageGesture.CompleteGesture();
        _pageGesture.CrossSliding -= _PageGestureOnCrossSliding;
        _pageGesture.Tapped -= _TappedButDidNotSwipe;
        _pageGesture = null;
    }

    private void _PageGestureOnCrossSliding(GestureRecognizer sender, CrossSlidingEventArgs args)
    {
        if (args.CrossSlidingState == CrossSlidingState.Completed && CrossSwipeCommand != null)
        {
            AssociatedObject.ExecuteCommand(CrossSwipeCommand);
        }
    }
                
    private void _TappedButDidNotSwipe(GestureRecognizer sender, TappedEventArgs args)
    {
        if (TapCommand != null)
        {
            AssociatedObject.ExecuteCommand(TapCommand);
        }
    }
        
    private void _OnRightTap(object sender, RightTappedRoutedEventArgs e)
    {
        if (CrossSwipeCommand != null)
        {
            AssociatedObject.ExecuteCommand(CrossSwipeCommand);
        }
    }
}

Here is how it’s used in XAML:

<ListView ... >
                <b:Interaction.Behaviors>
                    <i:GestureBehavior CrossSwipeCommand="DoSomething" TapCommand="DoSomethingElse" />
                </b:Interaction.Behaviors>
....

We have other behaviours which execute commands and we’ve encapsulated some of that command execution behaviour in the following code:

public static void ExecuteCommand(this FrameworkElement associatedObject, string commandName)
{
    if (associatedObject.DataContext == null) return;
    
    new CommandProxy(associatedObject.DataContext, commandName).Execute();
}

public class CommandProxy
{
    readonly string _commandName;
    readonly ICommand _command;

    public CommandProxy(object dataContext, string commandName)
    {
        _commandName = commandName;
        _command = _ExtractCommand(dataContext, commandName);
    }

    ICommand _ExtractCommand(object dataContext, string commandName)
    {
        var commandProperty = dataContext.GetType().GetRuntimeProperty(commandName);
        if (commandProperty == null)
        {
            return null;
        }

        return (ICommand)commandProperty.GetValue(dataContext);
    }

    public bool FoundCommand
    {
        get { return _command != null; }
    }

    public bool Execute()
    {
        if (!FoundCommand)
        {
            throw new NullReferenceException(string.Format("Cannot execute the command as no command named {0} could be found on the instance.", _commandName));
        }
        if (!_command.CanExecute(null))
        {
            return false;
        }
        _command.Execute(null);
        return true;
    }
}

I really should set up a git repo for all the WinRT stuff discussed in the blog – hopefully I’ll get some time once the project is done.

One thing we don’t like, but couldn’t find a way around, was handling exceptions when the GestureRecognizer fires events.  We were seeing odd behaviour when beginning a gesture on an empty list then populating the list.  The gesture wouldn’t complete and would fire more events but then throw exceptions (about not having same pointer id or different frame…).  With this here the app doesn’t crash and gestures still work ok.

Posted in Uncategorized | Tagged | Leave a comment

Machine.Specifications (mspec) only output errors

Our team is very command line oriented, we’ll often run our test suit from the command line.  A typical workflow would be to commit, pull build then push (assuming we didn’t break the build!).

You’ll notice that when you run mspec from the command line you get a lot of output.  You can turn off ALL output other than the summary at the end but that doesn’t help when you want to know which tests have failed.

We use psake for our build, Adrian has already posted about integrating mspec with psake.  We made the following tweak to our build to only show test failures (we parse the XML output generated by mspec):

task MSpecUnitTests -depends Compile -description "MSpec unit tests" {
  $testDlls = ls "$srcDir\*\bin\$buildConfiguration" -rec `
    | where { $_.Name.EndsWith(".Tests.dll") } `
    | where { (Test-Path ([System.IO.Path]::GetDirectoryName($_.FullName) + "\Machine.Specifications.dll")) -eq $True } `
    | foreach { $_.FullName }

  $mspecExePath = Join-Path $packagesDir "Machine.Specifications.0.5.8\tools\mspec-clr4.exe";

  if($env:TEAMCITY_VERSION -ne $Null)
  {
      exec{ & $mspecExePath $testDlls --teamcity }
  }
  else
  {
    $mspecOutputPath = Join-Path $buildDir 'mspec.xml'
    try{
      exec{ & $mspecExePath $testDlls -s --xml $mspecOutputPath }
    }
    catch {
      [xml]$testOutput = Get-Content $mspecOutputPath
      Select-Xml "//context[specification/@status='failed']"; $testOutput | % {
        Write-Host "> " -NoNewLine
        Write-Host $_.Node.name -NoNewLine -foregroundcolor "yellow"
        Write-Host " failed the following specifications:"
        foreach ($spec in $_.Node.specification) {
          if ($spec.status -eq 'failed') {
            Write-Host ">> " -NoNewLine
            Write-Host $spec.name -NoNewLine
            Write-Host " (" -NoNewLine
            Write-Host $spec.error.message.innerText -NoNewLine -foregroundcolor "red"
            Write-Host ")"
          }
        }
      }
    }
  }
}
Posted in Uncategorized | Tagged | Leave a comment