As we developed the app model for Windows 8 and the new Metro style apps, a key architectural requirement has been to deliver apps to customers that can be used with confidence--confidence that apps will be well-behaved with respect to resources, that apps will not interfere with other apps, that apps use system resources with your permission, that apps can be installed and uninstalled with ease, and so on. These attributes require a robust platform and strong set of tools for developers. This is an effort that requires a fresh start and cannot be retrofitted on an existing system. Windows 8 is a fresh start in this regard. This post details some of the work we have done at the platform level to deliver reliable and trustworthy Metro style apps. This post is authored by John Hazen, a program manager on our Developer Experience team. --Steven One of our core principles in the development of the Windows 8 Metro style app platform was to ensure that users would have confidence in their apps. This is a mission we’re in together in this post, I explain our vision for app confidence and reliability and help you build confidence by design into your apps. Let me start by explaining what we mean by confidence. Picture a customer browsing the Windows Store looking at a Metro style app we want them to be thinking only about the app and whether or not it is right for them. We want them to assume—in fact be confident—that the app will behave the way they expect and thus will perform well on their system, will use only the data and information they authorize, and will harmoniously co-exist with their other applications. Our goal with the platform is to help us all build great apps that embody this vision of confidence so that we get confidence by default. To that end we made investments throughout the system. Here’s how we picture it: <img title="App Confidence" style="background-image: none float: none margin-left: auto display: block margin-right: auto" border="0" alt="Diagram of factors contributing to App Confidence as enumerated in the caption" src="http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/6840.AppConfidence01_5F00_226595B6.png" width="700" height="299" /> App Confidence: Windows 8 SDK for Metro style apps, Windows App Certification Kit, App Signatures,
App Container, Ratings and Reviews, Store Onboarding, Frictionless Install, Telemetry Feedback This post covers these areas and towards the end goes into depth on our app capabilities. First, a quick overview:
App Container, Ratings and Reviews, Store Onboarding, Frictionless Install, Telemetry Feedback This post covers these areas and towards the end goes into depth on our app capabilities. First, a quick overview:
- Windows Store – For customers, it starts with the Store, their one-stop-shop for Metro style apps. To get into the Store your app is reviewed for both technical and policy compliance, including security checks. After it’s published to the Store, your app will be rated and reviewed by the community. Together, the onboarding process and community reviews help create an environment in which customers can try apps with confidence.
- App install – Windows 8 handles all the details of deploying apps on your behalf so your customers don’t have to worry that installing, updating, or removing one app will adversely affect other apps.
- SDK – The Windows 8 SDK for Metro style apps provides a well-defined set of APIs that help you build reliable apps that conform to the Store onboarding requirements and provide the best experiences for your customers.
- App container and capabilities – Windows 8 provides a greater degree of separation between apps than was possible with traditional desktop apps, so you can build apps that interact with each other in more predictable ways, giving customers a more consistent experience.
- Provide a dedicated environment for your app, including your own store for data and settings. You have little worry that some other Metro style app will change your app’s data, settings, or behavior.
- Help ensure that your app doesn’t accidently interfere with the reliability of the Windows platform itself, or accidently use your customers’ data or devices in ways they don’t expect.
- Provide a well-defined way to extend the capabilities of your app through declarations you make in the manifest and disclose to your customer in the app listing page.
- [url=http://msdn.microsoft.com/en-us/library/windows/apps/hh464920.aspx#traits_4_right_contracts" target="_blank">App contracts</a>, which are the glue that binds Metro style apps together and to the system UI.
- The [url=http://msdn.microsoft.com/en-us/library/windows/apps/hh465182.aspx" target="_blank">FilePicker</a>, which allows your app to interact with data the user selects.
- [url=http://msdn.microsoft.com/en-us/library/windows/apps/hh464936.aspx" target="_blank">App capability declarations</a>, which allow your app to programmatically interact with devices and data, when appropriate for your functionality. [/list] These are all well-defined ways for your app to engage more deeply with other apps and the system. The app container exists to help you deliver on your customer’s expectations of reliability and respectful use of their system and data. The constraints of the app container are designed to help realize customers’ expectations for consistent and intuitive app behaviors, and using techniques that allow your app to run code outside of an app container is a violation of user trust and Store policy. In our discussions with developers during this preview period, we have seen apps that have misunderstood or accidently misused some of these mechanisms, so let’s go into more detail about the app capabilities in particular. App capability declarations The app container can be extended in a variety of ways using capability declarations, each of which is designed to enable certain scenarios. Therefore, we recommend that you use them only under certain conditions. These capabilities fall into 4 primary buckets:
- Data libraries: By default, apps have no access to the customer’s data libraries, like the Music library, or the Documents library. We recommend that you use the FilePicker to interact with these libraries, but in some rare cases it is necessary for your app to be able to directly read and manage data in these locations.
- Device access: By default, apps can’t use devices that most users consider sensitive for their privacy, including the webcam, microphone, and location. When apps need these devices, they must both declare their intent, and get consent from the user.
- Network access: By default, apps have no access to the customer’s networks. Because most apps interact with the Internet, we enabled this particular capability in all the Visual Studio templates for Metro style apps. If your app needs more than just simple Internet access, you can read about your options below.
- User identity: These capabilities provide direct access to a particular customer’s corporate logon info, or to certificates associated with their identity. These capabilities, although rarely needed, are necessary for certain enterprise apps, and you might need to use them in scenarios like banking transactions in which a smartcard might be required for authorization.
- Storing app-specific settings in the documents library. The private store is designed to provide this function. You can learn more about app settings and storage [url=http://blogs.msdn.com/b/windowsappdev/archive/2012/05/10/trending-forum-topics-answering-your-questions.aspx" target="_blank">here</a>.
- Store a user-generated file. This is more properly accomplished using the FilePicker to allow the user to save the file to any location, including the documents library.
- Sharing a document with another app. The Sharing contract is designed for this purpose.
Source: [url=http://blogs.msdn.com/b/b8/archive/2012/05/17/delivering-reliable-and-trustworthy-metro-style-apps.aspx]Windows 8 Blog
Last edited: