Playing around with undo & redo functionality on WP7

Following on from my previous post about 'undo, redo, undo, redo' I thought I would port this to WP7, I say port more a case of re-compile. What follows is an example of simple WP7 app using undo-redo functionality, whether this is any use for a real-world Wp& is up for debate.

I pushed the code out to GitHub here, the only explicit changes required was a WP7 solution & project files. I also added support for INotifyPropertyChanged this allows the CanUndo & CanRedo properties to push out change notifications - this was done to allow the binding of the enable property of an input control (button). So now the undoable class looks like this; the same implementation for all .Net versions:

public class Undoable : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler PropertyChanged = delegate { };

    private readonly Stack<Memento> undoStack;
    private readonly Stack<Memento> redoStack;

    public Undoable()
    {
        undoStack = new Stack<Memento>();
        redoStack = new Stack<Memento>();
    }

    public bool CanUndo
    {
        get { return undoStack.Count != 0; }
    }

    public bool CanRedo
    {
        get { return redoStack.Count != 0; }
    }

    public void Add(Action undoAction)
    {
        undoStack.Push(new Memento(undoAction));
        redoStack.Clear();

        RaisePropertyChanged(() => CanUndo);
        RaisePropertyChanged(() => CanRedo);
    }

    public void Add(Action undoAction, Action redoAction)
    {
        undoStack.Push(new Memento(undoAction, redoAction));
        redoStack.Clear();

        RaisePropertyChanged(() => CanUndo);
        RaisePropertyChanged(() => CanRedo);
    }
        
    public void Undo()
    {
        if (undoStack.Count == 0)
        {
            return;
        }

        var current = undoStack.Pop();
        current.Undo();

        if (current.Redo != null)
        {
            redoStack.Push(current);
        }

        RaisePropertyChanged(() => CanUndo);
        RaisePropertyChanged(() => CanRedo);
    }

    public void Redo()
    {
        if (redoStack.Count == 0)
        {
            return;
        }

        var current = redoStack.Pop();
        current.Redo();
        undoStack.Push(current);

        RaisePropertyChanged(() => CanUndo);
        RaisePropertyChanged(() => CanRedo);
    }
        
    public void Clear()
    {
        redoStack.Clear();
        undoStack.Clear();

        RaisePropertyChanged(() => CanUndo);
        RaisePropertyChanged(() => CanRedo);
    }

    protected void RaisePropertyChanged<T>(Expression<Func<T>> expression)
    {
        PropertyChanged(this, new PropertyChangedEventArgs(ExpressionHelper.Name(expression)));
    }
}

The only thing of note in the above code snippet is the method signature of the RaisePropertyChanged method. I use an expression to avoid using magic strings for property names, the expression is then evaluated and returns the property name when evaluated inside the method.

So how is this used?

As I said in the previous post this was designed to be used from a Controller (ViewModel). The Controller 'controls' what & when is added to the undo list. In the following case the Controller has explicit properties to expose the state of the Model - properties on the ViewModel exposing properties on the Model, we aren't directly binding the Model to View. I'm inject the dependancies for the ViewModel and the Undoable instance is one of them - this could be shared between different ViewModels if required.

public class MainViewModel : ViewModelBase
{
    readonly Widget widget;
    readonly Undoable undoable;

    public MainViewModel(Undoable undoable)
    {
        this.undoable = undoable;
        widget = new Widget();
    }

    public Undoable Undoable
    {
        get { return undoable; }
    }

    public string Identifier
    {
        get { return widget.Identifier; }
        set
        {
            SetPropertyWithUndoActions(widget.Identifier,
                                       value,
                                       str => { widget.Identifier = str; },
                                       () => Identifier); 
        }
    }
}

The interesting part is the SetPropertyWithUndoActions method, as the name suggests it sets the value on the Model and adds actions to the undo-redo list represented by the Undoable instance. What I'm not showing here is there are 2 other similar method properties being exposed Name & Description. The ViewModel exposes these 3 properties to the View model.

The SetPropertyWithUndoActions method is shown below:

private void SetPropertyWithUndoActions<T>(T currentValue,
                                           T newValue,
                                           Action<T> setValue,
                                           Expression<Func<T>> expression)
{
    if (Equals(currentValue, newValue))
    {
        return;
    }

    var cVal = currentValue;
    undoable.Add(() =>
                 {
                     setValue(cVal);
                     RaisePropertyChanged(ExpressionHelper.Name(expression));
                 },
                 () =>
                 {
                     setValue(newValue);
                     RaisePropertyChanged(ExpressionHelper.Name(expression));
                 });

    setValue(newValue);
    RaisePropertyChanged(ExpressionHelper.Name(expression));
}

