Redeveloping my Word Tutor spelling application using .Net Core 3.0.
Redeveloping my Word Tutor spelling application using .Net Core 3.0.
Let’s try an experiment - taking many of the things I’ve been blogging about over the past few years and applying them to the design and build of an actual application, with the source code published step by step.
To begin our little project, we need to create our initial project structure. Once that’s in place, we can create the first class from our application model -
VocabularyWord last time, our next step is to create
VocabularySet, a container for many words.
Before we get much further in this project, we should set up command line builds while things are still simple. It’s easier to enhance the builds step by step as required than to configure a complex build system in one go.
At the core of the Redux design pattern is the store, a central place for storing the current state of the application. There’s only ever one store for the entire application. Changes in state are made by dispatching messages to the store that are processed by a reducer.
I’ve long been a fan of static analysis tools. They can act as a co-pilot, keeping an eye on things while you work, helping you to catch common types of problems. Let’s add (and tune!) some tools.
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.
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.
With the add vocabulary word screen that we defined last time, we can now look at the implementation of the related view model.
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.
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.
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.
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 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.
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.
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.
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?
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.
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.
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.
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.
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.
Continuing our the upgrade process from last time, in this post we’ll explore the changes required to our
Here’s an odd warning that came up when I was working on last weeks Code Gardening post:
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.
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 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.
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.
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.
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.
To implement the logging interfaces described earlier, there are some issues we need to consider. There are two different usage patterns we need to support, plus we need to support concurrent use, and avoid code duplication.
For the WordTutor application to work, we need to be able to read words (and letters) out loud to our student. To power the speech synthesis, we’re going to integrate Azure Cognitive Services into the application.
At this point in the development of the WordTutor, we need to properly incorporate speech generation into the application. We could hack and glue it into place on top of the existing architecture, or we can integrate it into the existing structure in a clean way.
Based on the interfaces we defined last time, let’s integrate middleware functionality into our existing Redux store. This will lay the foundation we need for asynchronous speech generation.
Now that we’ve modified our Redux store to support middleware, we have the foundation needed to integrate speech synthesis into the main flow of our application.
With our speech infrastructure in place, our next step is to hook it up with our existing maintenance screen. This will allow our users to test out pronunciation as they make changes.
If you’ve been playing around with maintenance screen and the speech integration that we completed last week you may have noticed that there can be a noticeable lag between the time you press a play button and when you hear the speech.
After our recent introduction of caching, I had an interesting conversation with a friend about the way I’d written the code. He was persuasive that the approach I’d taken had some significant issues and that it was worth taking the time to address them.
It wasn’t very long after my prior update on caching that a friend informed me that the code has a race condition. Yes, the same friend who persuaded me to update it last time. Worse, during a Skype call, we identified code that would outright fail for an independent reason.