Windows Store Apps - The good, the bad and the ugly
Back in late december 2013 I got to write my first Windows 8 (8.1) Store app. The company I am working in has a regular trade fair, and I wrote an app as a GUI frontend to our backend. I don't want to get into too many details here, but basically the architecture is this:
- The backend is a mature product that has been on the market for 15+ years. It is a Client/Server architecture, where the Server "does all the work", and the Client controls the user experience
- The Server exports an XML/RPC web service
- The W8 Store app connects to the web service, visualizes information and controls interaction with the devices
The good
In the following I want to elaborate a bit on my experiences and thoughts around Windows Store Apps, from what little experience I have now :)
Customer feedback
We bought a couple of Surface Pro 2 tablets (which are really notebooks disguising as tablets) and ran the app on the trade fair. Response was overwhelming: people loved the GUI, it worked like a charm, and - compared to HTML5 apps - responsiveness and overall feel. So in that sense it was a definite success.
The code experience
Programming the actual app was a very pleasant experience. The simulator is pretty good, Visual Studio 2013 is a definite improvement over previous versions, and code turnaround couldn't be better. (Though in retrospect it probably helped that I had a new PC with a top-range I7 and a raid SSD ;)
I read a couple of books on App programming to get in the mood: I can definitely recommend Progamming Windows by Charles Petzold - he's oldskool and he's a master, and it shows. I can definitely not recommend Windows Runtime via C# by Jeffrey Richter. Yes, the book contains lots of background facts you don't find easily somewhere else, but reading the book made me actually angry: it is written very much in a fanboy style apologetic of things worthy of obvious criticism. Don't believe me? Here is an actual quote from the book:
Users typically have files they care deeply about ... Windows desktop apps have always been able to access the users' files and folders arbitrarily.... ... this is not an ideal situation and it has caused users to be scared to use Windows desktop applications.
Windows Runtime via C#, Jeffrey Richter, Microsoft Press, Redmond, Washington 2013, Page 97.
Whoa whoa whoa. Users have been scared to use the Windows desktop applications because they can access files and folders arbitrarily? Why, Windows has a whopping 70% market share of desktop computers, I have been using them since the early 90s, and I have heard many complaints about Windows but the fact that programs can access files has never, not once, been mentioned. I wouldn't even have bothered complaining, but this is in a section about just why WinRT is so uptight about file access as if that were a good thing
So, Petzold yah, Richter nay.
Side note on async/await
The enforced use of async/await
everywhere makes a lot of sense: it is easy to use, and the GUI does indeed benefit from it. If you
haven't looked at it before, do it: it is a very worthwile extension of your C# skillset. Basically, what it does is it enables you to write "pseudo-synchronous"
code that is really async. I am oversimplifiying matters here, but if you had previously written code like this:
List<something> result = SomeLongRunningFunction(...)
all you basically need to add is
List<something> result = await SomeLongRunningFunction(...)
And the code can run in the background. Very neat. There are many better explanations out there, but you get the idea.
However, I cannot help being reminded of the good old days of cooperative multitasking: where applications had to actively yield processing power to other processes in order to give a semblance of multitasking. The thing is: back then it worked out most of the time, but it did not stop "programs" (as apps were called back then) from misbehaving; maybe not intentially, but maybe in the context of a program error, an abortive loop etc. So in the end everybody moved to preemptive multitasking, where the OS decides which process is scheduled to run at which point.
In a way the case with async/await
is very similar: programmers get to decide where to sprinkle their code with async/await
, and if they go wrong, the result is lag (or W8 killing their app because it is unresponsive for too long). I believe that at some point down the road something like "preemptive multicore" will emerge... Should
you, dear reader, be working on this, I'd love to hear about it!
The bad
Now, while the results were impressive, I have to point out that on a technical level things turned out to be pretty bad.
There is not a single .NET Framework
We have all come to terms with programming languages having version numbers. But at least they are growing in one direction: newer versions incorporate changes from previous versions. Not so with .NET. There are at least three divergent strains here:
- The .NET Framework as we know it, which is now at
4.5.1
and is the best documented of them all. - The subset that is available for Windows 8 Phone applications
- The subset that is available for Windows 8 Apps
To give you a very simple example, something as basic as Trace.TraceInformation
(and its friends) is simply not available for Windows Store apps. You only get Debug.WriteLine
. And it's not even pointed out
in the documentation: the
documentation for the function is in all documented .NET Frameworks, and a namespace like
System.Diagnostics
sounds pretty fundamental by the looks of it. Worse: there is a
System.Diagnostics
namespace available for WinRT apps: it just has different functionality.
I am sorry, it is probably me being stupid, but I absolutely cannot understand the logic behind it. It means you cannot have the same code in three environments: you need to change little shit like that: completely irrelevant to the actual code logic, but it is everywhere (in my code at least) and now apparently it turns out to be not portable. WHY?
Maybe the argument is security. Boy, I love security arguments: You cannot do this and that because of "SECURITY", oh, I see. But even so: if it were for security then make the function a stub. Don't just remove it and make your "standard" library incompatible. This is not rocket science, this is beginners stuff in API design.
So, issue #1 is that WinRT is just not compatible. I will refrain from commenting on the wisdom of internal design decisions like WinRT COM projections. Microsoft used to be a company that cared a lot about backwards compatibility, certainly much more so than Linux. But really when you have such a big .NET / C# Ecosystem that you've built over the years, slowly, and you have had lots of developers slowly moving to .NET / C# from Java, and then you kick them in the face and say you're essentially obsolete and you need to rewrite everything (but we won't give you all the functionality you're used to - remember file access?) then it doesn't sound like a very bright decision to me. But that may be just me.
Gaps in the functionality
Windows 8 has a new GUI, METRO, and a shiny new API to go with it, WinRT, and one would think that they strive to get you to use it. But have you noticed that even Microsofts own apps switch to the desktop? For example: you bring up Task Manager. It has seen lots of improvement in Windows 8 compared with Windows 7 - as a desktop app. Computer Management? Off to the desktop you go. Control Panel? Well, a subset is avialable, but many things simply aren't there: they are only available in the Desktop version.
The reason for this is that the security model of WinRT apps is really very very strict. It is strict to the point of belonging in a book about mental illnesses; it ought to be diagnosed OCD. Once again a simple example: WinRT does not have an API to query the battery status for security reasons. Oh, you can search for "battery" in the Windows store, and you'll find apps that "help you prolong the life of your battery". But tell you the actual battery status in a life tile? No sir, its a risk!
Now, on Windows 8 Phone applications it is possible to query the battery status, and there are pretty good apps taking advantage of this which leads me to either one of two conclusions: either the battery status of Phones is less security relevant than the battery status of Tablets, or the decision to restrict the API is stupid. You decide.
There are more things like that:
- you can do
P/Invoke
, but there is noMicrosoft.Win32.SafeHandle
. - You can do
TCP/IP
, but not on localhost. - ...
So, issue #2 is that you cannot write the WinRT apps that you'd love to write. There are tons of applications out there that are great, and make Windows great, and that couldn't have been written using WinRT. Examples?
- System Management apps like RapidEE or Everything or even my very own pserv.
- Programmers apps like Notepad++ or IDEs like Eclipse
- DAWs, because they need to access audio hardware
- Databases like PostgreSQL
- Backup apps
- And basically anything that you need for doing professional work with your computer...
I like the look and feel of "the tiles", and I have tons of ideas for apps I'd love to write, but I cannot: not because I am too stupid, but because Microsoft doesn't want me to, and somehow I think this is not right.
The ugly
OK, and now for the ugly: business integration.
I admit, I don't get this. Microsofts' main strength these days is business customers. One would think they make writing Windows Store apps as easy as possible for business customers. One couldn't be more wrong!
Ways to distribute Windows 8 Apps
In our case, we're a company that writes code that is sold to other companies together with expensive hardware. Neither our software nor our hardware are commodities, neither are meant to be distributed "in an app store". Now, along comes Windows 8 with a shiny new GUI, and the developers (read: me) write a shiny new App to go along with it. Responses are, as indicated above, overwhelming. How can I sell this?
It turns out, I cannot.
There are three ways I can distribute apps on Windows 8 Metro
- Windows Store deployments. This is obviously not what I want. As mentioned above, neither our software nor our hardware are commodities; we typically customize and tweak the software for each customers' needs.
- Enterprise deployments. Now, this is the way Microsoft wants businesses to be able to write LOB (line of business) software. With the following restrictions (remember my rant about WinRT being strict above?):
- The computers need to be domain-joined. Now, I don't know about your big company, but most companies I deal with have corporate desktops that are locked down (e.g. with customized harddisk encryption) and identical everywhere. Show me the corporate desktop that I can install on a Surface Pro 2? Ours cannot, and so this is a non-option right there.
- The computers need to be domain-joined. That means, they need to be joined to my domain. Now, I don't know about your big company, but last time I checked there was not one single big company dominating the universe, and it certainly wasn't mine.
- The licenses come in 100 packs only. This is not a big restriction, it is just a silly thing to do. I am sorry, but most likely there is not a machine out there printing App licenses in bundles of 100 only. I don't know who came up with this idea, but if anybody from microsoft is reading this: please find and fire the guy.
- Restricted Deployments. This is what we ended up showing on the trade fair: I manually installed the app with my developer account, so all tablets had to be bound to my personal account. It works, but it most certainly is not a real option.
Going forward
Ok, enough of that, let's recap.
What should happen
In an ideal world, if Microsoft wants businesses (or at least: our business) to jump to Windows 8 store apps, I think two main concerns need to be adressed:
- It must be possible to write the app you want to write.
- It must be possible to sell the app you've written
It's not very hard, but let me elaborate a bit.
Writing the app you want to write
For example, Microsoft could introduce a secondary "advanced" marketplace for apps that can do more. Maybe there could be a social component: users could volunteer to test "risky" apps. Maybe it should be possible to actively configure your system to grant more rights to apps (much like it is your decision to run as Administrator, against all good security advice: but for someone like me, for Developers, it should be an option, really.
Selling the app you've written
It must be possible to sell such an app, customized, to particular businesses, and for them to distribute it in their network, as they see fit. And no, not every software on earth is suitable for a consumer app store.
Probably all is not lost at Microsoft. Probably somebody is reading this and thinking that I am an incredible idiot, but maybe someone else thinks that I do have a point and reconsiders some of the decisions. It would be great: because I am one of those few people that actually like Windows 8.1.
GK, Feb 6, 2014