Articles

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.

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

Introduction

In the last article in this series, I walked you quickly through using commands, wiring up dependencies, and handling navigation using Prism in a Windows Store app. In this article I am going to focus on the application lifecycle state management features. I’ll show you how you can manage transient application data that you want to survive when your application gets suspended, terminated, and resumed. You’ll see how you can store objects that are properties in your view models, as well as anywhere else in your application such as transient data in a repository.

If you have been in touch with the new WinRT environment, you have met for sure a number of calls that use an asynchronous pattern to be accomplished. These usually are indicated by the "Async" suffix on the method name and they are much more frequent than expected due to the WinRT architecture. As a meaningful example, to open a simple and common message dialog, you have to use the ShowAsync method that is clearly, and unexpectly and asynchronous operation. Without focusing on the reasons of this choice that is mainly about performances and fluidity of the applications, it is clear that a language used to write Windows Store applications cannot omit to support this important pattern.

Every Windows developer knows the term "control" in the acception used into this operating system. This name is usually associated with piece of code, related to a visual component, which implements a reusable behavior. Since my first steps in Visual Basic, ages ago, these components have always permeated my work and ofter they made the success of a project, giving much more speed to the development, without losing in quality. So, Microsoft always payed full attention to this aspect which is often a parallel market for third party companies working on awesome controls to sell to people that needs effective interfaces, without paying the price of developing them directly.