Articles

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.

If you have a minimal experience in building web sites with HTML and CSS, you know for sure that creating a decent layout is someway hard. This comes from the way the browser renders the page, privileging the horizontal dimension on the vertical (that is potentially unlimited in height) but also from the many different flavours of browsers that gives a slightly different interpretation to the moltitude of specifications. On the other side, XAML programmers have a very strong layout system that makes thing really easy, thanks to a series of panels that acts with different behaviors in a consistent and predictable way.

Javascript, WTF?

A JavaScript article in Silverlightshow?

Web Development + Win 8?

What’s going on here !?!?

Before you stop reading let me introduce myself, I’m a Silverlight MVP (early joiner when there was a 1.1 alpha version), I love XAML + MVVM + Blend, and I was one of the dudes that run away from the JavaScript hell when I discovered the power of XAML + C# running inside a web browser.

As a Silverlight Developer and freelancer most of the projects that I’ve been working on were LOB apps running behind a firewall….

I know, as a XAML developer, you are probably confident that you own the better way for writing stunning interfaces, with a productive timing, a consistent toolset and a powerful language like C# that is a sweet juice. I'm also pretty sure that HTML people is completely confortable on its side and do not feel the need of moving to another language. Unfortunately, landing on the real world, these strong reasons are not so strong for all the people, and often you are forced to rely on something you'd not use under normal conditions, as an example because your customer has some constraints that prevent you from use your consolidated XAML or HTML5 knowledge but wants the other.

Now that Windows 8 has been around in its final form for almost a year, developers are getting used to the new platform. Lots of paradigms that have been around for many years in the Windows environment however have changed with the new course that Microsoft is sailing with the introduction of Metro (aka Modern UI aka Windows Store) apps.

Personally, one of the most striking differences between the desktop mode and the Windows 8 environment is without a doubt the way Windows handles multiple processes. In other words, background processing and the process lifecycle of Windows 8 applications.