Tag Archives: UWP API

ICYMI – Build 14986, BUILD 2017, and Windows 10 on ARM-based computers!?

What a time to be a Windows developer.

This week we got a new Windows Insider Preview Build, new options added to the Desktop Bridge, expanded access to customer segmentation and notifications, and finally some big news coming from the Windows Hardware Engineer Conference (also known as WinHec 2016). More details below!

Windows 10 Insider Preview Build 14986

In the latest Insider Preview Build, you’ll find a treasure chest of updates. Our favorites include improvements to Cortana, the Windows Game Bar, Ink and enhancements to the Windows 10 experience in Asia. Click the link in the above title to read the blog post!

Desktop Bridge – Options for bringing Win32 Apps to the UWP

Use the Desktop App Converter to gain access to UWP APIs and simplify your app’s installation process with Windows 10 app packaging technology.

Customer Segmentation and Notifications

Developers can build customer segments and use the segments to create custom retargeting and reengagement ad campaigns for their UWP apps. Additionally, devs can use these segments to send push notifications. Previously this ability was only available to Windows Insiders. So on that note, we hope you enjoy it!

Windows 10 on ARM-based Computers (!)

It’s not too good to be true, nor is it some sort of developer witchcraft. It’s real and represents a huge step forward in mobile technology. Here’s a preview of what Windows 10 looks like on a Qualcomm Snapdragon processor.

And last, but not least…

BUILD 2017 dates and location announced!

And that’s it! We’re excited to get the BUILD 2017 ball rolling, and as always, tweet us @WindowsDev with any questions or feedback.

Download Visual Studio to get started.

The Windows team would love to hear your feedback.  Please keep the feedback coming using our Windows Developer UserVoice site. If you have a direct bug, please use the Windows Feedback tool built directly into Windows 10.

Conversion options for bringing your existing desktop app to the Universal Windows Platform using the Desktop Bridge

With this summer’s release of the Windows 10 Anniversary update and the recent announcement of the Store supporting apps built with the Desktop Bridge technology, we are receiving much interest from many customers wanting to participate. Many developers are seeing the value of the new Windows 10 app packaging technology that enables your app to cleanly install, uninstall and update, as well as get full access to UWP APIs including Live Tiles, Cortana, notifications and more.

However, the conversion process can be intimidating if you are not familiar with your application’s footprint on the system and the technology it uses. This article is intended to educate you on the options for converting your app’s installation into a Windows app package.


Before we begin to list the options and their various pros and cons, it helps to understand a little about what makes up a Windows app package and how an existing application runs under the Desktop Bridge environment. In the context of the Desktop Bridge, the key parts of an app package, also known as a “.appx” file, has the following:

  • Application files – these are the files your app requires to execute and are usually placed in the root of the package. Typically these are the same files that are installed in the application’s folder under “C:Program Files” or “C:Program Files (x86).” In the Universal Windows Platform (UWP), package is placed in an app specific directory under “C:Program FilesWindowsApps” and are secured to prevent tampering.
  • AppManifest.xml – this file is used by the Windows Store to validate the package contents and identity of the publisher, and it is used by the deployment pipeline to install the application. The purpose of the manifest is to make everything about the installation of a package declarative and thus handled by the system. A key pillar is that no user code is executed at deployment time.
  • Reg.dat – If the application writes to the registry at install time, or the app expects certain registry keys to be set when it starts, this information must be stored in a local application hive. At runtime, this hive is mounted and merged with the system registry so the application sees a merged view. The isolation provided by this model allows for no-impact install and uninstall guarantees provided by the UWP packaging model for apps in the Windows Store.
  • Virtual File System, VFS (optional) – If the application places files in other locations outside its typical product folder, i.e, c:windowssystem32, these files should be placed under the VFS folder. At runtime, the VFS is mounted and merged with the actual file system on disk so the application is presented with a merged view. The isolation provided by this model allows for no-impact install and uninstall guarantees provided by the UWP packaging model for apps in the Windows Store.

After you understand the essential parts that are required for a UWP package, the next step that will influence the conversion is understanding how the application impacts the system – what files are installed where, and what registry entries does the application installer write. Depending on how much a developer knows about their application installer, they can make the decision on the best approach.

Don’t know what your setup package does?

Desktop App Converter

The Desktop App Converter (DAC) is the first option most developers are exposed to, as it requires very little knowledge of the application’s installer. The DAC leverages an isolated environment to install the application. While the install is happening, the isolated environment captures all file system and registry access within that environment and saves the deltas to disk.

The DAC then processes the deltas, filtering out changes made by the OS itself (the isolated environment is similar to a light weight VM running the OS and so there are services, filesystem and registry access happening while the installer is running), and locates your application via shortcuts registered in that environment by the installer. The DAC saves the installer-specific changes, creates the manifest file and sample image assets, and builds the UWP package if specified.

The benefits of this approach are:

  • Straightforward if you know your installer’s silent or unattended setup flags.
  • The DAC can be used to create an initial package, and the output (the PackageFiles folder) can be manually updated with new binaries and rebuilt when there are updates to the application. There is no need to re-run the DAC unless there are significant changes to the installer.

The caveats are:

  • First-time acquisition and setup of the DAC and its base image can take some time.
  • Requires the developer to be familiar with their installer, at least enough to know if it supports a silent or unattended mode. Some installers are not very clear on how to do this and can require a lot of trial and error to figure this out, which is beyond the scope of this article.
  • If the installer hangs, it can be a challenge to get the installer log files for debugging.
  • The file and registry filtering takes a conservative approach to remove system activity because installers can have a broad impact to the system. This approach was taken to ensure the greatest level of compatibility. Developers should review the virtual file system and registry and remove entries that are not associated with their application.

The Desktop App Converter itself can be downloaded from the Windows Store. For more information, please check out the documentation on the Windows Dev Center.

XCopy Deployment?

Manual Packaging

