Articles

One of the pillars of the Windows Store apps guidelines is "win as one" that remembers much more the Three Musketeers by Dumas than something related the software development. Instead, it is an important concept brought into the scene by Windows 8, that is really simple to understand. The fact is that, before windows 8, every application had always tried to embed so many functions that are not strictly related with the domain they are done to manage. As an example you can think at a photo album application.

Welcome to part 5 of this series on background processing in Windows 8 applications. In this part, we are going to explore an option to transfer files in the background. With the specifics that surround the process lifecycle of Windows 8, downloading or uploading a file in a Windows app isn’t possible without a specific option in the framework. This option is often referred to as the Background Transfer API. This API is the focus of this article.

The need for the Background Transfer API

In part 1 of this series, we have covered the process lifecycle of Windows 8 Store apps.

This is part 5 in the series WinRT Business Apps with Prism.

Introduction

In this article, I am going to show you how to use the client side validation mechanisms of Prism for Windows Runtime. One challenge you face when you sit down to write a business application with WinRT is that you will probably have a fair amount of data entry in a business application. But then you will quickly discover that unlike WPF and Silverlight, which had great support for input validation through features in the Bindings and controls, WinRT has none.

Welcome to part 4 in this series on background processing in Windows 8. So far, we’ve covered the lifecycle of applications in Windows 8, regular background tasks and how we can “upgrade” an application to become a lock screen app. That last item there was the focus of part 3. But we finished that article with a cliff hanger… We had seen how we can allow an application to post badge updates on the lock screen. But we had done so from the foreground application. However, this article series is all about background processing… In this 4^th part, we are going to extend the lock screen example so it will now be able to send updates from a background process to the lock screen.

In the previous article, we’ve covered background tasks in Windows 8. The background tasks we’ve covered are what I refer to as regular background tasks. With that I mean, they only run when a specific system-event is triggering (indeed a so-called trigger). While they are perfectly useful in some scenarios, some other scenarios require that we have more control over the execution of the background task as well as get more resources assigned for the task. For these cases, creating a lock screen application might be a solution.

This is part 4 in the series WinRT Business Apps with Prism.

Introduction

In this article, I am going to cover the loosely coupled communication mechanism from the newly released Prism for Windows Runtime, called PubSubEvents. This communication mechanism is also known as EventAggregator because it is based on the design pattern of the same name. If you have had exposure to Prism 4, then you might also be familiar with EventAggregator from there.

In the last article in this series, I've discussed about the use of a much more reliable solution to write effective code in Javascript, using Typescript. When you deal with solutions that are more than a simple exercise, this need becomes strong because you have the requirement of making your code strong and effective in the shortest time and in this scenario Javascript is not a safe way.
In this scenario, the Windows Store apps, let you to create reusable components, called "Windows Runtime Component", that may be written using C# or C++.

In the first article of this series on background processing in Windows 8, we looked at how applications in Windows 8 execute. We learned that Windows itself is taking care of the process lifecycle instead of the user and that it is the job of the developer to include code that saves state so that the user isn’t aware of the fact that the application gets suspended or terminated by the system. Understanding this new lifecycle is vital in learning how we’ll need to write code that runs in the background: an application that’s not in the foreground (running as the main application) isn’t capable of executing any code.

I'm pretty sure you agree with me when I say that Javascript is and hard bet for real world applications. No matter it you are very skilled with this expressive language, the danger of introducing bugs is always behind the corner, and too often these are so subtle to result difficult to discover and they become evident only when we get to the production stage. This is mostly because Javascript does ot have a strong type checking, so you can write code that does unwanted assignment from numeric to string or viceversa, but also because it isn't a real object oriented language, so to emulate these paradigms you have to rely on complex structures that make the code very hardly maintainable.