So now when ever I change the text in the text boxes representing the Identifier, Name or Description I will be able to undo & redo those actions. I wired the undo & redo to app bar buttons in the test app.

The screen shots don't really do it justice, but a user can now undo\redo any input field actions. There are a couple of caveats for the example app - it doesn't move the focus correctly when undo\redo an action and it does not place the cursor at the correct location either, both of these could be sorted out with some View specific logic.

The code for the WP7 demo app is available on the GitHub - check out the WP7 solution test project. I've also created a NuGet package.

Read More

undo-redo-undo-redo...

Code available on GitHub

I'm currently building a UI with a semi-complex input-form that requires the ability to 'undo, redo, undo, redo' user actions ad-infinitum. Not only does it require the ability to undo the text typed in text-boxes etc it needs the ability to undo (or redo) button clicks that add\remove complex properties (reference types).

For example imagine I have the following model, where there is a hierarchical structure to the data  - parent-child relationships, the Widget has one settable value type property - 'Name' & a collection of child Widgets accessed via the 'Children' property, this property can not set by the caller- the caller has to use the 'AddChild' & 'RemoveChild' methods to affect the enumerable 'Children' property. I want the ability to 'undo, redo, undo, redo' on these two properties.

public class Widget : Model
{
    private int? id;
    private Widget parent;
    private string name;
    private readonly ObservableCollection<Widget> children;

    public Widget()
    {
        children = new ObservableCollection<Widget>();
    }

    public int? Id
    {
        get { return id; } 
        private set
        {
            SetPropertyAndNotify(ref id, value, () => Id);
        }
    }

    public string Name
    {
        get { return name; }
        set
        {
            SetPropertyAndNotify(ref name, value, () => Name);
        }
    }

    public Widget Parent
    {
        get { return parent; }
        private set
        {
            SetPropertyAndNotify(ref parent, value, () => Parent);
        }
    }

    public IEnumerable<Widget> Children
    {
        get { return children; }
    }

    public Widget AddChild(Widget child)
    {
        if (children.Contains(child))
        {
            return this;
        }

        child.Parent = this;
        children.Add(child);

        return this;
    }

    public Widget AddChild(IEnumerable<Widget> childs)
    {
        foreach (var child in childs)
        {
            AddChild(child);
        }

        return this;
    }

    public Widget RemoveChild(Widget child)
    {
        if (!children.Contains(child))
        {
            return this;
        }

        child.Parent = null;
        children.Remove(child);

        return this;
    }

    public Widget RemoveAllChildren()
    {
        foreach (var child in children.ToList())
        {
            child.Parent = null;
            children.Remove(child);
        }

        return this;
    }
}

I know already the kind of functionality required, an implementation of the Command Pattern, specifically the Memento Pattern. A quick Google found some interesting implementations much of which I didn't like for a couple of reason, one being no separation from UI - here or to complex (to many interfaces) - here. A couple more examples were just to old, not using modern languages features like Lambda expressions. In fact the use of Lambdas should make this a trivial exercise. The solution I want should be capable of being used within an MVC implementation without being tied to it, in fact it should know nothing about either the Model or the View. I envisage it being used from inside the Controller. This fits well with the UI I'm currently building, an MVVM implementation.

The solution I came up with has 2 classes, the first is the Memento we wish to be able to 'undo-redo'. As you can see the use of Action delegate syntax to remove any explicit knowledge of how the 'undo-redo' steps will be performed. There are 2 constructors one for when both undo & redo is supported and the other when only undo is supported:

public class Memento
{
    public Action Undo { get; private set; }
    public Action Redo { get; private set; }

    public Memento(Action undo)
    {
        Undo = undo;
        Redo = () => { };
    }

    public Memento(Action undo, Action redo)
    {
        Undo = undo;
        Redo = redo;
    }
}

The second class actual contains the Memento instances, simply it contains a pair of Stack representing the undo & redo list. When an Undo action is executed the Memento is first popped from the undo stack, executed and then pushed onto the Redo stack, and it's the reverse for a Redo action. The only other behaviour of note is when a new Undo\Redo is added, any Redo's are cleared, this is to prevent confusion when changes are being reverted to a certain point and then editing continues.

public class Undoable
{
    private readonly Stack<Memento> undoStack;
    private readonly Stack<Memento> redoStack;

    public Undoable()
    {
        undoStack = new Stack<Memento>();
        redoStack = new Stack<Memento>();
    }

    public void Add(Action undoAction, Action redoAction)
    {
        undoStack.Push(new Memento(undoAction, redoAction));
        redoStack.Clear();
    }