If an application setup is very simple and does not require registry entries nor copying files to protected locations, then a manual packaging option is the most straightforward.  This solution is common for single executable tools or “xcopy” deployments. Typically, all that is required is to place the application files in a folder, and to create an AppManifest.xml with the proper fields updated to identify the publisher and the app executable. Step-by-step instructions for manual packaging can be found on the Windows Dev Center and a sample can be found on GitHub.

Need to support both MSI and Windows 10?

Install technology partners with .appx packaging support

We’ve been working with our partners that build setup technologies to add support for directly building Windows app packages (.appx file) with their tools. These tools will create the app manifest and produce the app package as part of their build process. The key benefit these solutions provide is the ability to maintain one installer code base that will produce an MSI installer typically used in older versions of Windows (e.g. Windows 7), as well as build a no-impact install package for Windows 10 (i.e., .appx file for Windows 10). More information can be found at:

Additionally, Embarcadero has announced support for the Desktop Bridge in RAD Studio, which lets you directly output a Windows app package through the build process.

In summary, the best option depends on how complex the application is and much a developer knows about their existing installation methodology. Whether you have an installer with unknown setup technology, a simple xcopy install, or an application that already has existing assets in a given installer technology, there are approaches to meet your needs.

For more information on the Desktop Bridge, please visit the Windows Dev Center.

Ready to submit your app to the Windows Store? Let us know!

Animations with the Visual Layer

When the layout of your Universal Windows Platform (UWP) app changes, there is often a slight pause as your app rearranges content to fit the new window size or orientation. Composition APIs let you create smooth-as-butter animations between these states so your layout changes won’t jar your users. After all, layout changes are a basic fact of the app life cycle. It doesn’t mean we can’t handle them gracefully.


Layout animations aren’t completely new, of course. UWP has always allowed you to hook up XAML transitions. These animations have tended to be, let’s just say, somewhat limited. By using implicit animations in the Visual Layer, however, you can have access to low-level animations that run at 60 frames a second in a separate process and all the freedom you need to create the layout animations you want.

Implicit versus Explicit animations

So what exactly is an implicit animation? This is best understood by contrasting it with explicit animations. Explicit animations are animations that you start running yourself in code-behind by calling a method like StartAnimation on a Visual.

For instance, here’s an example of a gear animation and the code used to get it started.


_gearMotionScalarAnimation.Duration = TimeSpan.FromSeconds(secondsPerRotation); 
_gearVisuals.First().StartAnimation("RotationAngleInDegrees", _gearMotionScalarAnimation);

Implicit animations, on the other hand, are configured and then triggered by property changes. There’s a fire-and-forget quality to implicit animations. All you have to do is wire them up and they will just keep working for you, getting recreated and then cleaned up every time the trigger fires.

Here’s how you create and configure an implicit animation in four easy steps:

  1. Create an implicit animation collection.
  2. Create the animation or group of animations.
  3. Associate the animation value to a trigger key in the collection.
  4. Add the collection to your Visual’s ImplicitAnimations property.

The following code is used to create the fruit animations in the animated GIF at the top of this post:

// Create an implicit animation collection (just one member in this case) 
var implicitAnimationCollection = _compositor.CreateImplicitAnimationCollection(); 
// Create the animation 
var offsetKeyFrameAnimation = _compositor.CreateVector3KeyFrameAnimation(); 
offsetKeyFrameAnimation.Target = "Offset"; 
// Final Value signifies the target value to which the visual will animate 
// in this case it will be defined by new offset 
offsetKeyFrameAnimation.InsertExpressionKeyFrame(1.0f, "this.FinalValue"); 
offsetKeyFrameAnimation.Duration = TimeSpan.FromSeconds(3); 
// Associate the animation to the trigger 
implicitAnimationCollection["Offset"] = offsetKeyFrameAnimation; 
// Finally, add the implicit animation to individual Visuals 
foreach (var child in _root.Children) 
    child.ImplicitAnimations = implicitAnimationCollection; 

There are two things worth noting about this code:

  • First, only one trigger property is being used, Offset, so the ImplicitAnimationCollection has only one member.
  • Second, the animation uses the Offset property as a trigger, but also uses the Offset property for the animation itself. This is actually pretty common since you will usually want to animate the same property that sets off the transition – for instance, if an element’s scale or rotation changes you would want to create a transition animation between the start and end scale sizes or the start and end rotations.

For extra visual flair you could also decide to have a change in a Visual’s Offset trigger more than one animation – for instance, a position animation as well as a bit of spinning and pulsing. Go to the Windows UI Dev Labs GitHub repository for the full source code for this implicit animations sample.

Using implicit animations as layout animations

In order to apply implicit animations to your XAML layout, the only additional step you need to do, beyond what has been covered in the previous section, is to grab the backing Visuals for any UIElements you intend to animate.


The Layout Animations demo from the Windows UI Dev Labs Sample Gallery on GitHub is basically a GridView control with several images in its Items collection.

<GridView x:Name="gridView" ContainerContentChanging="gridView_ContainerContentChanging"> 
        <Image Source="1.jpg" Width="235" Height="200" Stretch="UniformToFill"/> 
        <Image Source="2.jpg" Stretch="UniformToFill"/> 
        <Image Source="3.jpg" Stretch="UniformToFill"/> 
        <Image Source="4.jpg" Stretch="UniformToFill"/> 
        . . . 

Whenever the XAML page is resized, images inside the GridView are automatically shifted around by the underlying framework, altering the Offset property of each of the Visuals as it is moved from one position to another.
Here’s how you create and configure an implicit animation and add it to XAML elements in five easy steps:

  1. Create an implicit animation collection.
  2. Create the animation.
  3. Associate the animation value to a trigger key in the collection.
  4. In the ContainerContentChanging event handler, use the interop method GetElementVisual to peel of the backing Visual from a UIElement.
  5. Add the collection to your backing Visual’s ImplicitAnimations property.

The first three steps can all be done in the page’s constructor.

