Articles

When you develop a Windows Store application, a big deal is to find a place for every feature, connecting together the available space with a reliable user experience. Together with the canvas of the application, Windows Store apps give you some other "surfaces" where you can collocate your commands and features, most of the times following the strict rules that have been collected under the UX Guidelines. These so called "surfaces" have the intent of create additional room with the purpose of leaving the interface more clean and simple, without omitting important features that are discoverable using common gestures.

Up to here, I have always talked about XAML versus HTML and about C# versus Javascript, comparing features and functionalities. Working in the HTML side of the story, there is another actor of which we have to be aware of. It is the CSS stylesheet that is automatically created, as a common point to contain user interface aspects that apply to the whole application.

It is a very common practice in HTML programming to set visual aspects of elements using a cascading style sheet and it is really important to centralize styles and make them much more maintainable.

Almost every application has some kind of settings that enable the user to customize his experience, tuning the application behavior to his preferences. This is an important matter and, also if often settings fall under a small set of known locations, at the first sight it is not easy to understand where they are for an untrained user. Tools->Options, Edit->Preferences, or some strange settings button that is presented somewhere in the user interface. These and other are common locations where we are use to see, a little bit after having installed a new software and we simply need to change a unit measure, a font size and something else.

It’s that time again… We’ve reached the last part of this article series on background processing in Windows 8. So almost time to say goodbye for now!

But we’re not there yet. In the previous module, we’ve covered background downloads. We’ve seen that to enable these, we need to use a separate service that keeps transferrin our files when we’re not actively using the application (in other words, have it open as the main app on screen). But what if we want to have an app that plays audio such as Media Player? We probably want to create such an app so that it plays audio when we’re using the app but also so that it continues playing our content when we’re doing something else.

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.