Last week, I described a programming project that I’m starting this year. It’s a time tracking app that not only records what you decide to spend time on, but also tries to influence those decisions.
I’ll get into the initial coding details next week. This week, I’ll expand on the technology stack that I’m using.
Universal Windows Platform (UWP)
The first decision to make when picking the technology stack for an app is what devices you want it to run on. This defines the target audience, and influences the user interface as well as subsequent technology choices.
The target audience for my app is a knowledge worker (such as a developer) who wants to track the time they spend working at a desktop or laptop computer. My priority is not general time tracking of all daily activities. So having a phone- or tablet-based app is out of scope for now.
What do developers use on their desktops and laptops? The 2016 Stack Overflow Developer Survey lists four desktop operating system types:
- Mac OS X (used by 26.2% of respondents)
- A version of Windows (52.2%)
- A Linux distribution (21.7%)
Windows is still the clear leader, though the survey reports that the year-over-year trend is in favor of Mac OS X. Nevertheless, since I’m a Windows user, I’m going to drill down into that option.
For the latest Windows release, Windows 10, the newest application architecture is called Universal Windows Platform (UWP). Part of the appeal of UWP is that it can target multiple devices (e.g., phone, tablet, and desktop) with one codebase. That might be useful for my app at some point, but for now the main benefit is that UWP is a modern option for building a Windows 10 desktop app.
Getting back to the developer survey results: 20.8% of respondents use Windows 10 as their development environment. A further 8.4% use Windows 8.x. That’s a famously unpopular version of Windows, so I suspect that many of those users are thinking of upgrading. That adds up to 29.2% of developers who might soon be in a position to try out this app. It’s not an overwhelming number, and wouldn’t be a great number for a for-profit venture, but it’s far from a niche market. And as an open-source experiment that I plan to use for my own purposes, it’s reasonable.
Why not build a web application that can run on any platform? For a single-user application, that’s not a good trade-off. A desktop application is simpler to build and provides more straightforward access to operating system services. That may come in handy for advanced features like getting a list of what programs are running and what web pages are open. So UWP it is.
C♯
UWP apps can be developed using several programming languages, but C# was an easy choice for me. It’s a language I use a lot; it doesn’t have Java’s syntactical annoyances; and there are plenty of online examples on how to use it to build UWP apps.
Extensible Application Markup Language (XAML)
XAML is a markup language used to define the user interface of a UWP app, as HTML is used to describe a web page. XAML can be used to define buttons, textboxes, grids (for layout), lists, and other controls. It can also specify the relationship between the controls and code elsewhere in a UWP project, using a process called binding.
Binding is a way to associate a XAML control with a method or property in code. For example, a textbox can be bound to a property so that when the user types in the textbox, the property is updated. Another common binding is between a method in code and the click event on a button. When the user clicks the button, the method is called.
Visual Studio has a XAML editor that keeps a visual design and its associated XAML in sync: You can drag and drop controls into a visual editor and the XAML markup updates automatically. And you can update the XAML manually and see the effects in the visual editor. This provides both the ease of use of drag-and-drop design and the advantages of a text-based markup file that can be tracked in a version control system.
Model-View-ViewModel (MVVM)
UWP doesn’t enforce a specific program design. Developers are free to use the platform as they see fit. However, some designs fit better than others. Model-View-ViewModel (MVVM) is an architectural pattern that was invented to work with Windows Presentation Foundation (WPF), a predecessor to UWP that also uses XAML for defining its user interface.
The purpose of MVVM is to separate application code into groups of related components, each with a specific role. Here’s how MVVM works in UWP apps:
- The Model handles business logic and communication with the database.
- The ViewModel takes data from the model and organizes or formats it in a way that is convenient for the user interface.
- The View defines the user interface. Data that the UI needs to read and write comes from the ViewModel through data binding.
Separating these three concerns helps a developer focus on one thing at a time when implementing an application. Or for larger projects, it allows multiple developers to work on a system while avoiding code conflicts. It also facilitates unit testing, since components can more easily be tested in isolation.
Entity Framework (EF)
A time tracker app needs to store data like task names and start/end times. Since computers crash and get restarted, it’s not good enough just to store these in memory. We need some kind of persistent data store, and the Model needs a way to talk to that data store.
For UWP apps, the recommended way to connect the Model with a database is Entity Framework (EF). EF is an object-relational mapping (ORM) framework, a way to use an object-oriented programming language to access a relational database without having to manually write code to translate between the object model and the data model. Since object-oriented programs and relational databases represent data in different ways, having an ORM do the translation can simplify the programming process. It allows the programmer to think in terms of the object model without worrying about how it is represented in the database.
There are some performance pitfalls to watch out for when using an ORM. Unlike a compiler, which can generate faster assembly code than almost any human, ORMs tend to create less than optimal queries. An understanding of what’s going on under the hood can help avoid these types of problems.
SQLite
We have reached the bottom of the technology stack: the database. SQLite is a popular embedded database engine that is recommended for local storage of UWP app data. In addition to shipping with Windows 10, SQLite has been used for years by a number of widely-used programs, including Chrome and Firefox.
The Entity Framework project maintains a database provider that allows EF to be used with a SQLite database.
Technology
Of all the elements in this planned technology stack, I think UWP is the most risky. Although it has been around for a couple of years, it’s still very new compared to other .NET options for building Windows desktop applications, like Windows Presentation Foundation (WPF) and Windows Forms.
Fortunately, WPF also works well with the other patterns and components (C#, XAML, MVVM, EF, and SQLite). If I run into insurmountable limitations of UWP, I can always switch to WPF without throwing away too much work.
Next week: getting into the code.
(Image credit: drawn by me + the SQLite logo (public domain))