_compositor = ElementCompositionPreview.GetElementVisual(this).Compositor; 
// Create ImplicitAnimations Collection.  
_elementImplicitAnimation = _compositor.CreateImplicitAnimationCollection(); 
// Define trigger and animation that should play when the trigger is triggered.  
_elementImplicitAnimation["Offset"] = createOffsetAnimation();

In the Layout Animations demo, the final two steps are completed in the GridView’s ContainerContentChanging event handler.

private void gridView_ContainerContentChanging(ListViewBase sender, ContainerContentChangingEventArgs args) 
    var photo = args.ItemContainer; 
    var elementVisual = ElementCompositionPreview.GetElementVisual(photo); 
    elementVisual.ImplicitAnimations = _elementImplicitAnimation; 

It really is that simple to add fast, fluid and beautiful layout animations to your XAML page with the Visual layer.

Connected animations

For navigation transitions between pages, the Visual Layer provides a different mechanism known as connected animations to help you make your UI sweeter. Connected animations help the user stay oriented when she is performing common tasks such as context switching from a list of items to a details page.


You can download the full source for this connected animations sample on GitHub.

Wrapping up

The visual power being made available to developers through the Composition APIs have basically always been a part of the UI Frameworks. They just haven’t been accessible until now. Think of this as a UI nuclear reactor being handed over to you to play with. With this awesome power, however, also comes the responsibility to create sweet UI and beautiful interactions. Go forth and be amazing.

To learn more about the topics covered in this post, you are encouraged to voraciously consume the following articles and videos:

Try out your animation skills – download Visual Studio and get designing!

The Windows team would love to hear your feedback.  Please keep the feedback coming using our Windows Developer UserVoice site. If you have a direct bug, please use the Windows Feedback tool built directly into Windows 10.

Unity Interop and App Extensibility (App Dev on Xbox series)

Continuing what we started during the “App Dev on Xbox” event, today we are making available yet another app experience – Atmosphere. In this blog post, you will learn how to get started building great 2D and 3D experiences with Unity and XAML, how to open up your app so other app developers can extend your app functionality, and how you can make your app functionality available to other apps. Even though this blog post is part of the App Dev on Xbox series, the majority of the content applies to the entire Universal Windows Platform.

If you missed the previous blog post, we looked at how you can deliver the best possible experience for your app in a responsive and scalable way so it can target all device form factors and provide a premium experience on the TV. Among other things, we covered how to take advantage of the controller and enable direction navigation, how to optimize for the couch viewing distance, ways to customize the focus visual to make it your own and much more.

And if you missed the live event, you can still watch videos of all of the sessions on the “App Dev on Xbox” event page on Channel 9.

Check out this Channel 9 demo using the Atmosphere app, and read on for the how-to.



The Atmosphere app is a weather app that showcases the use of the popular Unity Engine in a normal Universal Windows Platform (UWP) application. It renders a 3D layer below a 2D XAML layer. The 3D world renders the weather with special effects like rain, thunder, clouds and so on for each day, and then the XAML User Interface (UI) layer communicates the information to the user. The app also showcases the use of app extensions that enable other developers to extend certain areas of the app – in this case, the extension provides music that matches the mood of the current weather. In addition, the weather service used by the app is exposed through an app service that enables other apps to use that weather information, as illustrated by Fourth Coffee (the news app experience from the previous blog post). Let’s dive in.


The Design of Atmosphere

Atmosphere shows you what the weather is like using straightforward data and insightful visuals.

Numbers, short descriptions and icons tell users whether it’s cold or warm or windy outside. This leads to a clean and to-the-point design, so that people can gather its information as quickly and confidently as possible.

This is what most weather apps do, and it’s important.

Atmosphere also uses color, animation and 3D imagery to capture the emotion and personality of weather. Through subtle color changes and additional effects, like rain and shadows, the mood of weather is conveyed.

By combining clean visuals (through XAML) and smooth animations (with Unity), as well as the addition of weather-themed music, Atmosphere delivers a well-rounded experience that is simple and delightful.

This allows Atmosphere to apply itself across the platform, from cinematic viewing on the Xbox One to on-the-go weather updates on a phone, and everything in between.

Making your UWP work in three dimensions with Unity

Unity is a very popular 3D engine designed to develop 2D and 3D games and interactive experiences. The engine supports both C# and JavaScript as development languages and has a clean and beautiful editor. Unity supports exporting to a vast number of platforms, including UWP. It enables you to simply drag and drop 3D assets like models into your scene, position them around and write custom logic to develop the experience you want.


1. Creating worlds with Unity
How Atmosphere works is that we developed a generic world captured inside a glass-looking sphere, controlled by a class WorldController. Each world is essentially an instance of the WorldController.


It consists of a simple sphere that acts like the border of the world, and everything for each instance of the world happens within this border. For instance, we have the 3D models that represent the environment plus different weather effects that will be visible based on what type of weather we set the environment to in the WorldController instance.

Another class, called WeatherController, acts like the main class for controlling the Unity layer. This is what we expose to the UWP part of the application. The WeatherController controls each WorldController independently.


The functions we expose are: SetWeather(..), which sets the weather on one of the worlds; SetOrientation(..), which changes the orientation of the Unity layer so it matches the XAML layer; and lastly SetView(..), for positioning the worlds around in the canvas. Three views are needed: one for the close-up view, one for the detailed view and one for the 5-day forecast.

The positioning of the spheres on the screen can be done in many ways – we chose to manually distribute them on the screen based on the aspect ratio so it would be easier to align it with a XAML Grid on the UI layer.

2. Unity Interop
Since the 3D rendering layer will run on a different thread than the 2D XAML UI, we need to enable these two layers to communicate. This is done using static variables and functions, as well as events.

The first thing we do is fire an event called AssetsLoaded from the WeatherController class when Unity is ready and all the assets are loaded. We know this is true when the WeatherControllers Start() function is called automatically by Unity.