    public void Undo()
    {
        if (undoStack.Count == 0)
        {
            return;
        }

        var current = undoStack.Pop();
        current.Undo();
        redoStack.Push(current);
    }

    public void Redo()
    {
        if (redoStack.Count == 0)
        {
            return;
        }

        var current = redoStack.Pop();
        current.Redo();
        undoStack.Push(current);
    }
        
    public void Clear()
    {
        redoStack.Clear();
        undoStack.Clear();
    }
}

So to round a couple of test written using MSpec. The first one shows the Undo'ing of setting a simple (value type) property on the model:

[Subject("Undoable")]
public class when_undoing_a_value_type_property_modification
{
    private Establish context = () =>
    {
        undoable = new Undoable();
        widget = new Widget {Name = OriginalName};
    };

    private Because of = () =>
    {
        undoable.Add(() => { widget.Name = OriginalName; }, () => { widget.Name = NewName; });

        widget.Name = NewName;
        undoable.Undo();
    };

    private It should_undo_setting_the_name_on_a_widget = () => widget.Name.ShouldEqual(OriginalName);

    private static string OriginalName = "Original Name - " + Guid.NewGuid();
    private static string NewName = "New name - " + Guid.NewGuid();
    private static Widget widget;
    private static Undoable undoable;
}

The second shows the Redo'ing of adding a child Widget to the parent:

[Subject("Undoable")]

public class when_redoing_a_reference_type_property_modification
{
    private Establish context = () =>
    {
        undoable = new Undoable();
        parent = new Widget { Name = "Parent Widget" };
        child = new Widget { Name = "Child Widget" };
    };

    private Because of = () =>
    {
        undoable.Add(() => parent.RemoveChild(child), () => parent.AddChild(child));
        parent.AddChild(child);
        undoable.Undo();
        undoable.Redo();
    };

    private It parent_widget_should_cotain_child_widget = () => parent.Children.Contains(child).ShouldEqual(true);

    private It parent_widget_children_collection_should_not_be_empty = () => parent.Children.Count().ShouldNotEqual(0);

    private static Widget parent;
    private static Widget child;
    private static Undoable undoable;
}

I've pushed this to GitHub here.

Read More

Trying to test strongly typed datatables with sqlite...

Following on from my previous post about wrapping an auto-generated strongly typed set of data-tables behind a service interface, in this post I want to show how I attempted to unit this service and failed!

The service was created for the sole purpose of abstracting away the complexity I believe an ORM would have removed (see previous post), if this functionality had been implemented by an ORM then this interface would not have existed and no testing would be required.

I was trying to perform unit testing - I wanted to test the code in isolation without any external dependencies. At this stage I didn't want to write any integration tests, since the development was deon off site and the client owned and managed the system infrastructure we believe they can take the opportunity to write integration tests after our delivery - this would allow them to prove the code base we have developed.

The system uses a Sql Server 2008 back-end - standard 2 tier stuff. So the first stage was to convert this to a Sqlite database - this would provide the database as a single file which could be included in the unit test project, thus removing the external dependency. This was easy enough using this tool hosted up on CodeProject - all done in 5 minutes.

Next stage was to modify the connection string used by the strongly typed data-tables - the client has specific requirements how this connection string was built - they inject particular connection string parameters from the app.config file. The client specific requirements wasn't the issue, the issue was the settings class containing the connection string, it was marked with sealed & internal modifiers. It was also a singleton used by all data adapters defined in the DAL.

As you can see from above no way to easily set the singleton. This wasn't difficult to get round, a bit of reflection and we have the settings class with connection string we want:

var type = Type.GetType("XXXX.RMS.DAL.My.MySettings, DAL, Version=2.0.2.0, Culture=neutral, PublicKeyToken=null");
var parameterlessCtor = (from c in type.GetConstructors(BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance)
                         where c.GetParameters().Length == 0 select c).FirstOrDefault();

var instance = parameterlessCtor.Invoke(null);
var setting = (ApplicationSettingsBase) instance;
setting["XXXXConnectionString"] = "Data Source=XXXX_sqlite.db;";

I used this code in the set-up for a unit test to access the sqlite database via the strongly typed database. This is when things went wrong or more specifically my assumption was wrong - all I needed to do was change the database connection string from a Sql Server to a Sqlite version.

[Test]
public void get_package_assemblies()
{
    // Given we can manipulate the settings class and set the connection string...
    SetConnectionStringToSqlite();

    // Given we can create a assemblies table adapter...
    var adapter = new AssembliesTableAdapter();

    // When we request an assembly by id...
    var dataTable = adapter.GetByAssemblyId(13231);

    // Then we expect some results to be returned...
    Assert.IsNotNull(dataTable);
    Assert.IsNotEmpty(dataTable.Rows);
}

