What Windows Runtime Can Teach .NET Developers?

Introduction and Background

C# programming language has evolved too much in these years and many frameworks and platforms have been created and developed that support C# language as their primary programming language. Indeed, C# was released with .NET framework but has grown out to support Windows Runtime applications, ASP.NET applications, many .NET framework platforms such as WPF, WinForms, etc. I have programmed for all of these frameworks, taught beginners in these frameworks and also written a lot of articles for these frameworks. However, the framework that appealed to my interests the most was Windows Runtime. Windows Runtime is the new kid on the block with an object-oriented design and performance factor much similar to that of C++ applications.

At a higher-level, it seems very simple, easy and straight-forward application development framework. At its core, it has great amount of validations and check points and most of the times, it is a pain. I remember the days when I was developing applications for .NET framework. WPF, WinForms, ASP.NET and other similar ones. I did have a few problems learning and starting, but there was one thing: the underlying framework was a very patient one. They never showed hatred for beginners or newbies. But when I started to write applications for Windows Runtime, I found out that it had no patience in it, at all. It was like, do this or it’s not gonna work.

In this post, I am going to collectively talk about a few things that Windows Runtime may teach C# programmers, for a better overview of the applications that they are going to develop.

1. As a Framework

Windows Runtime came into existence way after .NET framework itself and the child frameworks of .NET framework. But one thing that I find in Windows Runtime is that it is very much based on asynchronous patterns for programming. Microsoft never wanted to provide a good UI and UX but to leave out the performance factors.

One of the things that I find in Windows Runtime is that it still uses the same philosophy of C# programming language. But, adds the asynchronous pattern, too much. Not too much in a bad way, but in a positive way. The benefit is that you get to perform many things at the same time and let the framework handle stuff. So a few of the things that it teaches are, that you should always consider having tasks when there is a chance of latency.

1. Network
2. File I/O
3. Long running tasks

These are the bottlenecks in the performance. Windows Runtime allows you to overcome these. .NET Framework also uses the same mechanism, but developers typically leave out that part and go for the non-async functions. Bad practice!

References

For more on asynchronous programming, please refer to:

1. Diving deep with WinRT and await
2. Asynchronous Programming with Async and Await

2. Modularity

C++ programmers have been using modular programming, developing small snippets of codes and then using them here and there. Basically, modularity provides you with an efficient way of reusing the code in many areas of the application. Windows Runtime has a great modularity philosophy.

The foundation has been laid down on categories, and under those categories there are namespaces that contain the objects that communicate and bring an outstanding experience for the developers.

C# is an object-oriented programming, which means that even if you’re forcing yourself to have a single source file, you are still going to have multiple objects, working collectively for each of the purpose of that application.

Yet, it is recommended that you keep things where they belong.

References

1. Windows API reference for Windows Runtime apps
2. Modularity

3. Simplicity of Development

I don’t want to lie here, Windows Runtime is simple, it takes times to understand its simplicity. ;-)

When I started to write applications for Windows Runtime framework, I did not understand the framework or how to develop the application. That is because I was fond of straight-forward small programs. Windows Runtime is a beast, a humungousaur, with its handles hanging down to the developers through the interfaces of C# language.

Windows Runtime has everything already set up in different areas. Like, the views, source code, capabilities, properties, resources and much more.

Visual Studio brings a way more simpler means of development. I mean, Visual Studio handled everything,

1. Managing the source code.
2. Managing the output directories and how binaries are generated.
3. Managing the visual items; the image assets may be difficult to add, Visual Studio makes it really very easy to add the assets of different sizes.
4. The properties and manifest of the application is also written in XML. But Visual Studio makes it really very simple to edit and update the manifest of the application.

While building applications for other platforms and frameworks, like WPF, we can use the same philosophy of Windows Runtime to build a great project and package directory. The settings and configuration files can be kept separate to make it simpler to build the development process.

4. Keep all Architectures in Mind

.NET Framework developers don’t have to worry about the architecture that they are going to target. That made them forget the way that application would be targeted on multiple devices and environments. Windows Runtime is not like that. Windows Runtime generates multiple binaries for multiple environments, multiple architectures and devices.

1. x86
2. x64
3. ARM

These are a few of the configurations for which binaries are generated and since the code that gets generated in a native one, the code must match the architecture, otherwise, the results are undefined.

However, implementing the multiple architecture pattern would also require more manpower, more time for testing and implementing the patterns. Windows Runtime in Visual Studio has all of that already supported, but the thing is, you need your men ready for any new framework to be included and tested on.

5. You May Want to Test It Again!

Before, Windows Runtime, I thought, if everything works correctly. It is going to work anyways. But, ever since I had started to write applications for Windows Runtime and Windows Store, I forgot that mind set and wanted to ensure that it passed all of the tests that it must undergo. That all started when I was about to upload my application, “Note It! App” to Windows Store. Application was passing all of the tests in Debug mode. Yet, when it was tested in the Release mode, it failed many of the tests.

Note: I am not talking about the Windows App Certification Tests.

The thing is, the code in the Debug mode has a debugger attached, which knows when something is going wrong and tells the developers about it and we can fix it. In Release mode, it is not the same. The error checks, the memory segmentation and other stuff in Windows Runtime is not same as it is in .NET Framework. .NET Framework uses Just-in-time compilation and performs many checks. However, in Windows Runtime, that is not the case. Everything is pre-compiled to overcome the JIT latency; delay.

That is exactly why you should build the application in debug mode. However, always test the applications in Release mode. If you test the application in debug mode, you will skip a few of the key points in your application where it needs to be checked against.

Also, at the end, the App Cert Kit would be found useful to test if other tests, like resources, binaries and signature packaging is all well.

References

For more about it, read these:

1. Release IS NOT Debug: 64bit Optimizations and C# Method Inlining in Release Build Call Stacks
2. Debugging Release Mode Problems

Points of Interest

No developer wants to publish their buggy and faulty application on the Internet. I try not to publish the application until it has passed every possible condition of test. However, no software is 100% bug-free and perfect solution.

In this post, I didn’t mean to target Windows Runtime as an ideal case for solution building, instead I wanted to just share a few of the great cards it has up its sleeves. .NET framework is simple, easy and agile to build on. But agility may drive you insane someday sooner.

These are just a few of the things that you may want to keep in mind while developing a new application. Always keep these things on mind, and write applications by keeping these things in mind.