public static event EventHandler AssetsLoaded;
void Start()
    if(AssetsLoaded != null)
        AssetsLoaded(null, null);

We can then catch this event in the UWP part of the app and write custom logic related to this.
WeatherController.AssetsLoaded += WeatherController_AssetsLoaded;

private void WeatherController_AssetsLoaded(object sender, EventArgs e)

Since we defined SetWeather(..), SetView(..) and SetOrientation(..) as static functions, we can simply call them using WeatherController.SetWeather(..) from the UWP part of the application.

3. Exporting to UWP from Unity
Once we have this base logic in place, we can export it as a UWP from Unity. This is done from File -> Build Settings:


Windows Store is selected, the SDK is set to Windows 10 and the UWP Build Type is set to XAML since we want to add XAML and features on top of this.

Once exported, it will generate a normal UWP package that can run on any Windows 10 device, including Xbox. The generated UWP solution comes with three build configurations: Debug, Release and Master. The one you need to use when submitting your app to the store is the Master build.

4. Data, UWP and UI
The UI is developed using XAML and is placed on top of the SwapChain that renders the 3D content.

The weather data is then captured from a weather source and set using the functions we exposed in the WeatherController class, as well as bound using Data Binding to the XAML controls used for the UI.


Using XAML elements we define the layout of all the controls used for the UI using Grids, TextBlocks, Images for the weather icons and so on.

App Services

By implementing an app service in your UWP apps, you create an endpoint to which other apps on the same machine can call in to retrieve or provide data. The cool thing is that your app does not have to be running and it can be woken up in the background without having to load any UI. In Atmosphere, the weather service used by the application is made available through an app service so other apps, with only few lines of code, can consume the endpoint and get the current weather without needing to know how to communicate with the weather service.

1. Creating app service
There are two things that you as a developer need to do to expose an app service. First, you need to declare that your app exposes an app service by adding these lines of code in your app manifest:

<uap:Extension Category="windows.appService">

<uap:AppService Name="com.atomosphere.weather" />


The AppService name (in this case com.atmosphere.weather) is what other apps will use to call into the app service. In addition, they will need to know your app package family name (found under Packaging in the manifest UI).

Second, you need to override the OnBackgroundActivated method in App.xaml.cs. This method will be called when another app accesses the app service, and it’s where we can get a reference to the app service connection that we can use to send and receive messages from/to the caller method in App.xaml.cs. This method will be called when another app accesses the app service, and it’s where we can get a reference to the app service connection that we can use to send and receive messages from/to the caller.

protected override void OnBackgroundActivated(BackgroundActivatedEventArgs args)
    // Get a deferral so that the service isn't terminated.
    this.backgroundTaskDeferral = args.TaskInstance.GetDeferral();

    // Associate a cancellation handler with the background task.
    args.TaskInstance.Canceled += OnTaskCanceled; 

    // Retrieve the app service connection and set up a listener for incoming app service requests.
    var details = args.TaskInstance.TriggerDetails as AppServiceTriggerDetails;
    appServiceconnection = details.AppServiceConnection;
    appServiceconnection.RequestReceived += OnRequestReceived;
    appServiceconnection.ServiceClosed += AppServiceconnection_ServiceClosed;

All messages are passed as ValueSet, essentially a key and value map that can be used to implement your custom protocol. The only command that our app currently accepts is the CurrentWeather and it returns a ValueSet that contains the current Temperature. The full code is here.

private async void OnRequestReceived(AppServiceConnection sender, AppServiceRequestReceivedEventArgs args) 
    var messageDeferral = args.GetDeferral(); 
    ValueSet message = args.Request.Message; 
    ValueSet returnData = new ValueSet(); 
    if (message.ContainsKey("Command")) 
        string command = message["Command"] as string; 
         // ... // 
        returnData.Add("Status", "Fail: Missing command"); 
    await args.Request.SendResponseAsync(returnData); // Return the data to the caller. 

2. Consuming the app service
Calling into the app service allows other developers to use functionality that is part of your app and runs in the context of your app. To illustrate this, we used Fourth Coffee, the news app experience from the previous blog post, to implement the app service from Atmosphere and display the current weather on the home page. The code below comes from the app source code which is already available on the GitHub repository.


Apps can easily check to see if an app service is available by calling the FindAppServiceProvidesAsync method, which returns all app services with the name provided. Optionally, your app could also ask the user to install a specific app from the store, if not installed already, which returns all app services with the name provided. Optionally, your app could also ask the user to install a specific app from the store, if not installed already.

var services = await AppServiceCatalog.FindAppServiceProvidersAsync("com.atmosphere.weather");

Calling into the service requires the creation of a new AppServiceConnection and configuring it with the app service name and app package family name. Once the service is created, the channel can be opened and you can start sending messages in the form of ValueSet, then await a response. This is what it looks like in Fourth Coffee:

service = new AppServiceConnection(); 
service.AppServiceName = "com.atomosphere.weather"; 
service.PackageFamilyName = "WeahterCastPoly_pzq3xp76mxafg"; 
await service.OpenAsync(); 

var message = new ValueSet(); 
message.Add("Command", "CurrentWeather"); 
var response = await service.SendMessageAsync(message); 
// use result

To call into the app service from another app, there are two things that developers must know about the app providing the app service: (1) the name of the app service, and (2) the package family name.

There are multiple ways to make the transfer of this information easier for developers who will be accessing your app service.

If your app service will be accessed by multiple app developers, you should consider creating a small library that developers can use within their apps without having to know anything about the app service. The library should wrap around your protocol and implement the calls to your service by including the app service name and package family name.

Alternately, an app service can be made discoverable through the use of App Extensions, which we will cover in the next section.

App Extensions

Creating an ecosystem of apps would not be possible without having some way for these apps to communicate and extend themselves. With the Windows 10 Anniversary Update, developers can now open up their apps so other developers can write extensions that provide functionality not otherwise available in the host app. The extensions themselves are just other UWP apps that can be downloaded from the store the same way and can work as standalone apps.

