The WPF/Windows App Development experience – Part 1: Choice of Technology

We are developing a tablet application as a tool for record data, where a smaller Windows embedded device was used (in German: Ablesung von Messgeräten, Zählern, und Ergebnisse von Rauchwarnmeldertests). Due to the existing technology stack, switching platforms was out of the question, but switching to (Windows 8/10) consumer tablet hardware has immediate benefits to the customer, like the vastly increased screen size (bigger fonts, more stuff to display), and a huge reduction in the hardware costs (you can buy a new tablet for the price of a display replacement of the old device).

Microsoft promises easy and native, touch-ready App development for Windows 8 and 10. While touch works fine, other limitations made us choose the standard Windows application development environment with Microsofts GUI framework Windows Presentation Foundation (WPF).

The first issue we ran into with App development was that the standard GUI library is completely missing a data grid. Microsoft seems so focused on big, flashy, web-backed apps (the ones you see in demos and pre-installed on your device) that it does not support data grids for inputting or displaying datasets rather than simple images or labels. This seems to be by choice, as the Windows 8 UI principles target touch-first, and provides examples for navigating lists. Nevertheless, we looked at alternative UI approaches to our specific application and decided to still pursue a data grid UI, as it compresses a lot of data into much smaller space (specifically, you will have less navigation overhead).

As the App framework did not provide a data grid, we looked at third party libraries. Two big libraries in particular were tested within the application prototype, but even with only test data showed shockingly bad performance, and in one case, support resigned from any possible improvements of this.

Another problem is Microsofts app deployment policy. As a private, proprietary application we obviously do not want it to appear as a public application in the Windows store. As a tablet software with its users using it mainly at locations different from their home and company, putting it into a Windows domain would be problematic as well. Even if we would put it into the company domain, I doubt it would be easy with the licensing and administration hassle of Windows.

Yet another aspect are hard technological restrictions. The application group features a .NET client and server application, MS SQL Server databases, and ASP.NET web applications, as well as the WindowsCE / now Windows 8 mobile application using MS SQL CE embedded databases. The data contained in the databases is synchronized with MS Sync.

One impression that was experienced time and time again is that Microsofts documentation is unspecific, scattered, missing important information or links to further documentation, and sometimes even wrong – in general, its simply bad documentation.

This also showed when we tried to find out which Microsoft technologies can operate with one another. There are hard restrictions between MS Sync, SQL CE, Entity Framework, .NET, Windows App development (which can not even handle SQL CE mind you, as it uses a subset of .NET) and worst of all, an incompatibility of SQLCE 3.5 SP1 and SQLCE 3.5 SP2 because both are distributed – to this day! – with the same installation ID, so you can not install them both on the same machine. This would be no problem, if they were actually compatible in functionality. They are if you use it in its default state. However, as soon as you enable the change tracking feature required for MS Sync, table names do no longer match between SP1 and SP2, effectively breaking compatibility. This leads us to the second impression experienced time and time again: Microsoft technology works great for simple cases, but gets really complicated (or even breaks) once you dive deeper into it and use more of the edge cases and “special” features.

Worst of all, the SP1 vs SP2 compatibility issues are not documented at all. Secondly, the version (in)compatibilities between MS Sync and SQL CE as well as SQL Server are not clearly and obviously documented. One would think MS Sync is a technology put “on top” of databases, and thus, MS Sync documentation should have documentation on its requirements and compatibilities. Unfortunately, you’ll have to check the release notes of all the libraries and all their versions involved to get an idea of what the compatibilities probably are. Some incompatibilities are not as hard as others; you can use third party libraries to make the Entity Framework work with SQL CE 3.5 (which is not even the newest version), and for MS Sync Microsoft seemingly dumped their efforts towards a new/next version as open source “samples”.

We had to create a huge diagram of possible technologies and their versions, to visualize our choices of mobile/client and server technology. We also considered writing our own ORM and using SQLite. After a lot of searching and testing, this made us able to consider two possible “paths” of technology.

If you think about FOSS, there seem to be far fewer issues of this kind. Compatibilities are clearly documented, and they are much rarer.