I have developed mostly web apps in my programming career. There have been a few sporadic opportunities to develop desktop apps but mostly small, uninteresting projects. So when a client came up to us and asked us to develop an offline desktop client, I was taken aback. This is not our comfort zone. Yes it’s still .NET, it’s still C# but XAML and MVVM?
Needless to say, we went for it. After months of whirlwind requirements and intensive coding, we are now doing User Acceptance Testing (UAT). We are still not out of the woods but I’m confident that it’s all downhill from here. However, the last few months weren’t easy.It was intense and exhausting. We had to learn new things in crunch time. These are the things that stuck.
Lock down your OS requirements
To mitigate support and deployment headaches, we initially set Windows 7 with SP1 as a minimum requirement for the application’s operating system. At the very least, this would ensure a fresher .NET Framework. However, OS version is just one of the problems. We overlooked the microprocessor architecture: most of our client’s users are using 32-bit Windows. Since developers typically use 64-bit OSs, we have to recompile the application for 32-bit OS. We also looked for 32-bit version of SQL Server Express. While these are fairly trivial to solve, we could’ve save ourselves a lot of time had we anticipated these requirements.
Asynchronous programming is your new best friend
It’s easy to take for granted how modern web technology stacks support asynchronous right out of the gate. While WPF has rich support for asynchronous programming, baking it right into your application is not trivial. Your team needs a solid understanding on how to use asynchronous programming to build a responsive and desirable user experience (UX). Previous experience is definitely beneficial. Lastly, picking the right technology strategy is also critical. For example, using Model-View-ViewModel (MVVM) framework to build the app is one of the best decisions we’ve made in support of making responsive application. MVVM supports Asynchronous Commands that can be tied to a UI control asynchronously.
Installers can be tricky
Creating an installer for a WPF application is painless and easy. Visual Studio does everything for you. It finds all the required libraries of your application and bundles them with the installer. When you install this to the user’s machine, any pre-requisite will be automatically downloaded. It should be a perfect strategy. Unless when it’s not. This became one of the most painful tasks during testing. It turns out because of our client’s strict borderline-to-poor intranet settings (see below), downloading pre-requisite components during installation became a hair-pulling experience: our client’s internet connection is throttled therefore it’s glacially slow. It took us almost a day to download a 22MB cumulative patch for SQL Server Express.
This could be solved in several ways. Obviously, an improved policy is the best way. However, that typically involves approval from layers and layers of management. If you don’t want to deal with that, download and bundle components ahead of time.
Strategize when picking local persistence
Local persistence has two obvious benefits: offline mode and performance boost through local caching. There are myriad of options and depending on your requirements, picking the right strategy can be daunting. You can opt for a full-fledged relational database server like SQL Server Express (which we did) or MySQL however, typically entails big checklist of pre-requisite to the user’s machine. You can also opt for a file-based database like Microsoft Access or even Microsoft Excel but this could mean licensing cost for your client. Lastly, you can pick a more passive data storage like SQL Server Compact or SQLite—something I wished we considered more. The setup overhead for these embedded data storage is vastly minimal compared to a full-fledged RDBMS like SQL Server Express. Embedded database are usually free to download and distribute.
Corporate settings
This is what caught us off guard. I’ve seen how hostile corporate intranet settings can be to applications but I didn’t realized how difficult it was until now. The best way to solve this issue is to make sure that the business process owner (the owner of the application) understands the requirements of their application. You can work your way around the settings but it won’t get you far. They need to agree with you on the resources your application will be using in their environment. They also need to get on board on what kind of permission your application needs. Resolving these kind of issues give your application stable room without resorting to crazy solution.
Finishing a difficult project is an exhilarating experience for me and I could honestly say that this is one of the most challenging projects I’ve ever done. Imagine how amazing this makes me feel.