Getting started is really straightforward. First the host application, in this case Atmosphere, declares that it is an extension host and defines the name in the manifest:

<uap3:Extension Category="windows.appExtensionHost"> 

The extension can then define itself as an extension in its own manifest by providing the same name as the host:

<uap3:Extension Category="windows.appExtension"> 
  <uap3:AppExtension Name="Atmosphere"  
                     Description="Adds additional sound features to the Atmosphere compatible apps"  
                     DisplayName="Atmosphere Sounds"  

For both of these, make sure you have the namespace definition for UAP-3 and that it is added to the IgnorableNamespaces at the top of the manifest:


To use extensions in the host app, first you will need to open the AppExtensionCatalog for the name you defined in the manifest (e.g. Atmosphere) and subscribe to events for when other extensions are installed. This allows you to install extensions even when your app is running:for the name you defined in the manifest (e.g. Atmosphere) and subscribe to events for when other extensions are installed. This allows you to install extensions even when your app is running:

_catalog = AppExtensionCatalog.Open("Atmosphere"); 
_catalog.PackageInstalled += _catalog_PackageInstalled; 

Once the AppExtensionCatalog is open, iterating over every extension installed can be done using the FindAllAsync() command.

foreach (var extension in await _catalog.FindAllAsync())
    // use extension

In general, there are two ways that an extension can help extend the functionality: by providing an app service, and by providing data files in the public folder.

1. AppService
First, the extension provider can expose an app service that provides functionality for other developers to take advantage of in their apps. The extension can then provide the endpoint information as part of the properties, and it can be accessed by the host as described in the previous section. To illustrate this, Atmosphere provides an extension for Fourth Coffee where the app service is defined and can be used by Fourth Coffee even without Fourth Coffee knowing the name of the service or the package family name.

To provide the name of the app service, the extension can add custom properties to the extension definition in the manifest:

<uap3:Extension Category="windows.appExtension"> 
   <uap3:AppExtension Name="FourthCoffee" 
                      Description="Describes com.atmosphere.weather app service" 

In this case, we added a new property called Service that includes the service name. In Fourth Coffee, we can then use the extension to read the properties and discover the name of the app service. In addition, the extension already provides the package family name to be used. You can see the code in Fourth Coffee here:

var properties = await extension.GetExtensionPropertiesAsync() as PropertySet; 
if (properties != null && properties.ContainsKey("Service")) 
    PropertySet service = properties["Service"] as PropertySet; 
    var serviceName = service["#text"].ToString(); 
    var packageName = extension.Package.Id.FamilyName; 
    Weather = await WeatherService.GetWeather(serviceName, packageName); 

2. Public folder
Second, the extension provider can host data files that can be made available to the host to use. This allows assets to be shipped separately from the main app and extended over time through extensions. Other developers creating extensions for your app can also create assets that can be used within your app. Atmosphere has the ability to play sounds depending on what the current weather is, using sounds found in extensions provided by other developers. To see this in action, install the Atmosphere Music Extension app found in the same solution as Atmosphere. You will notice that Atmosphere will pick up the extension immediately and start playing the sounds.

Calling the GetPublicFolderAsync method on an extension allows you to get a StorageFolder that points to data files the extension has made available to your app. Here is the code from Atmosphere:

var folder = await extension.GetPublicFolderAsync(); 
var files = await folder.GetFilesAsync(); 
_soundFiles = files.Where(i => i.Name.EndsWith(".mp3"));

Until next time…

…check out the app source on our official GitHub repository, read through some of the resources provided, watch the event if you missed it, and let us know what you think through the comments below or on twitter.  if you missed it, and let us know what you think through the comments below or on twitter.

Next week we will release another app experience and go in-depth on how to develop cross-platform applications by sharing code with Xamarin. We will also cover how to enable background audio in your applications so the music can continue playing while the user is playing a game (or staying up late to finish up this blog post).

Until then, happy coding!


Get started now – download Visual Studio.

The Windows team would love to hear your feedback. Please keep the feedback coming using our Windows Developer UserVoice site. If you have a direct bug, please use the Windows Feedback tool built directly into Windows 10.

Smooth Interaction and Motion with the Visual Layer

The Composition APIs come with a robust animation engine that provides quick and fluid motion running in a separate process from your Universal Windows Platform (UWP) app. This provides a consistent 60 frames per second when running your app on an IoT device as well as on a screaming gaming machine. It is, quite simply, fast.


The Composition APIs also provide something you probably have never had access to before: the ability to create high-performing, low-level manipulation-driven custom animations like the one shown above.  Preview releases of the Composition APIs have already given you the ability to control animations with the XAML ScrollViewer’s ManipulationPropertySet. The Windows 10 Anniversary Update allows you to go even further, with the goal of empowering developers to use many types of input to drive animation.

This post will briefly cover the basics of expression animations. It will move on to a demonstration of how to drive expression animations from a ScrollViewer ManipulationPropertySet and, more importantly, why you really want to even if you don’t realize it yet. Finally, it will touch on the new InteractionTracker and give you an indication of just how much more powerful you are today as a developer than you were at the end of July.

A fast and fluid overview of expression animations

The Visual Layer supports both keyframe animations as well as expression animations. If you have worked with XAML animations before, then you are probably already familiar with how keyframes work. In a keyframe animation, you set values for some property you want to change over time and also assign the duration for the change: in the example below, a start value, a middle value, and then an ending value. The animation system will take care of tweening your animation – in other words, generating all the values between the ones you have explicitly specified.

ScalarKeyFrameAnimation blurAnimation = _compositor.CreateScalarKeyFrameAnimation();
blurAnimation.InsertKeyFrame(0.0f, 0.0f);
blurAnimation.InsertKeyFrame(0.5f, 100.0f);
blurAnimation.InsertKeyFrame(1.0f, 0.0f);
blurAnimation.Duration = TimeSpan.FromSeconds(4);
blurAnimation.IterationBehavior = AnimationIterationBehavior.Forever;
_brush.StartAnimation("Blur.BlurAmount", blurAnimation);

