UWP Quick Reference

This quick reference collects the pieces of UWP development you look up constantly once you're past the tutorial stage: what each file in a fresh project template actually does, which manifest capability unlocks which API, the WinRT namespaces you'll reach for most (Windows.Storage, Windows.UI.Xaml, Windows.ApplicationModel), and the XAML binding syntax variations. It's organized so you can jump straight to the section you need instead of reading linearly.

A default UWP project contains App.xaml/App.xaml.cs (the application entry point and global resources), MainPage.xaml/.xaml.cs (the default landing page), Package.appxmanifest (an XML file, editable via a visual designer, declaring the app's identity, visual assets, and required capabilities), and an Assets folder holding tile and splash screen images at multiple scale factors. Capabilities in the manifest gate access to sensitive APIs: internetClient is required for any networking call, picturesLibrary/videosLibrary/musicLibrary for accessing those known folders directly (versus the file picker, which needs no capability), and webcam/microphone for camera and audio capture — forgetting to declare a capability causes the corresponding API call to throw an UnauthorizedAccessException at runtime rather than failing at compile time.

For local storage, ApplicationData.Current.LocalFolder gives per-app-isolated file storage while ApplicationData.Current.LocalSettings is a lightweight key-value store best suited to small settings rather than large data; for user-facing file access, use a FileOpenPicker or FolderPicker rather than raw paths, since UWP apps cannot access arbitrary filesystem paths outside their sandbox without the broadFileSystemAccess capability. For networking, HttpClient works as in .NET but should be instantiated once and reused (not per-request) to avoid socket exhaustion; for background execution beyond the app's foreground lifetime, register a BackgroundTaskBuilder with an appropriate trigger like TimeTrigger or SystemTrigger, subject to the resource quotas the OS enforces per app.

Classic Binding syntax is {Binding PropertyName, Mode=OneWay, Converter={StaticResource MyConverter}}, resolved at runtime and tolerant of a DataContext type that isn't known until execution. The compiled x:Bind syntax is {x:Bind ViewModel.PropertyName, Mode=OneWay}, requiring the page or control to declare its DataContext type via x:DataType (often set implicitly to the code-behind class, or explicitly to a ViewModel type), and it supports calling methods directly in the binding expression, like {x:Bind ViewModel.FormatDate(Item.Date)}, which classic Binding cannot do without a converter. For collection UI, x:Bind combined with ItemsStackPanel virtualization on a ListView/GridView is the standard high-performance pattern for anything beyond a handful of items.