Introduction (Windows 8)
Microsoft claims that Windows 8 is selling pretty well - some analysts claim the opposite. In the end it will not matter what a company or a bunch of external people will claim, but if people are willing to consider the change worth a look. There are some strong arguments in favor of Windows 8 - and I will just name a few of them:
- The system boots a lot faster.
- The system handles resources (memory, CPU) much better, resulting in more performance and a longer battery lifetime.
- With Windows 8 essential tools are already integrated like an ISO (or image) mounter.
- The task manager has been improved and there are new dialogs with useful options like the new copy / move dialog.
- Of course IE 10 is already included out of the box, which is just enough for the modern web (IE 9 on the other hand is such an outdated browser that I consider it as useful as IE 7).
- The possibility of syncing all your settings in combination with a live ID. This simplifies a lot of processes and I can imagine that this will be strengthened even more in the future (like Skydrive being integrated completely and not as an external program).
This all being said I never mentioned the new start screen (formerly start menu). In my opinion this is also a plus, since I realized that I only used the start menu for searching (enter a search query and press enter once I typed in enough letters such that has been just a single result). Therefore I focused completely on a little fraction of the screen. Thus the results had also just a tiny bit of space, making large result sets pretty much impossible to investigate. Now this is all much better. Also the overall overview is great and I get a lot of information presented right away.
But now that's it! There are also disadvantages and I will not write any line about those. In general all my hates are mostly in the direction, that the "two worlds" have been implemented as such, but under one cover. I have my own ideas on how it should have been done. In my opinion that mix is what keeps people from buying Windows 8. There are much smoother possibilities and I will never understand why Microsoft had to do it in such a dramatic way.
The right UI description language
Now to the topic... So basically we have three options:
- Write a C++ app with XAML for the user interface.
- Write a C# or VB app with XAML for the user interface.
The first options seems to be the way to go for performance sensitive applications like 3D graphics or extensive numerical computations. The second option should make porting existing LOB applications easy. The third option should make existing HTML5 web applications easy. Right?
This leaves us behind with an ethnic question: HTML or XAML? In my opinion XAML is definitely NOT the way to go in such a scenario. I have my reasons for this:
- Only a subset of the XAML from WPF has been ported (Metro XAML is more like Silverlight XAML).
- There are some severe errors in the implementation. Just to mention one (which was driving me crazy for like 2 hours): Bindings with custom objects have to be done with the source type being set to
objectinstead of the real (more specialized) type. There was no binding exception or whatsoever occurring, which made finding the error really hard.
- Some basic controls are missing in the XAML stack - like a
- I dislike the
ViewStatemanager. The implementation of this seems sloppy and requires too much code.
Those are just a few of the arguments. But I know that some people are highly in love with C# (as I am) and regarding a speed comparison (and also a development cycle), C# is the language to go. But wait a minute! What do we want to achieve?
Separation of concerns
- Write the actual model code and everything related in its own library - this one should be testable and contain all the model information. The library is written in C#.
- Create another library to create the wrapping of the (required) external functions from the model library to the UI.
- One layer is of course the UI to value binding.
- Another layer is the data to value binding (code-behind).
- A layer is required for receiving (and sending) requests from the UI to the model - this one sits in the "wrapper-assembly".
The last layer gave us several options, but in my opinion having the ViewModels in the same library makes sense. One of the reasons for this is that unit tests should be performed on this as well.