The Application Model
As discussed earlier in the chapter, Windows 8 Modern UI applications come with a different set of expectations and responsibilities when compared to their desktop brethren. This means that an entirely new application model is provided. A quick example here: traditional desktop applications are used to doing anything that the logged-in user could do. In other words, if I write a Windows Forms application, I could write code to easily read a document from the user’s document library or to access the Internet. Because the application was running under the security context of a specific user, application developers (and, therefore, the applications themselves) did little to police or report on their actions. In the WinRT/Windows Store world, this is no longer the case. Applications must now ask for permission by requesting specific capabilities. By default, a Windows Store application will have access to its own local file folder but cannot randomly access data anywhere else in the OS without user consent. The same is true for accessing the network connection, interacting with the camera or microphone, and so forth. These are referred to in the Windows 8/WinRT world as capabilities, and applications must be given explicit permission at install time to use the capabilities they are requesting but also, for some of them, the first time they are used.
Another difference involves the concept of application lifecycles. Desktop applications would generally be launched and, barring an application crash, would stay there, chewing up UI real estate, memory, and CPU cycles until the user explicitly closed them. Again, there is a big change with Modern UI applications. To provide an application model that would work effectively under adverse memory or processing conditions (as you might find on low-powered tablets, for instance), Windows Store applications are carefully managed by the OS. If an application isn’t in the foreground (that is, has focus and is receiving user interaction), the application will be suspended.
A suspended application’s threads are no longer running, although it is kept loaded into memory. Once suspended, the OS may elect to actually terminate the application at any point in time without notification. This frees the OS to do what it needs to do to optimize system resources and frees the user from ever having to worry about physically closing an application.
Implied in this lifecycle is the concept of implicit data storage. With desktop applications, data is typically stored when the user issues the Save command, and not before. But if the OS could suspend or terminate an application at any time, it would lead to severe data loss potential (or at the very least, an intrusive message to the user along the lines of “this app is about to be killed, do you want to save your data?”). So Modern UI applications must embrace the concept of implicit saves. That is, the application will take full responsibility for persisting whatever data has been entered; this includes things such as current page/navigation state.
Lifecycle States
Figure 23.11 shows the various lifecycle states that a WinRT Modern UI application can progress through. Note that although the OS could terminate an application at any time and for any reason (but mostly when memory is needed), the intent is to keep apps in suspended mode for as long as possible.
