Metro app developers are strongly encouraged to stay within Microsoft's carefully planned boundaries of the Windows 8 SDK for Metro style apps. Microsoft program manager John Hazen recently discussed the principles behind their approach to Metro apps which represents a marked difference in how Windows applications have been previously handled.
With Metro based apps, Microsoft is offering developers interested in the platform a proposition: Microsoft will lower the barriers for end-users to find and install apps via a centralized store (“Windows Store”), but in exchange developers must relinquish some of the freedoms they have historically enjoyed. So while the logistics of purchasing, installing, and updating apps will be simplified, developers will in exchange be giving Microsoft a role in the relationship that they have with their customer.
Hazen discourages developers from straying outside of the SDK's included APIs, as:
“APIs that are outside the SDK are not guaranteed to work with Metro style apps either in this release or in future releases, so you may find that your app doesn’t function properly for all customers.”
Interestingly Hazen notes that it is possible to “hide or obfuscate calls” to outside APIs but that it is a violation of Windows Store policy. InfoQ requested further information from Microsoft regarding these statements, but they declined to elaborate on this possibility.
App Capability Declarations
The environment each Metro app runs in is called an app container. Each container is designed to isolate apps from each other, with all interactions between the system and other apps closely regulated. These interactions include app contracts, the FilePicker which is used by the user to select which data they app may manipulate, and app capability declarations. These declarations provide an app with greater access to either user data or the underlying system, and as a result Microsoft recommends limiting their use.
Hazen describes the four 4 main categories of app capability declarations:
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.
