Windows 10 UWP Community Toolkit 1.2 is now available

Reading time icon 2 min. read

Readers help support Windows Report. We may get a commission if you buy through our links. Tooltip Icon

Read our disclosure page to find out how can you help Windows Report sustain the editorial team Read more

The UWP Community Toolkit brings together a number of tools for developers to use in developing their own Windows 10 apps. It’s a rather technical topic, and so if helper functions, custom controls, and app services don’t mean anything to you, then you likely won’t be too excited about the release of UWP Community Toolkit 1.2.

If you are a developer type who gets this stuff, then you’ll likely be happy to see it. Here’s what you can expect in the updated version:

The focus of this version was to stabilize current features while adding the most wanted ones that were missing. A full list of features and changes is available in the release notes. Here’s a quick preview:

  • New Helpers. we worked on providing 7 new helpers to help with everyday tasks:
    • BackgroundTaskHelper to help you work with background tasks
    • HttpHelper to help you deal with HTTP requests in a secure and reliable way
    • PrintHelper to help you print XAML controls
    • DispacherHelper to help you work with tasks that need to run on UI thread
    • DeepLinkHelper to simplify the management of your deep links
    • WebViewExtensions to allow you to bind HTML content to your Webview
    • SystemInformation to gather all system information into a single and unique class
  • New Controls
    • We introduced a new control named MasterDetailView that helps developers create master/detail user experiences
  • Updates. We updated the following features:
    • ImageCache was improved to provide a more robust cache
    • HeaderedTextBlock and PullToRefreshListView now accept ContentTemplate customization
    • Facebook service now supports paging when requesting data
    • Renamed BladeControl to BladeView. BladeView now also derives from ItemsControl. This will allow for more common convention like data binding and will make the control aligned with SDK naming. To guarantee backward compatibility, we kept the previous control and flagged it as obsolete. This way, developers can still reference the new version and everything will work just fine. A compiler warning will just encourage you to use the new version. The current plan is to keep obsolete classes until next major version and then remove them.

You can keep up with what’s on its way by visiting the roadmap. Head over to GitHub if you have something to contribute.