A keyframe animation is a fire-and-forget mechanism that is time based. There are situations, however, when you need your animations to be coordinated and actually driving each other instead of simply moving in synchronized fashion.


In the demo above (source code), each gray gear is animated based on the animation of the gear preceding it. If the preceding gear suddenly goes faster or reverses direction, it forces the following gear to do the same. A keyframe animations can’t create motion effects that work in this way, but expression animations can. They are able to do so because, while keyframe animations are time based, expression animations are reference based.

The critical code that hooks up the gears for animation in the demo is found in the following section that calls the CreateExpressionAnimation method on the Compositor instance. The expression basically says that the animation should reference and be driven by the RotationAngleInDegrees property of the Visual that is indicated by the parameter “previousGear”. In the next line, the reference parameter is assigned. In the final line, the current Visual’s RotationAngleInDegrees property is finally animated based on the value referred to in the ExpressionAnimation object.

private void ConfigureGearAnimation(Visual currentGear, Visual previousGear)
    // If rotation expression is null then create an expression of a gear rotating the opposite direction
    _rotationExpression = _rotationExpression ?? _compositor.CreateExpressionAnimation("-previousGear.RotationAngleInDegrees");

    // put in placeholder parameters
    _rotationExpression.SetReferenceParameter("previousGear", previousGear);

    // Start the animation based on the Rotation Angle in Degrees.
    currentGear.StartAnimation("RotationAngleInDegrees", _rotationExpression);

But if an animation can be driven by another animation, you may be wondering, couldn’t we also drive an animation with something more concrete like user input? Why, yes. Yes, we can.

The beauty of the ScrollViewer ManipulationPropertySet

Driving an animation from a ScrollViewer using XAML-Composition interop is fairly easy. With just a few lines of code, you can add an animation to a pre-existing ScrollViewer control by taking advantage of the GetScrollViewerManipulationPropertySet method on the ElementCompositionPreview class.

You would use this technique if you wanted to add a parallax effect to your XAML or to create a sticky header that stays in place as content scrolls beneath it. In the demo illustrated below (source code), a ScrollViewer is even used to drive a parallax effect on a ListView.


Adding parallax behavior to a XAML page can be accomplished in just a few lines, as the following sample code by James Clarke demonstrates.

CompositionPropertySet scrollerManipProps = ElementCompositionPreview.GetScrollViewerManipulationPropertySet(myScroller);

Compositor compositor = scrollerManipProps.Compositor;

// Create the expression
ExpressionAnimation expression = compositor.CreateExpressionAnimation("scroller.Translation.Y * parallaxFactor");

// wire the ParallaxMultiplier constant into the expression
expression.SetScalarParameter("parallaxFactor", 0.3f);

// set "dynamic" reference parameter that will be used to evaluate the current position of the scrollbar every frame
expression.SetReferenceParameter("scroller", scrollerManipProps);

// Get the background image and start animating it's offset using the expression
Visual backgroundVisual = ElementCompositionPreview.GetElementVisual(background);
backgroundVisual.StartAnimation("Offset.Y", expression);

The even more beautiful InteractionTracker

Driving expression animations with a ScrollViewer is extremely powerful, but what if you want to drive animations using touch gestures instead? What if you want to pull items toward you with your finger, as in the demo below (source code), or animate multiple flying images across and into the screen as happens in the demo at the top of this post (source code)?


In order to achieve these effects, you would use the new InteractionTracker and VisualInteractionSource classes. InteractionTracker is a state machine that can be driven by active input. This is what you hook up to your animations. The VisualInteractionSource class, on the other hand, determines what kind of input you will use to drive your InteractionTracker.


The following sample code demonstrates a basic implementation of an InteractionTracker that is driven by touch input. The viewportVisual is simply the backing Visual for the root element on the page. You use this as the VisualInteractionSource for the tracker. In doing so, you specify that you are tracking X and Y manipulations. You also indicate that you want to track inertial movement.

_tracker = InteractionTracker.Create(_compositor);

var interactionSource = VisualInteractionSource.Create(viewportVisual);

interactionSource.PositionXSourceMode = InteractionSourceMode.EnabledWithInertia;
interactionSource.PositionYSourceMode = InteractionSourceMode.EnabledWithInertia;


Hooking the tracker up to an expression animation works basically the same way as hooking up a gear Visual to another gear Visual, as you did earlier. You call the CreateExpressionAnimation factory method on the current Compositor and reference the Position property of the tracker. You then animate the Offset property of the Visual you want to add motion to your expression.

var positionExpression = _compositor.CreateExpressionAnimation("-tracker.Position");
positionExpression.SetReferenceParameter("tracker", _tracker);

contentVisual.StartAnimation("Offset", positionExpression);

Those are the basics of driving animation from almost any input. What you do with this amazing new power is entirely up to you.

Wrapping up

Expression animations and Visual Layer Interactions are both topics that can become very deep, very fast. To help you through these deeper waters, we highly recommend the following videos and articles:

Get started now – download Visual Studio.

The Windows team would love to hear your feedback. Please keep the feedback coming using our Windows Developer UserVoice site. If you have a direct bug, please use the Windows Feedback tool built directly into Windows 10.

Introducing Arduino Wiring on Windows 10 IoT Core

Developers targeting Windows 10 IoT Core can use a programming language of their choice. Today, this includes C#, C++, Visual Basic, JavaScript, Python and Node.js, but we’re not stopping there. Arduino Wiring is the latest addition to IoT Core.

Arduino is one of the most popular platforms among makers. Its community has produced a large number of libraries to interface with peripherals such as LED displays, sensors, RFID readers and breakout boards. One of the main drivers for Arduino’s adoption is its simplicity. With Windows 10 IoT Core, you can now create or port Arduino Wiring sketches that will run on supported IoT Core devices, including Raspberry Pi 2, 3 and Minnowboard Max.