private void SetConnectionStringToSqlite()
{
    var type = Type.GetType("FBS.RMS.DAL.My.MySettings, DAL, Version=2.0.2.0, Culture=neutral, PublicKeyToken=null");
    var parameterlessCtor = (from c in type.GetConstructors(BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance)
                                where c.GetParameters().Length == 0
                                select c).FirstOrDefault();

    var instance = parameterlessCtor.Invoke(null);
    var settings = (ApplicationSettingsBase)instance;
    settings["FBSConnectionString"] = "Data Source=FBS_sqlite.db;";

    // Set the static field - singleton used by all data table adapters...
    var tmp = settings.GetType().GetField("defaultInstance", BindingFlags.NonPublic | BindingFlags.Static | BindingFlags.SetField);
    tmp.SetValue(settings, settings);
}

The test blew at the first assert - it failed because the assumption I made about how the data adapter had been generated was wrong. I was expecting the data adapter class to have member variables for the adapter, connection & command as interfaces not as implementations of the interface, in other words instead of IConnection for the variable type it was SqlConnection.

This completely scuppered my attempt to test the service in isolation.

It's at this point I gave up trying...

Read More

An ORM would have saved time...

I've just finished working on a WPF, a pretty standard inventory system for widgets & gadgets. A hierachurial structure to the data that lends its self to a tree-view structure - essentially each node has a parent-child relationship, where a node can have multiple child nodes and each node has a reference to it's parent. The app is a simple a CRUD application with some UI tweeks on how the data was to be displayed - visualising the modified nodes in the tree and hows these affected the parent node.

What made this interesting was the fact this wasn't a new app from the ground-up, it was literally only a new UI, the database was already established in a production environment and had been for over 5 years, what made this interesting was the client was providing the DAL & BLL for the application - we were abstracted away from the database. All queries for data are returned via strongly typed data tables and all commands (updates) are done via explicit methods on the BLL. To be honest these didn't really measure up to my idea of a business logic layer, to perform a 'business action' with the BLL required multiple calls - so when trying to hydrate data from the database we had to make multiple calls to the BLL just to get all the data required, none of the BLL calls were designed with any real business need, they were more a need to get data from the database.

Originally when we started the engagement we knew nothing about the DAL & BLL provided by the client. Our presumption was to use an ORM as part of the 2 tier architecture utilising MVVM with the ORM being used directly from the ViewModel to reduce the number of abstractions - I agree with Ayende's stance on the use of a repository abstraction in  applications is no longer providing any benefit. We still planned to follow this architecture after we found out using an ORM was not an option, but it became obvious we would have introduce another abstraction into the application because the BLL didn't do exactly what was expected.

We ended up with the following abstraction;

public interface IServiceAssemblies
{
    Assembly GetAssemblyHierarchyForPackage(Package package);

    IEnumerable<Package> GetUserFleet(User user);
    IEnumerable<Namespace> GetNamespaces();
    IEnumerable<Parameter> GetNamespaceParameters(int assemblyId, int namespaceId);
    IEnumerable<Country> GetCountries();
    IEnumerable<Language> GetLanguages();
    IEnumerable<ServiceRegion> GetServiceRegions();
    IEnumerable<Type> GetTypes(int parentTypeId);
    IEnumerable<DataCollectorAssembly> GetStandAloneDataCollectors();
    IEnumerable<Type> GetListOfEquipmentTypes();

    void Save(Assembly assembly, DeleteClipboard deleteClipboard, User user, ref IList<Assembly> savedAssemblies);
    void Create(CustomerAssembly assembly, User user, ref IList<Assembly> savedAssemblies);
    void Create(DataCollectorAssembly assembly, User user, ref IList<Assembly> savedAssemblies);
}

Now this really is an abstraction! - it's not some pointlessly introduced service or interface that just does pass-through method calling or to facilitate testing. It's there to allow the abstracting away all the concepts I'd normally expect an ORM to handle. Concerns such as:

• Caching of entities,
• Lazy loading of entities,
• Change tracking of entities,
• Mapping of entities to & from relational model.

The implementation of this interface is over 1000 lines of pure procedural code and you can see from the interface there is a clear division between the queries & the commands, put simply they represent CRUD methods by another name.

I would have preferred not to have written any of this code. Not only did we have to implement these concerns but we had to deal with a hierarchical relational model that used tables to store multiple different business entity types that required re-cursing the hierarchical structure to determine the entity type - WTF!

Read More