Posts about the C# language itself, including use, abuse and features.
Posts about the C# language itself, including use, abuse and features.
After earlier defining our logging interface, some readers posed a few questions about how it would work from a consumers perspective. So before we look at implementation details, let’s look at how we’ll instrument our code and what the output might look like.
As we progress building the WordTutor application, some of the functionality will be a great deal more complex - and that requires a better way to see what’s happening inside the application than we’ve had to date. It’s time to implement some logging.
Following on from our previous post on convention testing we can extend the conventions by considering the standards we want to follow when we write methods on our immutable types.
The Redux architecture we’re using for our application state relies on all our state objects being properly immutable. So far, we’ve relied on nothing more than self-discipline to ensure no mistakes are made. By adding some convention testing to our project, we can enlist some help in avoiding common errors.
If you’ve tried out our application as it stood after last week’s post, you may have noticed that the user experience for modifying a word is a bit suboptimal. After selecting a word, you have to separately press the Modify button. Can we do better?
The existing model class
ModifyVocabularyWordScreen only handles the creation of a new word. We need to modify it to support the modification of an existing word as well.
Here’s an odd warning that came up when I was working on last weeks Code Gardening post:
Continuing our the upgrade process from last time, in this post we’ll explore the changes required to our
Up until this point, we’ve relied exclusively on data-binding for the link between our view-models and our views. While data-binding handles a lot of scenarios well, it doesn’t support buttons, menu items and so on.
With subscriptions wired up to keep our view models updated, we can run our application and start clicking around. When we select a word, we can trace through the flow of messages to see how everything updates. But, it’s easy to crash. Let’s debug that crash and work out how to make the application more robust.
Now that our Redux store supports subscriptions, we can register to update our existing view models, allowing them to automatically stay current as our application state changes. The changes to each will be similar, but with a few variations on the common theme.
One of the problems we currently have is caused by lack of updates - our application model can change without our view-models being notified that the change has happened, leaving our user interface showing stale information. To solve this, we’ll extend our Redux store with subscriptions, to allow each view-models to be proactively notified when things change.
We saw last time that setting up dependency injection for our viewmodels involved a small number of moving parts. The same applies when applying dependency injection to our views, but with a few additional complexities.
Based on the foundation from last time, we can now turn our attention to our view-models. How can we use our dependency injection framework to construct each view model on demand?
To this point, we’ve been able to run each of our screens by hand-coding the necessary object initialization. We could continue this as we move forward, but the complexity would grow with each additional screen we complete. Instead, let’s take the time to configure a dependency injection framework that will take care of the complexity for us.
In addition to the unit tests we’re already writing for each of our core classes, we should also write some integration tests to ensure our types interact properly.
When I got to this point of the series, I expected to be writing about some interaction testing - checking that our messages triggered the right transitions between screens.
For our second screen, we’ll create a browser to show all of the words in a single vocabulary list. Let’s start with a small bit of design, so we know what we’re aiming to build.
When I went to write the code for our next view model (
VocabularyBrowserViewModel), I ran into some problems with our original
ViewModelBase. Let’s visit those problems and look at how they can be resolved.
First light is the term used for the first time that an observation is made through a new telescope (or other astronomical instrument). Lets get our application up and running.
Leveraging the add vocabulary word view model from last time, we now turn our attention to creating the associated view. Once we have that, we can wire everything up into a working WPF application.
With the add vocabulary word screen that we defined last time, we can now look at the implementation of the related view model.
Let’s look at the first of the screens we need to build for our application - the Add Word screen, used (surprisingly enough) to add a new word to the list of words we’re currently viewing.
Before we can start adding screens to our application, we need to set up some infrastructure for our WPF specific classes. In order to keep the
WordTutor.Core technology independent, we’ll do this by creating a new project.
|Static Analysis 13 Apr 2019|
|Redux Store 06 Apr 2019|
|Commandline Builds 30 Mar 2019|
|Application Model 23 Mar 2019|
|Vocabulary Set 16 Mar 2019|
|Vocabulary Word 09 Mar 2019|
|WordTutor Revisted 02 Mar 2019|
|Converting a List to a Queue 23 Feb 2019|
|Explicit Interfaces and Delegate Properties 16 Feb 2019|
|Extension Methods 19 Jan 2019|
|Generating Hash Codes 12 Jan 2019|
|The Problem with Equality 05 Jan 2019|
|Queue Equality 29 Dec 2018|
|Smarter Queue Enumeration 22 Dec 2018|
|Queue Enumeration 15 Dec 2018|
|Queue Testing 08 Dec 2018|
|Creating Branching Nodes 01 Dec 2018|
|Two Dual Item Queues 24 Nov 2018|
|Simple Queues 17 Nov 2018|
|Enqueuing Values 10 Nov 2018|
|Dequeuing Values 03 Nov 2018|
|Designing the External API 27 Oct 2018|
|Introducing the Priority Queue 20 Oct 2018|
|A better approach to reflection 13 Oct 2018|
|Avoiding Magic Strings 06 Oct 2018|
|Capturing Validation Metadata 29 Sep 2018|
|Modelling Validation Metadata 22 Sep 2018|
|Validation Metadata 15 Sep 2018|
|Extending validation with warnings 08 Sep 2018|
|Validation recap 25 Aug 2018|
|Equality of validation 18 Aug 2018|
|Short-circuiting validation 11 Aug 2018|
|Aggregation of validation 04 Aug 2018|
|Recovery of validation types 28 Jul 2018|
|Basic validation 21 Jul 2018|
|Why we need better validation 07 Jul 2018|
|A question of struct performance 30 Jun 2018|
|Equality has Symmetry 17 Mar 2018|
|Type Miscellany 05 Mar 2017|
|Testing Immutable Types 25 Feb 2017|
|Factory Methods 18 Feb 2017|
|Queue Concatenation 11 Feb 2017|
|Complex Queues 04 Feb 2017|
|The Problem with the Simple Queue 28 Jan 2017|
|Enumeration of Queues 21 Jan 2017|
|Reversing Stacks 14 Jan 2017|
|Simple Queues 07 Jan 2017|
|Queues 30 Dec 2016|
|Stacks Miscellany 22 Dec 2016|
|Stack Equality 09 Dec 2016|
|Enumerating Stacks 03 Dec 2016|
|Stacks 19 Nov 2016|
|When (not) to use Var 16 Jul 2016|
|Semantic Types Redux 05 Jun 2016|
|Semantic Types in C#6 27 May 2016|
|Property Enhancements for C# 20 Dec 2015|
|Language Extensions for C# 19 May 2014|
|When should methods be Static? 09 Oct 2012|
|Of Method Naming and more 29 Sep 2012|
|Someone needs an intervention 16 Dec 2011|
|CallerInfo in C# 5 08 Dec 2011|
|Regions in C# 16 May 2011|
|Lambda expressions and Block syntax 15 Apr 2011|
|Parameter Attributes and more 05 Feb 2011|
|Elegant.Data 19 Oct 2010|
|Doing less with LINQ 30 Jun 2010|
WCF and IList|
|Specialist Classes 22 May 2010|
|Attack of the Lazy Coder 20 May 2010|
|A Discovery in Linq: Lookup 11 Feb 2010|
|Co- and Contra-Variance in .NET 3.5 15 Sep 2009|
|When to use Var 26 Mar 2009|
|Struct Weirdness 11 Feb 2009|
|Contravariance and Covariance at last 29 Oct 2008|
|Spec# 30 Apr 2008|
|Lambda Events 22 Mar 2008|
|No longer the C# we knew 21 Mar 2008|
|Rare C# 12 May 2007|
|Generics in .Net 28 Jan 2004|