Creating your first Arduino Wiring sketch for IoT Core

You can find the detailed steps for creating Arduino wiring sketches in the Arduino Wiring Project Guide. In addition, here is a quick summary:


  • Upon project creation, a sketch file with the same name and the extension ‘.ino’ will be created and opened by default. The sketch includes a template for Arduino Wiring using a classic hello world LED blinking code. More details about the Arduino Wiring template and required device setup can be found at the Hello Blinky (Wiring) page.


  • Before deploying, make sure to change the driver on the target device to DMAP. For more details, follow the instructions in the Lightning Setup Guide.
  • Finally, select your remote machine and press F5 to build and deploy your app to your device. Go back to the Arduino Wiring Project Guide for additional guidance.

How does an Arduino Wiring sketch run on an IoT Core device

On an IoT Core device, an Arduino Wiring sketch runs as a background application (headless); i.e. there is no UI visible on an attached monitor. This is similar to running a sketch on an Arduino device such as the Arduino Uno for example. However, you can still debug the sketch as you would any other app under Visual Studio by inserting breakpoints and/or stepping through the code. Additionally, to enable verbose output logging, Serial.print() and Serial.println() have been updated to send their output to Visual Studio’s debug pane when the sketch is running under the debugger (the output will also be sent to the serial pins). The Log() function can be used to output to debug as well. Check the Arduino Wiring Porting guide for more details on using Serial.print*() on IoT Core devices.

Porting an Arduino wiring sketch or library to Windows 10 IoT Core

For many Arduino Wiring sketches, simply copying the source code from the existing one to a new Arduino Wiring project in Visual Studio editor and replacing the pin numbers with the ones on your device would suffice.

However, while we have tried to make our implementation as close as possible to other Arduino-based devices, in some cases, a few modifications need to be made to your sketch to make it compatible with the Windows IoT Core OS, the C++ compiler or the board the sketch is running on. The Arduino Wiring Porting Guide covers many of those modifications needed and solutions to problems you may face while porting your sketch.

To use an existing Arduino library, you simply need to copy and add the header (.h) and source file (.cpp) for the library to your project, then reference the header file. Again, most libraries should work with no or very few modifications. However, if you face any issues, please check the Arduino Wiring Porting Guide.

Writing Windows 10 IoT Core specific code

For your scenario, you may want to write code parts that target Windows 10 IoT Core only, but at the same time maintain compatibility with other devices. For that, you can use the _WIN_IOT macro; e.g.:

#ifdef _WIN_IOT
// Windows IoT code only
// Other platforms code

Arduino Wiring and the Universal Windows Platform (UWP)

Arduino sketches runtime behavior on IoT Core devices is similar to other Arduino devices, with every function implemented to work the same way when interacting with the various controllers. However, Arduino Wiring sketches are also Windows UWP apps and thus can be extended to call any UWP APIs such as networking, storage, Bluetooth, media, security and others; for example, you can communicate with Bluetooth devices, connect to Wi-Fi network or even create a OneNote app using Arduino Wiring.

Additionally, you can wrap your sketch inside a WinRT library and use it in any UWP app, including UI apps. Building Arduino Wiring Libraries guide details the steps needed to create Arduino Wiring based libraries.

Additional Resources:

Here are additional resources to assist with creating/porting Arduino Wiring apps running on Windows 10 IoT Core:

Also, check out these Arduino Wiring samples:

OneNote Cloud Services Weather Station Stepper Motor
RGB Pixel LCD Text Display DC Motors

Finally, please add your questions/comments below or send your feature requests to the Lightning repository on GitHub.

Get started with Visual Studio.

Interop between XAML and the Visual Layer

The Composition APIs empower Universal Windows Platform (UWP) developers to do beautiful and powerful things when they drop down to the Visual Layer (as in the sample below). One of the remarkable things about these APIs is that they are designed, end-to-end, to integrate with the XAML Layer. Because of this built-in interoperability, the Composition APIs allow you to visually enhance your current XAML code without needing to replace it.


This post will cover the specific APIs for pulling Visuals out of your XAML as well as pushing Visuals back into your layout. These are also known as hand-out Visuals and hand-in Visuals. Additionally, we’ll cover some details of property sharing between the Framework Layer and the Visual Layer which you will find helpful to get under your belt. We’ll finish off with a dessert recipe (hint, it includes frosting) that demonstrates how the interop between XAML and the Visual Layer is used to create sweet effects.

Let’s talk about hand-out Visuals

Each XAML UIElement in your page layout has a backing Visual that is used for rendering. Because Visuals can contain other Visuals, the tree made up of Visuals tends to be larger than the logical tree made up of XAML elements. If you have been working with XAML for a while, you are probably already familiar with this concept of visual trees and logical trees.


Using the interop class ElementCompositionPreview, which is the workhorse of XAML-Composition interop, you can grab the backing visual for any page element by calling the GetElementVisual method.

Visual backingVisual = ElementCompositionPreview.GetElementVisual(MyImage);

In fact, grabbing the root backing Visual for your page, rather than a specific element, is a common way to retrieve the current Compositor instance.

// Get the current compositor
Compositor compositor = ElementCompositionPreview.GetElementVisual(this).Compositor;

The Visual you receive from ElementCompositionPreview in this way is referred to as a hand-out Visual. Several properties of a hand-out Visual are effectively shared between your XAML and the Composition API so that changes to UIElement properties — such as those related to position, height and width — can alter the Offset and Size properties of the Visual. Some care should be taken when working with these properties, however. While hand-out Visuals receive property changes made to UIElements, UIElements will not read property changes made to hand-out Visuals. The flow of property information flows in only one direction.

Welcome to Composition Island

