UWP Quick Reference

Analogy categoryAnalogies

Introduction

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.

🏏

Cricket analogy: A quick-reference sheet for UWP is like a fielding position chart pinned to the dressing room wall — you don't memorize it cover to cover, you glance at it mid-match when you need to confirm where cover-point should stand.

Project Structure and the App Manifest

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.

🏏

Cricket analogy: Declaring capabilities in the manifest is like a team submitting its official playing XI before the match — you can't bring an uncontracted overseas player onto the field (call an API) that wasn't registered beforehand.

Common WinRT APIs Cheat Sheet

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.

🏏

Cricket analogy: ApplicationData.Current.LocalSettings being for small data only is like using a scorecard for the match summary rather than trying to log every single delivery's ball-tracking data on it — right tool for the size of data.

XAML Binding Syntax Reference

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.

🏏

Cricket analogy: x:Bind calling a method directly in the expression is like a scorer applying a live custom formula (strike rate calculation) right in the scoreboard software instead of manually computing it and typing in the result — the logic runs inline.

xml

<!-- x:Bind requires the page's DataType, usually inferred from code-behind -->
<Page x:Class="MyApp.MainPage"
      xmlns:vm="using:MyApp.ViewModels">

    <Page.DataContext>
        <vm:MainViewModel x:Name="ViewModel" />
    </Page.DataContext>

    <ListView ItemsSource="{x:Bind ViewModel.Items}"
              SelectionMode="Single">
        <ListView.ItemTemplate>
            <DataTemplate x:DataType="local:ItemModel">
                <StackPanel Orientation="Horizontal">
                    <TextBlock Text="{x:Bind Name}" />
                    <TextBlock Text="{x:Bind FormattedDate}" Margin="8,0,0,0" />
                </StackPanel>
            </DataTemplate>
        </ListView.ItemTemplate>
    </ListView>
</Page>

For settings you expect to grow large or complex, use ApplicationData.Current.LocalFolder with a serialized JSON file instead of LocalSettings — LocalSettings has a per-key 8KB roaming-data size limit that's easy to hit.

App.xaml, MainPage.xaml, and Package.appxmanifest are the core files in every UWP project template.
Manifest capabilities gate API access; a missing capability causes a runtime UnauthorizedAccessException, not a compile error.
LocalFolder is for file storage; LocalSettings is a lightweight key-value store with an 8KB per-key limit.
Reuse a single HttpClient instance across the app's lifetime to avoid socket exhaustion.
x:Bind requires x:DataType and supports calling methods directly in the binding expression.
Classic Binding is runtime-reflection-based and defaults to OneWay; x:Bind is compiled and defaults to OneTime.
Use ItemsStackPanel virtualization with x:Bind for any ListView/GridView beyond a handful of items.