Developer guidance summary and checklists for Windows Store business apps using C#, XAML, and Prism
[This article is for Windows 8.x and Windows Phone 8.x developers writing Windows Runtime apps. If you’re developing for Windows 10, see the latest documentation]
Explore checklists that provide a consolidated view of the guidance included with the documentation and illustrated in the AdventureWorks Shopper reference implementation, a Windows Store business app that uses C#, XAML, and Prism for the Windows Runtime. We include checklists for the Model-View-ViewModel (MVVM) pattern, creating and navigating between pages, using touch, validating user input, managing app data, handling suspend, resume, and activation, communicating between loosely coupled components, working with tiles, implementing search, improving performance, and testing and deploying apps.
After you download the code, see Getting started using Prism for the Windows Runtime for instructions on how to compile and run the reference implementation, as well as understand the Microsoft Visual Studio solution structure.
You will learn
- About the key decisions that must be made when developing a Windows Store business app.
- About checklists that you can use to accelerate the development of a maintainable and testable Windows Store business app.
- Windows Runtime for Windows 8.1
- Extensible Application Markup Language (XAML)
Making key decisions
This guidance provides information to developers who want to create a Windows Store app using C#, XAML, the Windows Runtime, and modern development practices. When you develop a new Windows Store app, you need to determine some key factors that will define the architecture of your app. The following are many of the key decisions that you will need to make:
- Decide on the design of the end user experience. When planning Windows Store apps, you should think more about what experience you want to provide to your users and less about what Microsoft Windows features you want to include. For more info see Designing the user experience.
- Decide whether to use a dependency injection container. Dependency injection containers reduce the dependency coupling between objects by providing a facility to construct instances of classes with their dependencies injected, and manage their lifetime based on the configuration of the container. You will need to decide whether to use a dependency injection container, which container to use, and how to register the lifetime of components. For more info see Using the Model-View-ViewModel pattern.
- Decide whether to provide a clean separation of concerns between the user interface controls and their logic. One of the most important decisions when creating a Windows Store app is whether to place business logic in code-behind files, or whether to create a clean separation of concerns between the user interface controls and their logic, in order to make the app more maintainable and testable. If you decide to provide a clean separation of concerns, there are then many decisions to be made about how to do this. For more info see Using the Model-View-ViewModel pattern.
- Decide how to create pages and navigate between them. There are many decisions to be made about page design including the page layout, what content should be displayed in different page views, whether to include design time data on your pages, and whether to make pages localizable and accessible. In addition, you must also make decisions about page navigation including how to invoke navigation, and where navigation logic should reside. For more info see Creating and navigating between pages.
- Choose the touch interactions that the app will support. This includes selecting the gestures from the Windows touch language that your app requires, and whether to design and implement your own custom touch interactions. For more info see Using touch.
- Decide how to validate user input for correctness. The decision must include how to validate user input across physical tiers, and how to notify the user about validation errors. For more info see Validating user input.
- Decide how to manage application data. This should include deciding upon which of the app data stores to use, what data to roam, deciding how to manage large data sets, how to perform authentication between your app and a web service, and how to reliably retrieve data from a web service. For more info see Managing application data.
- Decide how to manage the lifecycle of the app. The purpose and usage patterns of your app must be carefully designed to ensure that users have the best possible experience when an app suspends and resumes. This includes deciding whether your app needs to update the UI when resuming from suspension, and whether the app should start fresh if a long period of time has elapsed since the user last accessed it. For more info see Handling suspend, resume, and activation.
- Choose between platform provided eventing and loosely coupled eventing. Event aggregation allows communication between loosely coupled components in an app, removing the need for components to have a reference to each other. If you decide to use event aggregation, you must decide how to subscribe to events and unsubscribe from them. For more info see Communicating between loosely coupled components.
- Decide how to create tiles that are engaging for users. A tile is an app's representation on the Start screen and allows you to present rich and engaging content to your users when the app is not running. In order to create engaging tiles you must decide on their shape and size, how to update tile content, and how often to update tile content. For more info see Working with tiles.
- Choose how to participate in search. If your app has content that users might want to search, you should add a search box to your app canvas. The search box can respond to user queries and display search results in a page of your own design. However, there are still decisions to be made that include whether to provide query and result suggestions, filtering, and what to display on the search results page. For more info see Implementing search.
- Consider how to improve app performance. A well-performing app should respond to user actions quickly, with no noticeable delay. In order to deliver a well-performing app you will need to decide which tools to use to measure performance, and where to optimize code. For more info see Improving performance.
- Decide how to test and deploy the app. Windows Store apps should undergo various modes of testing in order to ensure that reliable, high quality apps are deployed. Therefore, you will need to decide how to test your app, how to deploy it, and how to manage it after deployment. For more info see Testing and deploying Windows Store apps.
Windows Store business apps developer checklists
When developing a Windows Store business app you should consult the following checklists to accelerate development while ensuring that a maintainable and testable app is produced.
Designing the user experience
Good Windows Store apps share an important set of traits that provide a consistent, elegant, and compelling user experience. Planning ahead for different form factors, accessibility, monetization, and selling in the global market can reduce your development time and make it easier to create a high quality app and get it certified.
|Created a "great at" statement to guide user experience planning.|
|Decided the user experiences to provide in the app.|
|Followed the Index of UX guidelines for Windows Store apps for the experiences the app provides.|
|Storyboarded the different app flows to decide how the app behaves.|
|Designed the app for different form factors.|
|Designed the app for all users regardless of their abilities, disabilities, or preferences.|
For more info see Designing the user experience.
Using the Model-View-ViewModel (MVVM) pattern
MVVM provides a way for developers to cleanly separate the user interface controls from their logic. This separation makes it easy to test the business logic of the app.
|Used a dependency injection container to decouple concrete types from the code that depends on those types, if appropriate.|
|Used view-first composition because the app is conceptually composed of views that connect to the view models they depend upon.|
|Limited view model instantiation to a single class by using a view model locator object.|
|Used a convention-based approach for view model construction to remove the need for some boilerplate code.|
|Used an attached property to automatically connect views to view models.|
|Promoted the testability of the app by exposing commands from the view models for ButtonBase-derived controls on the views.|
|Promoted the testability of the app by exposing behaviors to views for non-ButtonBase-derived controls.|
|Supported a view model hierarchy in order to eliminate redundant code in the view model classes.|
For more info see Using the MVVM pattern.
Creating and navigating between pages
The app page is the focal point for designing your UI. It holds all of your content and controls. Whenever possible, you should integrate your UI elements inline into the app page. Presenting your UI inline lets users fully immerse themselves in your app and stay in context.
|Used Visual Studio to work with the code-focused aspects of the app.|
|Used Blend for Microsoft Visual Studio 2013 or the Visual Studio designer to work on the visual appearance of the app.|
|Provided flexible page layouts that support landscape, portrait, and minimal view states.|
|Followed a consistent layout pattern for margins, page headers, gutter widths, and other page elements.|
|Maintained state in minimal view and possess feature parity across states.|
|Used the Windows simulator to test the app on a variety of screen sizes, orientations, and pixel densities.|
|Added sample data to each page to easily view styling results and layout sizes, and to support the designer-developer workflow.|
|Incorporated accessible design principles into the pages, and planned for them to be localized.|
|Placed navigation logic in view model classes to promote testability.|
|Used commands to implement a navigation action in a view model class, for ButtonBase-derived controls.|
|Used behaviors to implement a navigation action for non-ButtonBase-derived controls.|
|Used the navigation bar for navigational elements that move the user to a different page and used the bottom app bar for commands that act on the current page.|
|Implemented common page navigation functionality as a user control that is easily included on each page.|
|Used strings to specify navigation targets.|
For more info see Creating and navigating between pages.
Touch interactions in Windows use physical interactions to emulate the direct manipulation of UI elements and provide a more natural, real-world experience when interacting with those elements on the screen.
|Used the Windows touch language to provide a concise set of touch interactions that are used consistently throughout the system.|
|Used data binding to connect standard Windows controls to the view models that implement the touch interaction behavior.|
|Ensured that touch targets are large enough to support direct manipulation.|
|Provided immediate visual feedback to touch interactions.|
|Ensured that the app is safe to explore by making touch interactions reversible.|
|Avoided timed touch interactions.|
|Used static gestures to handle single-finger touch interactions.|
|Used manipulation gestures to handle dynamic multi-touch interactions.|
For more info see Using touch.
Validating user input
Any app that accepts input from users should ensure that the data is valid. Validation has many uses including enforcing business rules, providing responses to user input, and preventing an attacker from injecting malicious data.
|Performed client-side validation to provide immediate feedback to users, and server-side validation to improve security and enforce business rules on the server.|
|Performed synchronous validation to check the range, length, and structure of user input.|
|Derived model classes from the ValidatableBindableBase class in order to participate in client-side validation.|
|Specified validation rules for model properties by adding data annotation attributes to the properties.|
|Used dependency properties and data binding to make validation errors visible to the user when the properties of the model objects change.|
|Notified users about validation errors by highlighting the control that contains the invalid data, and by displaying an error message that informs the user why the data is invalid.|
|Saved user input and any validation error messages when the app suspends, so that the app can resume as the user left it following reactivation.|
For more info see Validating user input.
Managing application data
Application data is data that the app itself creates and manages. It is specific to the internal functions or configuration of an app, and includes runtime state, user preferences, reference content, and other settings.
|Used the application data APIs to work with application data, to make the system responsible for managing the physical storage of data.|
|Stored passwords in the Credential Locker only if the user has successfully signed into the app, and has opted to save passwords.|
|Used ASP.NET Web API to create a resource-oriented web service that can pass different content types.|
|Cached web service data locally when accessing data that rarely changes.|
For more info see Managing application data.
Handling suspend, resume, and activation
Windows Store apps should be designed to suspend when the user switches away from them and resume when the user switches back to them.
|Saved application data when the app is being suspended.|
|Saved the page state to memory when navigating away from a page.|
|Allowed views and view models to save and restore state that's relevant to each.|
|Updated the UI when the app resumes if the content has changed.|
|Used the saved application data to restore the app state, when the app resumes after being terminated.|
For more info see Handling suspend, resume, and activation.
Communicating between loosely coupled components
Event aggregation allows communication between loosely coupled components in an app, removing the need for components to have a reference to each other.
|Used Microsoft .NET events for communication between components that have object reference relationships.|
|Used event aggregation for communication between loosely coupled components.|
|Used the Microsoft.Practices.Prism.PubSubEvents library to communicate between loosely coupled components.|
|Defined a pub/sub event by creating an empty class that derives from the PubSubEvent<TPayload> class.|
|Notified subscribers by retrieving the event from the event aggregator and called its Publish method.|
|Registered to receive notifications by using one of the Subscribe method overloads available in the PubSubEvent<TPayload> class.|
|Request that notification of the pub/sub event will occur in the UI thread when needing to update the UI in response to the event.|
|Filtered required pub/sub events by specifying a delegate to be executed once when the event is published, to determine whether or not to invoke the subscriber callback.|
|Used strongly referenced delegates when subscribing to a pub/sub event, where performance problems have been observed.|
For more info see Communicating between loosely coupled components.
Working with tiles
Tiles represent your app on the Start screen and are used to launch your app. They have the ability to display a continuously changing set of content that can be used to keep users aware of events associated with your app when it's not running.
|Used live tiles to present engaging new content to users, which invites them to launch the app.|
|Made live tiles compelling by providing fresh, frequently updated content that makes users feel that the app is active even when it's not running.|
|Used a wide tile to display new and interesting content to the user, and periodic notifications to update the tile content.|
|Used peek templates to break tile content into two frames.|
|Set an expiration on all periodic tile notifications to ensure that the tile's content does not persist longer than it's relevant.|
|Updated the live tile as information becomes available, for personalized content.|
|Updated the live tile no more than every 30 minutes, for non-personalized content.|
|Allowed the user to create secondary tiles for any content that they wish to monitor.|
For more info see Working with tiles.
If your app has content that users might want to search, you should add a search box to your app canvas. The search box should respond to user queries and display search results in an app page of your own design.
|Used the SearchBox control to let users search for content in an app.|
|Implemented type to search for the app's hub, browse, and search pages.|
|Disabled type to search before showing flyouts, and restored it when flyouts close.|
|Showed placeholder text in the search box, to describe what users can search for.|
|Provided query suggestions to help the user search the app quickly.|
|Navigated to the search results page when the user selects a query suggestion.|
|Used a grid layout to display search results.|
|Showed the user's query text on the search results page.|
|Used hit highlighting to highlight the user's query on the search results page.|
|Enabled users to navigate back to the last-viewed page after they look at the details for a search result.|
|Provided app bar navigation on the search results page.|
|Provided a suitable message if the search query returns no results.|
|Restored page state correctly upon reactivation.|
|Saved the search results page for the last query in case the user searches for that query again.|
For more info see Implementing search.
To deliver a well-performing, responsive Windows Store app you must think of performance as a feature, to be planned for and measured throughout the lifecycle of your project.
|Performed app profiling to determine where code optimizations will have the greatest effect in reducing performance problems.|
|Measured app performance once you have code that performs meaningful work.|
|Taken performance measurements on hardware that has the lowest anticipated specification.|
|Optimized actual app performance and perceived app performance.|
|Limited the startup time of the app.|
|Emphasized responsiveness in the UI.|
|Trimmed resource dictionaries to reduce the amount of XAML the framework parses when the app starts.|
|Reduced the number of XAML elements on a page to make the app render faster.|
|Reused brushes in order to reduce memory consumption.|
|Used independent animations to avoid blocking the UI thread.|
|Minimized the communication between the app and the web service.|
|Limited the amount of data downloaded from the web service.|
|Used UI virtualization to only load into memory those UI elements that are near the viewport.|
|Used the IncrementalUpdateBehavior to implement incremental loading.|
|Avoided unnecessary app termination.|
|Kept the app's memory usage low when it's suspended.|
|Reduced the battery consumption of the app.|
|Minimized the amount of resources that the app uses.|
|Limited the time spent in transition between managed and native code.|
|Reduced garbage collection time.|
For more info see Improving performance.
Testing and deploying apps
Testing helps to ensure that an app is reliable, correct, and of high quality.
|Performed unit testing, integration testing, user interface testing, suspend and resume testing, security testing, localization testing, accessibility testing, performance testing, device testing, and Windows certification testing.|
|Validated and test a release build of the app by using the Windows App Certification Kit.|
For more info see Testing and deploying Windows Store business apps.