The SetElementChildVisual method of ElementCompositionPreview plays the role of equal and opposite reaction to the GetElementVisual method. It allows you to take a Visual you have created and add it to a UIElement’s visual tree. When a Visual is added in this way, it is called a hand-in Visual. It doesn’t participate in property sharing the way hand-out Visuals do. Instead, a hand-in Visual acts as a Composition Island: an isolated piece of Visual-based content surrounded by a sea of XAML.


By default, a hand-in Visual is added as the last member of the UIElement’s visual tree, placing it prominently on top of other child Visuals.

Visual dataIsland = _compositor.CreateSpriteVisual();
ElementCompositionPreview.SetElementChildVisual(MyImage, dataIsland);

ElementCompositionPreview also has a third method, GetElementChildVisual, which takes a UIElement as an argument and returns the hand-in Visual you previously added to the element’s visual tree.

Things you should know about property sharing and property stomping

As discussed above, property sharing between the Framework Layer and the Visual Layer can be a little tricky if you aren’t careful. The following Visual properties are shared between UIElements and their backing Visuals:

  • Offset
  • Size
  • Opacity
  • TransformMatrix
  • Clip
  • CompositeMode

Size and Offset are especially tricky because, as mentioned before, a UIElement isn’t aware of changes to the property values on the hand-out Visual, even though the hand-out Visual is aware of changes to the UIElement. Consequently, if you change the value of the hand-out Visual’s Offset or Size property and the UIElement’s position changes due to a page resize, the UIElement’s previous position values will stomp all over your hand-out Visual’s values.

There is a simple trick that will allow you to avoid property stomping, though. Place your UIElement inside a Grid control or Border control. Then instead of setting position properties directly on your UIElement, you should set them on the wrapper instead.

<Border x:Name="ElementWrapper" Margin="5" VerticalAlignment="Top" Width="300">
    <Image x:Name="MyImage" Source="Assets/Lenna.png"/>

By doing this, the UIElement’s position appears to never change from its default settings, and so it doesn’t draw any attention during the layout pass, thus avoiding any unwanted property stomping. Additionally, changes to the hand-out Visual’s Offset property will be relative to the position of the wrapper.

You can find out more about property stomping in Robert Mikhayelyan’s blog post about Changes to XAML-Composition Interop.

Recipe: How to add frosting to the Visual Layer

In the following recipe, you will add a frosted glass effect to a XAML element that is overlaid on top of an image. This effect illustrates both the GetElementVisual and SetElementChildVisual methods at work. A more detailed example of this recipe can be found in the Dev Center post Visual Layer with XAML.

Let’s start with a simple image control.


While you could add the frosting effect directly to the Image control, placing a canvas over it and then applying a Composition effect to the canvas better demonstrates how smoothly XAML and the Visual Layer work together.

<Border x:Name="ElementWrapper" Margin="5" VerticalAlignment="Top" Height="300" Width="300">
    <Image x:Name="MyImage" Source="Assets/Lenna.png"/>
<Canvas x:Name="FrostHost" Width="130" Height="300" Margin="5"
    HorizontalAlignment="Right" VerticalAlignment="Top"/>

There are basically four steps involved in adding frosting to the FrostHost element:

  1. Grab the backing Visual for FrostHost with GetElementVisual
  2. Define and create the effect
  3. Create a new Visual and apply the effect to it
  4. Insert the new Visual into FrostHost’s visual tree with SetElementChildVisual

In the first step, you can kill two birds with one stone by grabbing the backing Visual with GetElementVisual and retrieving the current Compositor at the same time.

Visual hostVisual = ElementCompositionPreview.GetElementVisual(FrostHost);
Compositor compositor = hostVisual.Compositor;

You define the frost effect by creating a blur effect and chaining it to a tint effect by setting one of its sources to a solid color. The compositor is then used to actually create the effect.

// Create a frosty glass effect
var frostEffect = new GaussianBlurEffect
    BlurAmount = 15.0f,
    BorderMode = EffectBorderMode.Hard,
    Source = new ArithmeticCompositeEffect
        MultiplyAmount = 0,
        Source1Amount = 0.5f,
        Source2Amount = 0.5f,
        Source1 = new CompositionEffectSourceParameter("backdropBrush"),
        Source2 = new ColorSourceEffect
            Color = Color.FromArgb(255, 245, 245, 245)

// Create an instance of the effect and set its source to a CompositionBackdropBrush
var effectFactory = compositor.CreateEffectFactory(frostEffect);
var backdropBrush = compositor.CreateBackdropBrush();
var effectBrush = effectFactory.CreateBrush();

effectBrush.SetSourceParameter("backdropBrush", backdropBrush);

Next, you create a new SpriteVisual using your compositor instance and add the frosting effect you created above to it.

// Create a Visual to contain the frosted glass effect
var frostVisual = compositor.CreateSpriteVisual();
frostVisual.Brush = effectBrush;

All that remains is to insert the new Visual back into your XAML as a hand-in Visual by using SetElementChildVisual. As a final touch, you can also sync your hand-in Visual with your hand-out Visual.

// Add the blur as a child of the host in the visual tree
ElementCompositionPreview.SetElementChildVisual(FrostHost, frostVisual);

// Make sure size of frost host and frost visual always stay in sync
var bindSizeAnimation = compositor.CreateExpressionAnimation("hostVisual.Size");
bindSizeAnimation.SetReferenceParameter("hostVisual", hostVisual);

The result is a picture half-frosted over by the FrostHost canvas placed on top of it. What’s interesting here is that the frosting was not added to the picture but to a different element. As we would hope, though, the effect passes through to the underlying image without any artifacts or airspace issues.


Wrapping up

The ability to pull hand-out Visuals from your XAML and to insert Composition Islands back into it provides a highly accessible way to go back and forth between the Framework Layer and the Visual Layer. Understanding the central role of the ElementCompositionPreview class is important to accomplishing smooth integration between your XAML and the Composition APIs. If you would like to go even deeper into the Interop story behind Windows.UI.Composition, we highly recommend the following resources.

Get Started with Visual Studio.