We live and work in a fast-paced, real-time, information environment where the scarcest resource of all is not information itself, but human attention to that information. This is why user experiences and UI need to evolve to more effectively target human attention amid the cacophony of data and distraction. Success or failure of apps presenting the same information can come down to having the most engaging experience. This means creating more personal experiences that are playful, create delight, and drive up engagement, as they provide users with the insights and information they seek. A focus on creating beautiful experiences allows developers to differentiate their apps from the competition.
This is why the Windows platform enables developers to build beautiful apps, simply and by default.
Although this story will unfold over time, today we to announce the first chapter with a brand new family of APIs in the November update of Windows 10 under the Windows.UI.Composition namespace.
This new family of WinRT APIs contains light-weight visuals, animations, effects, and manipulations to create smooth and highly-scalable UI experiences, inspired by the motion and graphical design evolutions in the world around us: in movies, on television, in app and game designs, in print and elsewhere. You can use this functionality within your existing XAML–based Universal Windows Platform app (UWP). In future we expect to support desktop apps as well.
In the initial release of Windows 10, significant work was done to create a new unified compositor and rendering engine for all UWP applications running on Windows 10 devices .
Now with the first update of Windows 10, Build 10586, we are releasing this public API and Windows.UI.Composition.
What is Windows.UI.Composition?
The Windows.UI.Compositon WinRT APIs can be called from any Universal Windows Platform app to create lightweight visuals and apply powerful animations, effects, and manipulations on those objects in your application. The goal is not to replace any existing framework, but to be a valuable supplement to existing frameworks.
In the past, this kind of work was difficult to do in a UWP application and required basic app developers drop off a steep cliff down to DirectX for custom UI work.
With the new API a XAML developer can “drop down” and do custom work in the composition layer using WinRT to create a “Composition Island” of objects in a familiar WinRT language such as C#.
How does this help you with a beautiful engaging UI? By giving you access to this new layer of APIs, Windows.UI.Composition lets you create composition objects directly in the compositor layer, which improves performance and scale using exciting new features.
The New Effects System
Real-time effects that can be animated, customized and chained. Effects include 2D affine transforms, arithmetic composites, blends, color source, composite, contrast, exposure, grayscale, gamma transfer, hue rotate, invert, saturate, sepia, temperature and tint.
Below is an example of a saturation effect that shows a number of key concepts, effects can be defined once and reused multiple times, effects are based on the concept of sources as inputs to effects and effects can be a source to another effects enabling chaining. Effects can be set for animations.
// Create the graphics effect
var graphicsEffect = new SaturationEffect
{
Name = "SaturationEffect",
Saturation = 0.0f,
Source = new CompositionEffectSourceParameter("mySource")
};
// Compile the effect specifying saturation is an animatable property
var effectFactory = _compositor.CreateEffectFactory(graphicsEffect, new[] { "SaturationEffect.Saturation" });
myEffect = effectFactory.CreateBrush();
myEffect.SetSourceParameter("mySource", surfaceBrush);
myEffect.Properties.InsertScalar("saturationEffect.Saturation", 0f);
Windows.UI.Composition has an expressive, framework-agnostic animation system that allows you to set up Keyframes and Expressions that can move the new lightweight Visuals, drive a transform or a clip, or animate an effect. By running directly in the compositor process, the new system ensures smoothness and scale, letting you run large numbers of concurrent, explicit animations. Below is a quick example of how a KeyFrame animation is structured using a the predefined effect above. Key concepts to take note here are that KeyFrame based animations allow effects, or transforms or any animatable objects in the API to animated over time.
// Create a ScalarKeyFrame to that will be used to animate the Saturation property of an Effect
ScalarKeyFrameAnimation effectAnimation = _compositor.CreateScalarKeyFrameAnimation();
effectAnimation.InsertKeyFrame(0f, 0f);
effectAnimation.InsertKeyFrame(0.50f, 1f);
effectAnimation.InsertKeyFrame(1.0f, 0f);
effectAnimation.Duration = TimeSpan.FromMilliseconds(2500);
effectAnimation.IterationBehavior = AnimationIterationBehavior.Forever;
// Start the Animation on the Saturation property of the Effect
myEffect.Properties.StartAnimation("saturationEffect.Saturation", effectAnimation);
A Deeper Look Starting with the Basics: The Composition Visual Sample
Before diving into the advanced concepts of the API, a good place to start is learning the fundamental concepts by looking at how objects are created using a Compositor and doing basic transformations and tree operations on those objects.
You can learn some of the basic concepts of the API in the CompositionVisual sample from our Composition GitHub. This sample is a simple framework-less app written entirely in the API.
In the sample there are a number of transparent, solid color squares that can be clicked on and dragged about the screen. When clicked on, a square will come to the front, rotate 45 degrees. Then when you drag it about the screen it will becomes opaque.
This shows a number of basic concepts for working with the API including:
Creating a compositor
Creating a SpriteVisual with a ColorBrush
Clipping a Visual
Rotating a Visual
Setting Opacity
Changing the Visual’s position in the collection.
In the sample there are also three different Visuals at work:
Visual – base object, the majority of the properties are here, and inherited by the other Visual objects.
ContainerVisual – derives from Visual, and adds the ability to create children.
SpriteVisual – derives from ContainerVisual and adds the ability to associate a brush that paints pixels, is used to paint the Visual with images, effects or a solid color on the Visual.
While this sample doesn’t cover concepts like Animations or more complex effects, it contains the building blocks that all of those systems use. There will bemore links to supplemental information in future blog posts.
Please note, all example code below is in C#.
Creating a Compositor
Creating a Compositor and storing it for use as a factory in a _variable is a simple task. This is a simple line of code:
_compositor = new Compositor();
Creating a SpriteVisual and ColorBrush
Using the Compositor it’s now easy to create objects whenever you need them, such as a SpriteVisual and a ColorBrush.:
var visual = _compositor.CreateSpriteVisual();
visual.Brush = _compositor.CreateColorBrush(Color.FromArgb(0xFF, 0xFF, 0xFF, 0xFF));
While this is only a few simple lines of code, it demonstrates a powerful concept, SpriteVisuals are the heart of our new effects system. The SpriteVisual allows for great flexibility and interplay in color, image and effect creation. The SpriteVisual is a single visual type that can fill a 2D rectangle with a brush, in this case a solid color.
Clipping a Visual
The Compositor can also be used to create clips on a Visual. Below is an example from the sample of using the InsetClip to trim each side of the Visual:
A Visual can be transformed with a rotation. RotationAngle supports both radeons and degrees. It defaults to Radeons, but it’s easy to specify degrees as shown in below:
child.RotationAngleInDegrees = 45.0f;
Rotation is just one example of a set of transform components provided by the API to make these tasks easier. Other include Offset, Scale, Orientation, RotationAxis and a 4×4 TransformMatrix.
Setting Opacity
This is also a simple operation using a float value. For example, in the sample all the squares start at .8 opacity:
visual.Opacity = 0.8f;
Important Note: All of the clips and transforms above, like almost all objects in the API, are animatable.
Managing Your Visual tree
A Visual’s position relative to its sibling’s can be changed in a number of ways when it is added or moved in the tree, it can be placed above another Visual with InsertAbove, placed below with InsertBelow, move to the top with InsertAtTop or the bottom with InsertAtBottom.
In the sample a Visual that has been clicked on is sorted to the top:
parent.Children.InsertAtTop(_currentVisual);
It’s also important to note that while sibling re-ordering appears to change Visual z-order, this is still essentially a 2D scene, and does not represent a true global 3D z-order.
XAML Interoperability
One of the key concepts of the new API is the ability to add a “composition island” of objects directly to a XAML application. A developer can get the backing Visual of a UIElement in XAML and apply an animation or load a custom image an apply an effect.
Thanks to all of you who tried out the preview version of the API, for your efforts and feedback. You helped make this a better API. As a preview user there are several things to note about the final API:
You no longer need to declare a security capability in your manifest, the API is fully public.
We have removed the SolidColorVisual, ImageVisual and EffectVisual. You now use Color, Image and Effects through SpriteVisuals.
Pause and Resume were removed from animation system to streamline using Start and Stop.
Earlier this year, we announced the availability of Windows IoT Core – a new edition of Windows designed for maker boards and small devices. We’ve been busy the past few months continuing to make improvements to the platform, with the goal of making Windows IoT Core the best platform for IoT developers and makers.
Of course, we’re far from done. One challenge that we hear from the maker community is the ability to quickly and easily connect to the cloud. Certainly, we’ve seen it done, but it required jumping through a number of hoops. When you’re a maker, added tasks detract from your ultimate goal. You already have multiple priorities competing for your time, energy and attention: Connecting to the cloud shouldn’t be any harder than lighting up an LED.
Fortunately, connecting your IoT device to the cloud has just become easier than ever. The process is straightforward, and best of all, is free for makers.
Azure IoT Hub
Azure IoT Hub is a Microsoft Azure cloud service that offers reliable and secure device-to-cloud and cloud-to-device messaging that scales to millions of devices. Yet getting started is simple, with a streamlined programming model and platforms and protocols you already know. With Azure IoT Hub, makers can get started with minimum effort and scale up your solution as its needs grow, without having to rewrite it or rework what you’ve already built.
Getting started
First, to deploy applications on Windows IoT Core, you’ll need to have Microsoft Visual Studio 2015 (or download the free Community edition here). You’ll also need an active Azure subscription (you can start with a free trial subscription), and then choose a free version of the Azure IoT Hub service.
To set up an instance of the IoT Hub, log on to the Azure Portal and click “New” on the jumpbar on the left, then “Internet of Things,” then “IoT Hub.” (The process is straightforward, but if you want additional pointers, there are great tips in this article). Be sure to choose “F1 –Free” pricing and scale tier. The free option provides one IoT Hub per subscription, which includes 10 devices and 3000 messages per day.
Creating a device ID
Once you’ve set up your instance of IoT Hub, the first thing you need is to create the identity for your device. Every device must have a key that uniquely identifies it to the service. This way the IoT Hub can securely associate the data with the device that sent it.
To create a device ID, use a tool called ‘iothub-explorer’. The tool requires Node.js, so make sure it’s installed on your machine (or get it here).
Now open the command line prompt and install the iothub-explorer package:
npm install -g iothub-explorer@latest
The tool will need the connection string to connect to your instance of the Azure IoT Hub. You can find the connection string in the Azure Portal under the settings tab of your IoT Hub instance: navigate to Settings | Shared access policies | Connection string – primary key.
Now create a new device called ‘MyDevice’. Run the tool as follows:
Remember to use your actual connection string in the above command. The tool will create the new device ID and output the primary key for the device, among other things. The primary key is what you’ll use to connect your device to the IoT Hub.
The tool also allows you to list and delete existing devices, as well as listen to the messages coming into the IoT Hub. It might be worth taking a few minutes to explore the tool. Type ‘iothub-explorer help’ to learn about the other commands.
Hello, Cloud!
You’re now ready to start sending data to the cloud.
In Visual Studio 2015, go to File | New | Project menu, select the Blank App UWP application and call it ‘HelloCloud’:
You will use the Microsoft.Azure.Devices.Client library to connect to Azure, so go ahead and install it from the NuGet gallery. (And if you’re curious to know what’s in this library, you can check it out on GitHub: github.com/azure/azure-iot-sdks)
Add these using directives at the top of the file:
using System.Text;
using Microsoft.Azure.Devices.Client;
Next, in the generated project, open the MainPage.xaml.cs file and add the following function to the MainPage class:
static async void SendDeviceToCloudMessagesAsync()
{
string iotHubUri = "<replace>"; // ! put in value !
string deviceId = "<replace>"; // ! put in value !
string deviceKey = "<replace>"; // ! put in value !
var deviceClient = DeviceClient.Create(iotHubUri,
AuthenticationMethodFactory.
CreateAuthenticationWithRegistrySymmetricKey(deviceId, deviceKey),
TransportType.Http1);
var str = "Hello, Cloud!";
var message = new Message(Encoding.ASCII.GetBytes(str));
await deviceClient.SendEventAsync(message);
}
Then, invoke this new function from the constructor of your MainPage class in the MainPage.xaml.cs file:
public MainPage()
{
this.InitializeComponent();
SendDeviceToCloudMessagesAsync();
}
A few things need to be adjusted in the above code before you can run this app. The iotHubUri needs to be set to the Uri of your IoT Hub, the value of which you can find under the Settings tab. (This should look like your_hub_name.azure-devices.net). The deviceId and deviceKey were created earlier by the CreateDeviceIdentity tool – remember to replace them as well.
Run the app on your IoT device (if you need instructions on how to set up your device, see here) and – voila! – your data has been sent to the cloud.
Processing data in the cloud
Sending data to the cloud is only meaningful if something useful can be done with the data once it gets there. There are many ways to process data in Microsoft Azure – you can connect it to other services such as Azure Stream Analytics, store it into an Azure Blob, visualize it in PowerBI etc.
One simple example is to write an app that retrieves messages sent to the IoT Hub and displays them in a console window – not too fancy, but you can imagine doing something more interesting, such as triggering an alert or sending a command back to the device.
Create a console application in Visual Studio 2015 named ‘ReadDeviceToCloudMessages’. Add the WindowsAzure.ServiceBus library from the NuGet gallery and replace the generated Program.cs with the following code:
using System;
using System.Text;
using System.Threading.Tasks;
using Microsoft.ServiceBus.Messaging;
class Program
{
static void Main(string[] args)
{
string connectionString = "<replace>";
string iotHubD2cEndpoint = "messages/events";
var eventHubClient = EventHubClient.
CreateFromConnectionString(connectionString, iotHubD2cEndpoint);
var d2cPartitions = eventHubClient.GetRuntimeInformation().PartitionIds;
foreach (string partition in d2cPartitions)
{
var receiver = eventHubClient.GetDefaultConsumerGroup().
CreateReceiver(partition, DateTime.Now);
ReceiveMessagesFromDeviceAsync(receiver);
}
Console.ReadLine();
}
async static Task ReceiveMessagesFromDeviceAsync(EventHubReceiver receiver)
{
while (true)
{
EventData eventData = await receiver.ReceiveAsync();
if (eventData == null) continue;
string data = Encoding.UTF8.GetString(eventData.GetBytes());
Console.WriteLine("Message received: '{0}'", data);
}
}
}
As before, replace the connection string with the actual connection string for your IoT Hub instance.
When you compile and run the application, it will start listening for the messages sent to the IoT Hub. To make sure it works, re-run the HelloCloud UWP application that you built before. You should see the following output coming from the ReadDeviceToCloudMessages:
Message received: ‘Hello, Cloud!’
What’s next
You can find the basic example explored here, as well as more advanced samples, on GitHub: https://github.com/ms-iot/samples. The Azure-specific examples are located in the Azure subfolder.
In the next installment of this blog series, we’ll look into more advanced ways of processing data in the cloud, as well as sending data from the cloud back to the device.
This is neither the beginning nor the end of the journey to make cloud connectivity easy and accessible. Your feedback helps us determine what we should do next, and how we prioritize our work. Please add your comments below – we look forward to hearing from you!
Post written by Artur Laksberg, a principal software engineer in Windows
As part of the periodic improvements to Dev Center, I want to share details about several new capabilities, as well as ideas on how to make best use of them:
Multi-user access with roles: support multiple users in a single account, with permissions controlled through user roles – this is one of the most voted for features in user voice, and is available now in all Dev Center accounts
Windows Store APIs: validate apps or in-app product acquisitions, useful for cross-platform services, or to add another layer of validation for customer purchases
In-app purchase discounts: schedule IAP price discounts for apps running on Windows 10
Access to Office and Azure programs: access the Office and Azure developer programs at no extra cost through the Dev Center registration
More effective Store lists: The Store is updating the algorithms for the “New and Rising” and “Best Rated” lists to be able to show more apps than before
Update to the Windows App Certification Kit: with additional validation tests for UWP app submissions
1. Multi-user access with roles
This week’s release includes one of the most requested features in Dev Center: support for multiple users in a single Dev Center account with the ability to assign the roles and capabilities of each user. This feature enables much greater account management flexibility with different permissions through managed roles: Image may be NSFW. Clik here to view.
Roles allow you to, among other things, choose which users can manage and submit packages, restrict access to account financial information, or allow only select users to be able to respond to reviews.
This new capability requires an Azure Active Directory (Azure AD) account with admin permissions to create and manage accounts. If you aren’t familiar with Azure Active Directory, you can read all the details and how-to guides.
2. Windows Store purchase and collection APIs
This month, Dev Center released two REST APIs for Windows Store services that unlock new scenarios never before possible in the Windows Store:
Windows Store collection API: used to query if the app or IAP has been acquired, as well as to report a consumable IAP has been fulfilled
Windows Store purchase API: used to grant ownership of a free app or free IAP
These new APIs enable you to directly access Windows Store ownership information for paid apps and IAPs from your services, giving you more control over purchase security. These APIs use Azure Active Directory (Azure AD) and enable advanced app scenarios, for example:
Additional layer of fraud protection: when a user opens a paid app or attempts to use an IAP, the publisher can check with the service (directly or through the publisher servers) to verify that the user actually purchased that item before granting access in the app.
Support for cross-platform services: if a user purchases an IAP in a Windows Store app, the publisher can confirm the user owns that app or IAP, and then enable that same feature in the same app in another platform, or on the Web.
The holidays are a great time to encourage users to purchase IAPs through discounted pricing. You can now schedule a sale for your IAPs. Just like app sales, when you publish a sale for an IAP, the price will drop at the start date and time you specify, and will automatically revert to the original price at the end date and time. You can configure sales with a duration of up to 30 days.
To schedule a sale in Dev Center, go to the Pricing and Availability page in an IAP submission, and select “Sale Pricing.” Give your sale a name (optional, not displayed to customers), then set the sale price, start date/time and end date/time, click or tap “Save,” to submit the IAP to the Store. You can also configure per-market pricing for your IAP sales. Image may be NSFW. Clik here to view.
Sales prices will only be visible to Windows 10 customers. If you use the Dev Center IAP Sale Pricing feature, customers running Windows 8.x or Windows Phone 8.x will not see any discount. If you want your Windows 8.x or Windows Phone 8.x customers to receive the discounted IAP, you’ll need to lower the base price, and revert it when you want the discount to end.
When you put an IAP on sale, Windows 10 customers will see the sale price in the purchase screen from the start to end date of the sale. Customers running the Windows 10 November update will also see the IAP on your app description page in the Store, with the original price in strikethrough and the sale price highlighted. Image may be NSFW. Clik here to view.
4. One registration for Windows Dev Center + Azure + Office
Developers with a Windows Dev Center account or those signing up for a new account can also access the Azure Marketplace and Office Store developer programs for no additional fee.
This allows you to access Azure services and Office add-ins developer portals; Windows apps are still managed separately (the same way they are managed today, in their own Dev Centers). Payouts for Azure and Office developers are managed separately at this time as well, with the plan to merge the payout process in a future release.
5. More effective Store lists for customers
The Windows Store has updated the algorithm used to select apps for the “Best Rated” and the “New and Rising” lists.
Previously, the “Best Rated” apps and games list algorithm was based on ratings that the app received from all device families (Desktop/Tablet or Mobile). This update separates the ratings by device, so customers will see a more accurate app rating, based only on ratings created in that device family Image may be NSFW. Clik here to view.
When customers browse through a specific category in the Store, a “New and Rising” list highlights the apps and games recently added in that category. Previously, the algorithm limited the number of apps eligible to be shown. This update allows more apps to be shown, providing increased visibility and opportunity to more developers.
6. Updated Windows App Certification Kit
Finally, a new Windows App Certification Kit (WACK) was released this month, including additional Universal Windows Platform tests. The update also addresses an issue to correctly validate app resources like image sizes. The WACK will detect and warn if it finds these problems in your app, and beginning in February, 2016 these errors will fail an app submissions. To avoid any potential issues, please download and install the latest version of the WACK and use it to validate your UWP submissions. Learn more from WACK and the new tests.
Feedback
This month Dev Center has released some major improvements, including multi-user access with roles, Windows Store APIs, and more opportunities to promote apps through IAP discounts and more effective Store lists.
We are looking for feedback, so as you use these features, please let us know about your experience through the “Feedback” button in Dev Center (found in the bottom right) or vote for new features through User Voice.
We’re now a week into the Share Your Idea and the community has suggested over 3,000 ideas. Keep the ideas coming, and don’t forget to tell us which ideas are your favorite by voting for ideas (click the star). The ideas that are most likely to be chosen for the voting phase after January 11th are the ones that embrace the mixed world capabilities of HoloLens.
We wanted to give you a little look into the future of our blog postings. So far we’ve introduced the program, and discussed the skills need to build a holographic app. This week we’ll be talking about visual assets, and in the coming weeks we’re planning to cover the following topics:
Leveraging the strength of Windows (Cortana, Wi-Fi, Bluetooth, and more)
And remember, we’d love to hear from you! We’ll adjust our content based on what we hear from the community, so this is your opportunity to help shape what we write about in the future.
Now let’s dive in and talk about the visual assets that go into building these apps. Windows Holographic builds on the decades of investment Microsoft has made into DirectX. This means that all of the experience and skills developers have with building 3D graphics continues to be valuable with HoloLens. We’ll talk about three options for assets: (1) creating new assets, (2) converting existing assets and (3) capturing assets.
3D artists use digital creation tools to create models which consist of meshes, textures and materials. This is then saved in a file format that can be imported or used by the graphics engine used by the app, such as .FBX or .OBJ. Any tool that generates a model that your chosen graphics engine supports will work on HoloLens. Among 3D artists, many choose to use Autodesk’s Maya which itself is able to use HoloLens to transform the way assets are created. Both the developers and artists have to consider the capabilities of the device and the graphics engine. Microsoft HoloLens has all of the computational and graphics built into the device. It shares the capabilities developers would find on a mobile platform. For example, use less than 100,000 triangles in a rendered scene. Naturally, assets that use simple geometry and lighting effects are going to be easier to build. This includes toy cars, cartoon characters and rigid objects.
Many app ideas may start with reusing existing assets that were originally built for other devices and different apps. This can be done and it also showcases new opportunities when using the mixed world. These assets can show their true scale. So experiences like walking around furniture in your house, touring museum artifacts in your office and previewing that 3D printed object at a makerspace are all possible. Again, all developers need to do is convert these assets to formats compatible with the graphics engine their app is using. If the original model is too detailed, they’ll also have to decimate the mesh to match the HoloLens device’s graphics capabilities. Another excellent option for asset reuse is to purchase assets for your experience. There are a vast number and variety of assets available through services such as the Unity Asset Store, TurboSquid, others.
Lastly, there is an option to capture objects in 3D. Capturing inanimate objects in 3D and editing them with digital content creation software is increasingly popular with the rise of 3D printing. There’s also the opportunity to capture holographic video. Because the video played on HoloLens is literally a hologram, it can be viewed and heard from any angle and replayed in new environments. That means you can watch and then re-watch from another angle a magician and his card trick, the world champion in speed stacking or a loved one’s message. Holographic video was actually the very first thing we showed on HoloLens back when it was announced in January.
(This article is specifically for Windows 8 UAP application packaging. It does not apply to Windows 10 UWP application packaging in Visual Studio 2015 since the Create App Packages wizard does not create the required .appxupload package using the following steps.)
If you’re a publisher developing your app in-house, stop here. If you’re a 3rd party development vendor who has been given access by your publisher to their Store account credentials, no need to read further. In both of these cases, packaging your app for the publisher’s Store account is well-documented and straightforward. This article is for developers who need to package an app but are unable to get access to the publisher’s Dev Center account credentials. In this scenario, you’ll have to take some manual steps to ensure that the information in the appxmanifest.xml file matches what the publisher has configured in their Store account. Read on.
Packaging your Windows Store application using Visual Studio’s built in “Create App Packages” wizard is a straightforward and easy way to automatically configure your app’s appxmanifest.xml file with the correct app and publisher ID information for the Store. When you launch the wizard (Project > Store > Create App Packages…) you are asked “Do you want to build packages to upload to the Windows Store?”
If you select “Yes,” you’re prompted to enter in your Store (aka Dev Center) account credentials.
This is how Visual Studio associates the app with your publisher account so that it can pull down all the correct information from the Store to automatically populate the appxmanifest.xml. However, what if you don’t have access to the publisher’s Store account credentials? It’s common for a publisher to hire a 3rd party vendor to develop their application but retain the Store publishing processes in-house. In this case, the vendor is expected to deliver the packaged app to the publisher who then uploads it to their Store account separately. The “gotcha” in this scenario is that when the publisher attempts to upload the package to their Store account, Microsoft will reject the package with errors because it doesn’t include the correct publisher and app information in the appxmanifest.xml file.
The Create App Packages wizard clearly states that you need to sign into the Store account. Your only other option is to select “No” and you’re told you can only use the resulting package “…on a computer that has a developer license installed…”
Fortunately, there’s a work-around! Developers can ensure the app is configured with the correct publisher and app information without having to sign into the publisher’s Store account. This does, however, require that the publisher delivers specific information to the developer that they will manually insert into the Visual Studio Manifest Designer before proceeding with the Create App Packages wizard.
Step 1. After the publisher has reserved an app name, have them send you a screenshot of the Dev Center app identity page.
They will log into the Dev Center and navigate to the App Overview for the app. Once there, they’ll choose the App Identity item under App management on the left menu:
Step 2. You will open the solution in Visual Studio and view the Manifest Designer for the project (Note: the Manifest Designer opens when you open the package.appxmanifest file, not when you choose the “view code” option). Go to the “Packaging” tab. Click on the “Choose Certificate” button in the “Publisher” field of the form. The dialog below opens.
Step 3. Choose to “Create test certificate…” in the dialog.
Step 4. Enter the Package/Identity/Publisher string (without the “CN=”) you received from the publisher in Step 1 into the “Publisher Common Name:” field. No need to enter a password since this is only a temporary cert used just to get the correct publisher ID to populate the manifest. (Note: When the app has been uploaded to the Dev Center, the Store will automatically strip out this signing signature and will replace it with the Store signature anyways.)
“Package name:” = “Package/Identity/Name” value in the screenshot from Step 1.
“Package display name:” = “Name” value from Step 1.
“Version:” – whatever you want it to be. Just make sure that it is higher than any packages you’ve already uploaded to the Store for your target Device Family and architecture. Otherwise, users who already have your app installed won’t get the update. More details on app versioning are available here.
“Publisher:” – per Step 4 this should be the “Package/Identity/Publisher” value and is automatically populated from the Subject attribute of the signing cert you created in Step 4.
“Publisher display name:” = “Package/Properties/PublisherDisplayName” value from Step 1.
“Package family name:” – gets automatically populated as a combination of the “Package name:” and a hash of the “Publisher:” value.
Step 6. After saving the file, go to Project > Store > Create App Package. Make sure you select “No” since you’ve manually set the publisher/app manifest values already.
Step 7. Proceed to build the release packages for the architectures you want to release to. To check that the appxmanifest.xml was created with the appropriate values, unzip the .appx package and open the appxmanifest.xml file.
Following these simple steps, you’ve now created an .appxupload package that the publisher can upload successfully to their Store account. When the Store does its automatic check of the manifest values no errors should be thrown and the package should show up on the Packages page for the app. We hope this article has been helpful. Additional information on packaging your apps for the Windows Store can be found on the Windows Dev Center.
Post written by Tim Harader, Sr. Program Manager at Microsoft
Earlier this year, NPR released a Windows 8 version of NPR One for Windows, and recently, a Universal Windows Platform (UWP) version. They were eager to share their challenges and developer experiences in bringing the app to UWP.
NPR One provides talk radio personalized for each listener. NPR’s mission is to provide public radio content wherever the user is: on-the-go, at home, or at work. Windows provided a new way for their growing audience to listen. “When we released the Windows app, we had an unanticipated spike in iOS and Android downloads, as well” said Ben Schein, Product Manager at NPR. “Seventy percent of NPR listeners use Windows devices, and we’ve seen a 50-percent increase in their listening time just since Windows 10 came out. And that was before we upgraded our app.” The number of users and the adoption rate of Windows 10, over 110 million in the first two months, inspired NPR to create a native Windows 10 app. In consideration of this growth, NPR collaborated with InfernoRed Technology, who had worked on the original Windows 8 app. Together, they developed the upgrade, adapted the app to use NPR’s newly updated API’s, and designed the user interface pictured below.
The challenge NPR originally faced with the bringing the NPR experience to the PC was upsizing their mobile app design. As they approached the PC, they needed to design for a wider variety of screen sizes without sacrificing the core app experience, which is to sit back and listen. The original NPR app experience was designed for a four to five-inch phone screen. For larger screens, they began to explore how to use the extra space to deepen the experience with images. They wanted to avoid the traditional music-related imagery approach, as they don’t want to be in the business of finding quality visuals for every story, and even considered researching an automated way to provide related images. For NPR’s update to UWP, the developers leveraged Windows 10’s adaptive layouts to dynamically change the UI in response to different screen or window sizes. For example, when the app display reaches the large screen breakpoint, the app adjusts the interface elements to make better use of the screen real estate. When it reaches the small or mobile breakpoint, the app responds with a completely different UI design tailored to the condensed screen or window size.
“We’ve always strived to provide a simple, clean experience for users that doesn’t get in the way of them listening and getting to the content they want,” Schein notes. “Once we pivoted to think about that through the scope of displays as large as 20-30 inches, it gave us an opportunity to think about ‘simple’ through a different lens.”
While they are still looking for a better solution, they found a way to make a great user experience for their listeners by displaying a high-quality image when one is available, and a placeholder image when one is not. An example of their solution is below, the story metadata is displayed, non-intrusively inviting the listener to learn more.
To create a first-class audio experience for NPR One, the app needed to provide a continuous, reliable audio stream. The dev team needed to run the audio task in the background to optimize performance, even on less-than-ideal hardware. Plus, running the logic in the background meant the UI could be lightweight, while the background task did all the heavy lifting.
The developers leveraged the Windows background audio task, which allows audio to continue playing and to be accessed through the system volume controls even after the foreground app has been closed. Previously in their Windows 8.1 apps for PC and desktop, their background audio code could not be shared between projects, but now with apps built on the UWP it can be shared by both phone and desktop device families. The playback task uses IBackgroundTask, but slightly specialized for background audio. For example, unlike traditional background tasks, it is not registered in the foreground. Through BackgroundMediaPlayer.Current, the app accesses the MediaPlayer class, part of the Windows.Media.Playback namespace.
Cortana in NPR One
As the NPR One app is a mostly hands-off experience, NPR was intrigued by Cortana and the idea of being able to use your voice in situations where it might not be practical to use your hands. The InfernoRed development team needed to make the Cortana background task communicate with the background audio task, something it was not originally designed to do. “This meant we had to code our own clever custom solution for processing commands in the voice background task, then responding and taking action on them in the audio background task,” said Ed Snider, Senior Developer at InfernoRed. Based on the results of user research, they created a set of commands that cover how most listeners interact with the audio playback. Users can play specific programs or podcasts, and even mark the current or previous story they heard as interesting. And because the app is using the background audio task, the app is able respond to default media commands using Cortana, as well, such as “Pause,” “Play,” or “Skip.”
The developers have plans to utilize Cortana further as the feature set matures. “Working with Cortana was a lot of fun. It’s really cool to be able to lay out the voice command definitions and use them as the conduit from the user to the app,” said Scott Lock, CEO and Co-Founder at InfernoRed.
Part of the appeal of the app is its personalization feature and how that follows the user from one listening session to another, even to other devices. NPR One’s Windows app allows users to login to NPR One with their Microsoft Account. By leveraging the Live SDK REST API, the app provides seamless access to stored personalization settings. For example, while listening to a particular program, the users can tell Cortana to mark that content as interesting. This interaction is evaluated in the NPR One back end, which then provides listening recommendations from NPR’s curated inventory. This is done through an API call, so they won’t lose their settings or preferences, even if they change platforms.
We’re happy to announce that the video recordings from last weeks’ Developers’ Guide to Windows 10 live event are now available on-demand on Channel 9. This half day event is an addendum to the existing Developers’ Guide to Windows 10 video series and covers new features for developers in the Version 1511 release and the corresponding Windows 10 Build 10586 SDK.
The opening video, What’s New for Developers in Windows 10 Version 1511 and the 10586 SDK, brings us up to date with the Windows 10 story so far, from the initial release last summer of Windows 10 for desktop, laptop and convertibles and also for IoT devices such as the Raspberry Pi 2 and the Minnowboard Max, to the present release of the Version 1511 update.
Most significant in the Version 1511 update is the release of Windows 10 Mobile for phones and small tablets. This includes the new Continuum for phone, allowing modern devices such as the Lumia 950 and 950 XL to drive an attached screen such as a monitor or TV, in much the same way as a dual monitor setup for desktop PCs.
Along with phone support, there is also the new Build 10586 SDK which includes minor updates and bug fixes to the original 10240 SDK, and also a number of new APIs such as support for Bluetooth device pairing, Jump Lists attached to tiles, app listings in the Start Screen, and more.
Take a look at the new videos:
What’s new for developers’ in Windows 10 Version 1511 and the 10586 SDK – Andy Wigley and Shen Chauhan take you through a quick review of Windows 10 momentum, then an introduction to Continuum for phone. We explore the new Build 10586 SDK and review some of the updated UWP samples on Github, then explain how developers should version their apps to decide whether to target 10240, 10586 or both, and how to correctly program version-dependent code. Finally, we look at the new tools and packages in Visual Studio 2015 Update 1.
Building Apps for Continuum – Liz Threlkeld joins Andy to take a deeper look at what it takes to build apps to run on the connected screen in Continuum for phone. For most developers, there are no specific extra steps needed, just create an adaptive UI for your UWP app and you are good to go. We provide recommendations on scaling assets and look at those special cases where you want to create an app that runs on both displays at the same time.
Creating fluid and beautiful UI using the new Visual Layer – This API is one of the most exciting new features in the Build 10586 SDK. Formerly in preview in the original 10240 SDK, this API is now final and ready for use in your apps. Paul Gildea and John Serna from the engineering team show how to utilize new lightweight Visuals, Animations, Effects, and Manipulations to easily create smooth and highly scalable UI experiences for Windows 10 devices.
Moving beyond passwords and credential theft with Microsoft Passport and Windows Hello – Microsoft is on a mission to do away with passwords and instead replace them with more secure two-factor authentication techniques based on your device and a pin code or biometrics such as face, iris, or fingerprint recognition. Rajen Kishna joins Andy to explain how it works and how you can use these modern authentication techniques not only to log onto your Windows 10 devices but also to provide authentication for your UWP apps. The sample used in this video is available on GitHub.
Windows 10 for Business: Publishing apps to the Windows Store for Business – A major goal for Version 1511 is to provide essential Windows 10 features for enterprises. Windows 10 machines can now be set up using workplace or education identities backed by Azure Active Directory. Accompanying that, the new Windows Store for Business provides great facilities for enterprises to manage and distribute apps for their employees, and allows app developers to distribute their apps to business and education customers. Shen Chauhan returns in this video to walk through how it works.
Don’t forget, these videos supplement the existing Developers’ Guide to Windows 10 series, where you can find in-depth videos on everything you need to know to build great UWP apps for Windows 10. We hope you enjoy the series and if there is something else you’d like us to cover, please comment!
Today we are happy to announce the reboot of Coding4Fun; a site within Windows Dev Center that’s dedicated to exploring the lighter side of Windows 10 development. Our goal is pretty simple; create fun and interesting code samples that feature the more interesting APIs available on the Universal Windows Platform. Why? Coding is fun and fun is good. Fun can also be educational and by showing you some neat, unique, and sometimes time-saving capabilities, you’ll not only have something cool to show for your time investment, you’ll also walk away having learned something new.
Even though the focus of Coding4Fun has changed a bit over the years, our passion for development remains relentless. We are still as dedicated to delivering top quality, project-based content that includes complete, well-commented source code, provided under the MIT open-source license, and documentation on how to build the sample. But don’t feel obligated to build it yourself, just run the sample to take a look under the hood if you prefer.
Of course, not every project is going to appeal to every developer so a variety of project types, ranging in complexity, will be made available. Currently, we’ve got three projects posted but there are more in the pipeline.
Here are the available projects that you can explore right now:
FaceTheremin lets you create original music by moving your face (or multiple faces) to different positions in a camera’s view. The app uses face detection on a live video stream to trigger musical events by using new media API’s. FaceTheremin features the following APIs:
FaceTracker – Detects faces in VideoFrame objects and tracks faces across subsequent video frames.
MediaCapture class – Provides functionality for capturing photos, audio, and videos from a capture device, such as a webcam.
See it in action:
MusicServer is a music streaming app designed to simultaneously play a single track on many Windows 10 machines. It contains code to run on both a publisher, which sends out the music, and a subscriber, which uses a virtual speaker to play it. MusicServer features the following APIs:
Windows.Networking.Connectivity namespace – Retrieves connection profiles that provide connectivity, usage, and data plan information for established network connections. This data can be used by a connected application to take appropriate action when operating in challenging network scenarios or abiding by data plan limits set by a network provider.
Windows.Networking.Sockets namespace – Provides sockets and WebSockets classes to use for network communications and classes for real-time network notifications received in the background for Windows Store apps.
MediaPlayer class – Provides access to media playback functionality such as play, pause, fast-forward, rewind, and volume.
CardReader lets you create new contacts by capturing Media Elements from a live camera. It extracts text using OCR and integrates it into the People app. CardReader features the following APIs:
OcrEngine class – Provides optical character recognition (OCR) functionality.
DeviceInformation class – Allows access to well-known device properties as well as additional properties specified during device enumeration.
ContactManager class – Represents a service that source apps can call to access contact data.
Make sure to follow us on Twitter to receive updates on new content and updates on Building Apps for larger updates.
It’s the end of the year and the holiday season in many parts of the world, so we have one more release this year to celebrate all the App Studio enhancements in 2015, such as the launch of Windows 10 and the November Update. Today’s Windows App Studio Beta update brings some exciting new features that we can’t wait for you to use. There are a couple of big new features, some significant design related improvements, and fun and useful new templates.
The new features in this release focus on things that help empower small businesses, professionals, and organizations to create great apps for Windows and better connect with their customers.
WordPress Data Source – We introduced a new WordPress data source that lets you connect your app to your WordPress blog. It pulls in content and displays it beautifully in your app so you can free your blog from the web and get it in front of 110+ million Windows 10 users by publishing it to the Store.
Related Content – Did you ever want to show related content in a section (such as speaker information for an event listing in a Convention app, or comments from a blog post)? Now it can be easily done in Windows App Studio Beta. This feature opens up new use cases and we will show them off in new templates in the future.
Microsoft Advertising – It’s great to have people using and enjoying your app, but it’s even better when those eyeballs translate into revenue! Now included is the Microsoft Ad control, which means you can now place advertising in your app to make money from people using it.
Recognizing that great design is core to quality user experience, we also put time into building features that customize of the look and feel of the apps created in Windows App Studio. These features let you set the look and feel you want for each section of your app, taking advantage of media-rich designs. :
New Carousel Control – Sometimes you want to showcase a selection of images in your app. The Carousel lets you display a number of hero images in a single section that behave like a slideshow. Image may be NSFW. Clik here to view.
Improved Section Design Features – We added a few more features to help make your apps look great. Now you can change the background and adjust the hero image for each section individually and choose how each section appears on the default/home section of your app.
What’s the best way to get started with these features? With the new templates we’re releasing! These templates show off the new features and make it easy for you to become familiar with and use them.
WordPress Template – Showcases the new WordPress data source and is an excellent way for you to break out of the web and bring your WordPress blog to the Windows platform and Store Image may be NSFW. Clik here to view.
Events – This template uses the new Related Content feature to help you build an informative app for all of your event attendees. Image may be NSFW. Clik here to view.
My Shop – Leverage our new design features in this template and show off your catalog of products. This template also adapts nicely to portfolio situations for photographers, artists, designers, and anyone who creates or sells content. Image may be NSFW. Clik here to view.
We would love to hear your feedback on these new features and see the great ways you take advantage of them for the apps you build. As always, you can find us on the forums and User Voice. Also, if you have a great story to tell about your experience using App Studio, please tell us. Have a great rest of 2015 and we look forward to an exciting 2016.
Earlier this month we announced the release of one of the most requested features in Dev Center: support for multiple users in a single Dev Center account with the ability to manage access through roles. With multi-user there is much greater account management flexibility. For example, you can now though delegate engineering work to one individual or company while at the and provide access to financial information to a different individual or company.
In this blog, I’ll walk you through some common scenarios that you might encounter with this new feature.
The multi-user access is managed through Azure Active Directory (AAD), and an Azure AD user account with admin permissions for your organization is required. You can visit the MSDN documentation for information on how to enable multi-users on your account, and you can also check out the Multi-user Support in Dev Center video on Channel 9.
Setting up the Azure Active Directory
The first step in setting up multi-users is to set up Azure Active Directory. We recommend you carefully consider your business goals before deciding on the Azure AD plan that works best for you and your apps. There are three different scenarios to consider:
Your company currently has an Azure AD, and you can easily identify the admin for your Azure AD.
You’re ready to go. Follow the instructions to link your Azure AD to your Dev Center account.
Your company may have an Azure AD, but you cannot easily identify the admin for your Azure AD.
We recommend you research this internally to identify your Azure AD admin, as unlinking an incorrect Azure AD requires opening a support ticket, can take several days, and can disrupt the use of the users that are accessing Dev Center. If your company does have an Azure AD but is unable to link someone with admin permissions to Dev Center, we recommend that you do not link your Azure AD to your Dev Center account at this time.
Your company does not have an Azure AD.
You’ll need to set up an Azure AD and have several options:
Free Azure AD account: This option is best if you only plan to use Azure AD for multi-user roles, and have no plans to use it in any other capacity.
Pay-as-you-go Azure AD account: This option is best if your organization may use Azure AD in a limited capacity for Dev Center only. Consider this option if your Dev Center “owner” may change at some point, or if you would like to use Azure AD for other Dev Center features like Windows Store Purchase API.
Azure AD subscription: Azure AD offers identity and access management for all your cloud-based needs at affordable pricing. Consider this option if your organization uses cloud-based features on a regular basis.
Adding an external user or group to Dev Center
One of the most common scenarios in app development is when a company contracts another developer or company to create or contribute to an app. In this case, you may want to add a user or group to your Dev Center account, though they may not have an account in your Azure AD. The “Add a new user” or “Add a new group” options will allow you to add a user or group to your Dev Center account. This user or group’s permissions can later be added or removed from Dev Center, though it’s important to note that adding a user/group to Dev Center will also create a user/group in your Azure AD that can only be fully managed within Azure.
To add a single user:
From the “Manage users” option in “Account Settings”, select “Add user”. From the “Add user” screen, select the “New user” button at the top. Image may be NSFW. Clik here to view.
Complete the required fields. Note that the user name will be an email address under your company’s email domain. Select the appropriate role, and click “Save”. Image may be NSFW. Clik here to view.
Dev Center will confirm the user has been added, and that an account has been created for the user. The user name and a temporary password will be provided. The user will be prompted to change their password the first time they log into Dev Center. Image may be NSFW. Clik here to view.
To add a group of users:
From the “Manage users” option in “Account Settings”, select “Add group”. From the “Add group” screen, select the “New group” button at the top. Image may be NSFW. Clik here to view.
Dev Center will confirm the users have been added to your account. You can manage the group via the “Editing a user” option. Image may be NSFW. Clik here to view.
Note: At this time, Visual Studio does not support Azure AD logins, which means that to package an app for Store submission, the “Developer” role must log in to Visual Studio with the primary Dev Center account credentials, rather than their Azure AD credentials. If this is an important scenario for your organization and you would like to see it supported, please vote for it in UserVoice.
Removing a user from Dev Center
There are two cases when you might want to remove a user from Dev Center: 1) the user has left your company or was a temporary employee/contractor that no longer works for you, or 2) the user has swapped roles within your company. It’s easy to remove or change the user’s role on your Dev Center account.
Check the new access level you would like to assign to the user, and click “Save”. The user’s access will be updated next time they log in to Dev Center. Image may be NSFW. Clik here to view.
Dev Center removes the user instantly, without a confirmation screen. Note that this does not remove the user from your organization’s Azure AD. Also note that you can add the user back in the future.
Enabling a third party developer to submit apps in Dev Center
Third party developers sometimes submit apps on behalf of an app publisher, and the “Developer” role allows the user to submit app packages. However, Visual Studio does not currently support Azure AD logins, so a developer will not be able to upload the package from Visual Studio if they don’t have access to the primary Dev Center account credentials. We are aware of this limitation, and are actively working to implement a solution for this scenario in 2016. If you think this is an important scenario to support sooner, please vote for it in user voice.
A workaround is available for Windows 8.x and Windows Phone 8.x apps, you can read more about it here.
Feedback
Our team is excited to bring you this much anticipated feature, and we look forward to introducing more functionality in future updates. As you explore and use these new capabilities, please send us feedback via the Windows Feedback tool, the “Feedback” button in Dev Center Image may be NSFW. Clik here to view. found in the bottom right.
As we welcome 2016, I thought it only fitting to provide an update on our progress since the Windows 10 launch on July 29.
As announced yesterday, over 200 million PCs, tablets and phones across the globe are now running Windows 10, the fastest growth trajectory of any version of Windows, outpacing Windows 7 by nearly 140% and Windows 8 by nearly 400%. And, accounting for 67% of all Store downloads across PC and tablet in December.
These new Windows 10 customers are discovering and engaging with the Store at a higher rate than ever before with over 3 Billion Store visits since the Windows 10 launch. While it’s early yet, the promise of Windows 10 is beginning to pay off. Over the holiday selling season, we saw a 2x increase in the number of paid transactions from PC and tablet customers over last year. Looking at the month of December, 60% of those paying customers were new to the Store, with Windows 10 generating 4.5x more revenue per device, as compared to Windows 8.
Both the growth of Windows 10 customer base and the increase in customer engagement (both with the Store and with the apps themselves) will enable us to deliver on our promise of providing a platform where developers can find growing success. For some of you, that means finding new success on the PC, and for others, Windows 10 represents an opportunity to bring your existing code to 200 million, and growing, devices. Recently, NPR and several other partners shared some highlights of their Windows 10 results:
“Seventy percent of NPR listeners use Windows devices, and we’ve seen a 50-percent increase in their listening time just since Windows 10 came out. And that was before we upgraded our app.”
— Ben Schein, Product Manager at NPR
In addition, Box recently shared their positive experiences developing for the Universal Windows Platform, while providing an experience for their users, regardless of the version of Windows they might be using:
“By combining the two apps in Windows 10 as a universal Windows app, it decreased our engineering overhead, and increased our velocity for future iterations. We’re really excited about this.”
— Lois Wang, Senior Product Manager at Box
As we begin 2016, our focus remains unchanged. We will continue to drive Windows 10 adoption and make investments in these 5 areas to help developers be successful:
Expanded payment options. To enable a broad range of customers to purchase your apps, we are expanding carrier billing to Windows 10 PCs and tablets, in addition to phones. This investment is especially important, as roughly 88% of the world’s population does not have a credit card (Source: World Bank, 2014). Customers need only enter their mobile phone number to purchase via any Windows 10 device. This capability was released for the Windows 10 platform in mid-November and is now live with O2 in Germany, Swisscom in Switzerland and Sprint in the US, with a robust pipeline of new connections planned in 2016. While these connections have just come online, early results show a 40% increase in operator billed sales. Carrier billing rounds out a range of payment options beyond credit cards: Alipay, PayPal, traditional gift cards, digital gifting and Bitcoin (US only).
Enhanced monetization. We also continue to simplify and expand monetization models available to developers. With Windows 10, ad mediation is now available across PC, tablet and phone, enabling those of you who monetize with advertising to maximize your fill rate and grow revenue. In November, we announced a partnership with Vungle to offer in-app video ads. Over the coming months we will also begin testing new subscription capabilities announced at Build 2015, piloting the capability with a few partners and expanding availability based on the feedback we receive. We now also offer capabilities to enable you to more easily track and optimize your monetization strategy.
Increased app discoverability. We’ve taken a number of actions to help users discover high quality apps, including the new Windows Store UI, algorithms and in-product app promotion, as well as the addition of a new Deals Hub app and Collection in the Store. We’ve also begun investing in a regular cadence of cross-Store sales and promotions to drive traffic, including the recent 10 days of 10-cent deals over the Black Friday holiday and Countdown to 2016, both of which contributed to this year’s strong holiday results. You can expect a full line-up of promotions and marketing activities in 2016. And, with the new Windows Store Affiliate Program, you can run your own promotions and earn additional revenue. Image may be NSFW. Clik here to view.
For those of you with apps tailored toward organizational users, Windows 10 is also seeing rapid adoption with organizations, and the new Windows Store for Business provides an excellent way to reach them. Over 76% of Microsoft’s global enterprise customers are now in active pilots of Windows 10, with more than 22 million devices running Windows 10 across enterprise and education organizations. The new Windows Store for Business, launched in mid-November and offering free content in select markets, is in pilot with several thousand enterprise, education and small business organizations today. By the spring, this new storefront will be available in over 30 markets for distribution of free apps with paid app support coming later this calendar year.
Existing code welcome. Whether you’re an experienced Windows app developer or just getting started, we want to make it easy to bring your app or game to the Store. To that end, we’re building a number of Windows Bridges to more quickly expand your reach to the Universal Windows Platform. Two toolkits shipped in 2015, and more are coming in 2016.
For web developers, you can quickly package your existing web site into Windows 10 hosted web apps. Once packaged, your server-based code can use the Store for discovery and distribution, and you can extend your code to use Windows device capabilities, notifications and monetization. I highly suggest taking 5 minutes in Windows App Studio to try your adaptive design website as a Windows app to see how easy it really is.
Windows Phone Silverlight developers were delighted to see the release of Mobilize.NET’s Silverlight bridge in late 2015. This bridge is an API mapping tool that eases migration of existing Windows Phone 8 projects to the Universal Windows Platform, enabling distribution to all devices running Windows 10.
We open-sourced the Windows Bridge for iOS to GitHub under an MIT license, making it possible to use Objective-C to build native UWP apps, as well as making it easier to reuse your iOS code on Windows 10. Since release, the team has been providing regular updates, with ARM support targeted for preview later this month.
Lastly, we continue to work with numerous partners to ensure that Windows 10 is a deployment option for those using cross-platform tools and game engines such as Unity and Marmalade.
And finally – get more done in fewer steps. We’ve made a good deal of progress to minimize the app submission and management flows since Build 2015 starting with the convergence of the Windows Phone and Windows Dev Centers in addition to adding pubCenter for Microsoft Advertising. We’ve enhanced reporting and app promotion capabilities, and added sale pricing and most recently added support for multiple users within a single Dev Center account with roles – the number one request from all of you. Later this week we will begin the next phase in the rollout of the new single age rating workflow, based on the global rating and age classification system, IARC.
While we have much more work to do, we’ve delivered a number of new capabilities and tools since Build 2015 and the Windows 10 launch. We hope you’ll take the plunge in 2016 and update your existing apps to Windows 10 and bring that idea for a new app to the Windows platform. Happy New Year!
To aid customers in determining which apps or game are appropriate to download, Dev Center requires you to select an age rating during the submission process and include specific requirements (e.g. ESRB or PEGI) for every market you’re planning to publish in. The workflow to assign age ratings in Dev Center often required several hours of work to obtain and include all the market-specific certificates, as each was handled separately, one by one.
On January 6, Dev Center will begin the rollout of a single and more efficient workflow, which uses the International Age Rating Coalition’s (IARC) age rating system. The system will be rolled out in phases throughout January. In this blog I will discuss what this means for your app and for your Store listings.
New single workflow: IARC for all regional and international age ratings
The IARC rating system is a global rating and age classification system for digitally-delivered games and apps. With IARC, you complete a single questionnaire about the content in your app during submission and Dev Center automatically adds regional and international age rating certificates to the Store listing for you. If you change your app’s content, you can update the questionnaire and receive a new rating at any time.
IARC makes it quick and simple to obtain age and content ratings across the globe, making it easier to offer your apps in more countries and markets. There is no cost to you, and the questionnaire can be competed in just a few minutes. The ratings are then automatically generated for:
Classification Board (ACB) in Australia
Classificação Indicativa (ClassInd) in Brazil
Entertainment Software Rating Board (ESRB) in North America
Pan European Game Information (PEGI) in Europe
Unterhaltungssoftware Selbstkontrolle (USK) in Germany
International Age Rating Coalition (IARC) for general purpose
Based on the IARC ratings, Microsoft will then issue three additional rating values: Windows Store rating, a Game Software Rating Regulation (CSRR) for Taiwan, and a Russian Age Rating System (PCBP).
In addition to the automatically generated market-specific age ratings, Dev Center offers the option to add a South Korea age rating. South Korea does not participate in IARC, so if you plan to offer a game in that market, you’ll need to add this rating.
All Windows Store apps and games need to obtain a rating through the IARC rating system
The IARC rating system will be enabled in some accounts starting today, and rolled out to all accounts over the next few weeks. Once your account is enabled with the new workflow:
You will need to complete the IARC rating questionnaire as part of new app
You will need to complete the IARC rating questionnaire the first time your current apps have any sort of update (price change, new screenshot, new package, etc.).
Note: Subsequent updates do not require you to complete the questionnaire again, unless new content or functionality in your app would make your previous answer to any question on the IARC questionnaire inaccurate.
The process is the same for both new apps and app updates. During app submission, in the “App Properties” step, select an App Type (note that this may not match your app’s Store category):
Based on your app’s Type, the IARC rating system will ask a series of multiple choice questions. If you answer yes, it may ask additional questions about the applicable content:
After you answer all relevant questions, click the “Generate age ratings” button at the bottom. You’ll receive regional age ratings from participating rating boards, along with a generic IARC or Windows Store rating for markets without a participating rating authority. Once you’ve completed the questionnaire and submitted the new or updated app to the Store, the age ratings are automatically applied to your app’s listing.
Windows 10 customers will see the age rating specific to their market, along with the rating icon for the applicable rating authority. Customers in markets without a participating age rating authority will see IARC’s generic age rating icon.
Windows 8.x and Windows Phone 8.x customers will also see the age rating specific to their market, along with the rating icon for the applicable rating authority.
Customers in markets without a participating age rating authority will see the generic Windows Store age rating.
After your app is published to the Windows Store, you will receive an email from IARC with your official certificate ID and rating from each participating rating authority, as well as any additional pertinent information. This email is for your records, you do not need to do anything with it in Dev Center.
South Korea
If you plan to offer your game in South Korea, you’ll need to obtain a separate rating from the South Korea Game Rating Board (GRB), as the GRB is not included in the IARC age rating system at this time. Apps offered in South Korea will use the generic IARC rating.
To obtain this rating for your game, follow the process described on the GRB website.
Once you complete the IARC questionnaire and are issued the age ratings, you will be able to upload the app’s GRB certificate. Select the desired age rating from the pulldown menu, select the descriptors for your rating (e.g. bad language, fear, etc.) and provide your certificate.
The Dev Center team is excited to introduce this single workflow solution for your Windows Store apps and games. Publishing your apps in all available markets with the appropriate age ratings for each one may increase your downloads. If your app is not available worldwide, consider expanding your app’s availability using this new process.
After you complete the questionnaire for your app, don’t forget to check that all desired markets are selected in your app’s availability prior to publishing.
Try out IARC and please send us feedback through the “Feedback” button in Dev Center (Image may be NSFW. Clik here to view. found in the bottom right).
Background audio in a Universal Windows Platform (UWP) app is a powerful way to provide a more seamless audio experience to your users. This post will walk you through setting up background audio, reacting to device media controls, communicating with the background media player, and managing playlists.
Before we get started, you need to know that background playback consists of two processes:
the foreground app (the app UI and client logic)
the background playback task (the audio playback logic and background services)
In the sample app we’re developing, the user selects and controls the audio, which is then played in the background. By definition, background audio continues playing even when the app is no longer in the foreground.
The background task communicates with Windows through the System Media Transport Controls (SMTC), which lets your app use the media controls and update metadata for the display. It also listens for foreground app events broadcast by the BackgroundMediaPlayer.
Note: You’ll likely want to install Update 1 for Visual Studio 2015 before working your way through this code. It contains the latest Windows Phone emulators.
Setting up the Background Audio
The background playback task is implemented through IBackgroundTask, like any other UWP background task, except in this case, we add logic for audio services. Here, we take a look at how that’s done.
Setting up the Background Task
The IBackgroundTask interface gives us an entry point for running code in the background. It provides one method, IBackgroundTask.Run, that is called by Windows to perform the task’s work. We use the Run method to set up the objects we need to manage the media playback.
The IBackgroundTask.Run method is invoked the first time that one of the following occurs:
the Current is accessed from the foreground app
a handler is registered for the MessageReceivedFromBackground event
Here’s a quick visual to show how this all fits together:
We’ll take a close look at the background audio task by walking through the code in the sample on GitHub.
External References
The first block of code is a standard set of ‘using’ directives to import our namespaces and Windows types. Note the Background Audio resources listed in the last block. The BackgroundAudioShared namespace provides utilities for formatting data and persisting the app state. The BackgroundAudioShared.Messages namespace provides helper classes for decoding messages from the foreground app.
using System;
using System.Diagnostics;
using System.Threading;
using System.Linq;
using Windows.ApplicationModel.Background;
using Windows.Media;
using Windows.Media.Playback;
using Windows.Foundation.Collections;
using Windows.Storage;
using Windows.Media.Core;
using System.Collections.Generic;
using BackgroundAudioShared;
using Windows.Foundation;
using BackgroundAudioShared.Messages;
using Windows.Storage.Streams;
The Background Task
We implement the IBackgroundTask interface in the BackgroundAudioTask class. This class needs to refer to the media controls, the playback list, application state, and events. We declare the necessary member variables for this in this top section of the class definition. These will get initialized during the Run method callback. We will discuss how each of these are used in more detail in later sections of this article.
We also set up a couple of helper methods to get the track IDs from playback items. The first gets the track ID of the current item on the playback list. It calls the second helper that gets the track ID from any playback item.
#region Helper methods
Uri GetCurrentTrackId()
{
if (playbackList == null)
return null;
return GetTrackId(playbackList.CurrentItem);
}
Uri GetTrackId(MediaPlaybackItem item)
{
if (item == null)
return null; // no track playing
return item.Source.CustomProperties[TrackIdKey] as Uri;
}
#endregion
The App Manifest
Before we get to the app manifest, the background audio task should be set up as a Windows runtime project. Currently it must be in a separate project in the solution because the task is compiled into a DLL that is loaded into a special system background task host process. When you run the app, this process will show in Task Manager as Windows.Media.BackgroundPlayback.exe.
We need to set up a few things in the App Manifest after creating the background audio task. MyBackgroundAudioTask needs to be you registered in the Package.appxmanifest to handle audio events. In the declarations section, you need to specify the following:
Declarations section
Entries
Supported declarations
Background Tasks
Supported task types (properties)
Audio
Entry point
BackgroundAudioTask.MyBackgroundAudioTask
The Run Method
The Run method is the heart of the BackgroundAudioTask class. This method will be called by Windows the first time the Media Player is accessed from the foreground. This is where we connect up to the media player by setting properties and adding event handlers.
We set up the Run method below.
#region IBackgroundTask and IBackgroundTaskInstance Interface Members and handlers
/// <summary>
/// The Run method is the entry point of a background task.
/// </summary>
/// <param name="taskInstance"></param>
public void Run(IBackgroundTaskInstance taskInstance)
{
Debug.WriteLine("Background Audio Task " + taskInstance.Task.Name + " starting...");
In this step we subscribe to key events and set up properties to enable the app to show in the UVC and to respond to system media transport control commands, for example, when you press the volume button on your device.
// Initialize SystemMediaTransportControls (SMTC) for integration with
// the Universal Volume Control (UVC).
//
// The UI for the UVC must update even when the foreground process has been terminated
// and therefore the SMTC is configured and updated from the background task.
smtc = BackgroundMediaPlayer.Current.SystemMediaTransportControls;
smtc.ButtonPressed += smtc_ButtonPressed;
smtc.PropertyChanged += smtc_PropertyChanged;
smtc.IsEnabled = true;
smtc.IsPauseEnabled = true;
smtc.IsPlayEnabled = true;
smtc.IsNextEnabled = true;
smtc.IsPreviousEnabled = true;
Read the persisted state of the foreground app, so that later we will be able to evaluate whether we can send updates to the active foreground application.
var value = ApplicationSettingsHelper.ReadResetSettingsValue(ApplicationSettingsConstants.AppState);
if (value == null)
foregroundAppState = AppState.Unknown;
else
foregroundAppState = EnumHelper.Parse<AppState>(value.ToString());
Add handlers for MediaPlayer to sync the cached playback status on SMTC—playing, paused, or closed—with CurrentMediaPlayer.
Note: We recommend that you register for the message received handler before calling BackgroundMediaPlayer.Current for the first time so that the foreground app doesn’t miss any messages sent from the background process.
In the code below, we send a message to the foreground app, if it is active, that the background task has started. This way the foreground app is aware that it can now send further commands, for example, to begin playback.
if (foregroundAppState != AppState.Suspended)
MessageService.SendMessageToForeground(new BackgroundAudioTaskStartedMessage());
ApplicationSettingsHelper.SaveSettingsValue(ApplicationSettingsConstants.BackgroundTaskState, BackgroundTaskState.Running.ToString());
To keep the background task alive after the Run method completes, we need to ask IBackgroundTaskInstance for a deferral. We need to do this before subscribing to the events below because they use it.
deferral = taskInstance.GetDeferral();
We then mark the background task as started to unblock the SMTC play operation (see related WaitOne on this signal).
backgroundTaskStarted.Set();
The app goes through lifecycle states that need to be handled. Here we add handlers for cancellation and completed states. This state must be declared at the end of the Run method because the event may raise immediately before thread execution continues.
taskInstance.Task.Completed += TaskCompleted;
taskInstance.Canceled += new BackgroundTaskCanceledEventHandler(OnCanceled); // event may raise immediately before continuing thread excecution so must be at the end
}
Task Completed Callback
Because we took a deferral from the task instance during the Run method, we must call Complete on the deferral whenever the task completes. This is the callback method that we registered with the task to handle the Completed notification.
The task can be canceled when another media app comes into the foreground and starts playing music, or it can be canceled due to lack of resources if your task consumes more CPU or memory than allowed. If this happens, we save state so that the app can resume gracefully.
Here, we add some handling for the background task being canceled. This handling gives the app time to save state before it closes and resources are reclaimed by the system.
The audio app should respond to the media controls on the device, such as volume control, pause, stop, back, and skip. This is accomplished through the system media transport controls, which are configured and updated from the background task, not the foreground app.
To set this up, we initialize SystemMediaTransportControls for integration with the Universal Volume Control (UVC). We create a function to update the UVC with playback status and information about the current audio.
#region SysteMediaTransportControls related functions and handlers
private void UpdateUVCOnNewTrack(MediaPlaybackItem item)
{
if (item == null)
{
smtc.PlaybackStatus = MediaPlaybackStatus.Stopped;
smtc.DisplayUpdater.MusicProperties.Title = string.Empty;
smtc.DisplayUpdater.Update();
return;
}
smtc.PlaybackStatus = MediaPlaybackStatus.Playing;
smtc.DisplayUpdater.Type = MediaPlaybackType.Music;
smtc.DisplayUpdater.MusicProperties.Title = item.Source.CustomProperties[TitleKey] as string;
This code block handles local album art for the display. (Remote URIs are not covered in this sample app.)
var albumArtUri = item.Source.CustomProperties[AlbumArtKey] as Uri;
if (albumArtUri != null)
smtc.DisplayUpdater.Thumbnail = RandomAccessStreamReference.CreateFromUri(albumArtUri);
else
smtc.DisplayUpdater.Thumbnail = null;
smtc.DisplayUpdater.Update();
}
We could optionally add some code to cover what happens if an SMTC property is changed—for example if the sound is muted.
void smtc_PropertyChanged(SystemMediaTransportControls sender, SystemMediaTransportControlsPropertyChangedEventArgs args)
{
// Put custom code here
// For example, you could add code to pause the music if the volume is muted
}
At the very least we need handling for each UVC button: play, pause, next, and previous. The following switch statement is a simple dispatcher that forwards these button presses to one of our class methods that will react to it. Note that if this is not run in the background process, we won’t be able to handle button events when the app is suspended.
Note that the play button presents a special problem. Pressing play could be the event that causes this background process to start running again after being suspended. We’ll wait for the backgroundTaskStarted event to be signaled during our Run method before proceeding so that we know that everything is initialized properly.
case SystemMediaTransportControlsButton.Play:
Debug.WriteLine("UVC play button pressed");
When the background task has been suspended and the SMTC starts it again asynchronously, time is needed to allow the task startup process in the Run method to complete. The WaitOne method lets the app wait for the task to start. Once it starts, this signal continues until shutdown so that it won’t wait again unless it needs to do so.
bool result = backgroundTaskStarted.WaitOne(5000);
if (!result)
throw new Exception("Background Task didn't initialize in time");
StartPlayback();
break;
case SystemMediaTransportControlsButton.Next:
Debug.WriteLine("UVC next button pressed");
SkipToNext();
break;
case SystemMediaTransportControlsButton.Previous:
Debug.WriteLine("UVC previous button pressed");
SkipToPrevious();
break;
}
}
#endregion
Managing playlists
We definitely want our user to be able to play a playlist and navigate through it. We’d also like for playback to resume where the user last stopped when the foreground app closed.
A playlist in the desktop version of the sample app.
We set up some playlist management functions and handlers in the following code blocks. In the following code, we try to resume playback from the previously saved track and position.
#region Playlist management functions and handlers
/// <summary>
/// Start playlist and change UVC state
/// </summary>
private void StartPlayback()
{
try
{
// If playback was already started once we can just resume playing.
if (!playbackStartedPreviously)
{
playbackStartedPreviously = true;
// If the task was cancelled we would have saved the current track and its position. We will try playback from there.
var currentTrackId = ApplicationSettingsHelper.ReadResetSettingsValue(ApplicationSettingsConstants.TrackId);
var currentTrackPosition = ApplicationSettingsHelper.ReadResetSettingsValue(ApplicationSettingsConstants.Position);
And if we have the current track ID, we find the index of the item by name.
if (currentTrackId != null)
{
// Find the index of the item by name
var index = playbackList.Items.ToList().FindIndex(item =>
GetTrackId(item).ToString() == (string)currentTrackId);
if (currentTrackPosition == null)
If there is no saved position for how far into the track to begin, we play it from the beginning.
{
// Play from start if we dont have position
Debug.WriteLine("StartPlayback: Switching to track " + index);
playbackList.MoveTo((uint)index);
// Begin playing
BackgroundMediaPlayer.Current.Play();
}
Otherwise, we play it from the saved position in the track.
else
{
// Play from exact position otherwise
TypedEventHandler<MediaPlaybackList, CurrentMediaPlaybackItemChangedEventArgs> handler = null;
handler = (MediaPlaybackList list, CurrentMediaPlaybackItemChangedEventArgs args) =>
{
if (args.NewItem == playbackList.Items[index])
{
This only needs to run once for this item, so we unsubscribe.
playbackList.CurrentItemChanged -= handler
Then we set the position to start and begin playback.
var position = TimeSpan.Parse((string)currentTrackPosition);
Debug.WriteLine("StartPlayback: Setting Position " + position);
BackgroundMediaPlayer.Current.Position = position;
// Begin playing
BackgroundMediaPlayer.Current.Play();
}
};
If the user switches the track, we want to trigger an item changed event.
playbackList.CurrentItemChanged += handler;
// Switch to the track which will trigger an item changed event
Debug.WriteLine("StartPlayback: Switching to track " + index);
playbackList.MoveTo((uint)index);
}
}
In case the currentTrackId is null (see ‘currentTrackId != null’ above), we just begin playback without setting a track or position.
else
{
// Begin playing
BackgroundMediaPlayer.Current.Play();
}
}
Another else handles playback in the event no playback was previously started (see ‘if (!playbackStartedPreviously’ above).
else
{
// Begin playing
BackgroundMediaPlayer.Current.Play();
}
}
catch (Exception ex)
{
Debug.WriteLine(ex.ToString());
}
}
Next we add some functions to handle navigation through the playlist. We start by getting the new item, then we update the system view (the display), and get the current track.
void PlaybackList_CurrentItemChanged(MediaPlaybackList sender, CurrentMediaPlaybackItemChangedEventArgs args)
{
// Get the new item
var item = args.NewItem;
Debug.WriteLine("PlaybackList_CurrentItemChanged: " + (item == null ? "null" : GetTrackId(item).ToString()));
// Update the system view
UpdateUVCOnNewTrack(item);
// Get the current track
Uri currentTrackId = null;
if (item != null)
currentTrackId = item.Source.CustomProperties[TrackIdKey] as Uri;
We also need to notify the foreground app of the change or persist it for later, as shown in the following block.
private void SkipToNext()
{
smtc.PlaybackStatus = MediaPlaybackStatus.Changing;
playbackList.MoveNext();
// TODO: Work around playlist bug that doesn't continue playing after a switch; remove later
BackgroundMediaPlayer.Current.Play();
}
#endregion
We will likely want the user to be able to create new playlists, so we add code to handle that. The foreground app creates the playback list by sending it to the background task. Note that this sample does not include a playlist UI.
#region Background Media Player Handlers
void CreatePlaybackList(IEnumerable<SongModel> songs)
{
We begin by making a new list and enabling looping.
playbackList = new MediaPlaybackList();
playbackList.AutoRepeatEnabled = true;
Then we add playback items to the list.
foreach (var song in songs)
{
var source = MediaSource.CreateFromUri(song.MediaUri);
source.CustomProperties[TrackIdKey] = song.MediaUri;
source.CustomProperties[TitleKey] = song.Title;
source.CustomProperties[AlbumArtKey] = song.AlbumArtUri;
playbackList.Items.Add(new MediaPlaybackItem(source));
}
We want to make sure the new playlist doesn’t automatically start. We assign the list to the media player and add a handler for future playlist item changes.
BackgroundMediaPlayer.Current.AutoPlay = false;
// Assign the list to the player
BackgroundMediaPlayer.Current.Source = playbackList;
// Add handler for future playlist item changes
playbackList.CurrentItemChanged += PlaybackList_CurrentItemChanged;
}
You should be aware that this example demonstrates only how the playlist works with the background media player: MediaPlaybackList is the type of list you would pass into a MediaPlayer. If you would like to explore more ways to work with playlists or creating a playlist UI, it’s worth taking a look at the playlists sample on GitHub and the adaptive streaming sample for streaming audio. The playlists sample shows how you might load a list of songs from a serialized file, a different kind of list that we show here. When deserializing from file, you would still need to add each playback item to a MediaPlaybackList in a way similar to the foreach (var song in songs) statement above.
Communicating with the Background Audio Task
Finally, we create a set of message handlers for the background media player, so the foreground app can send it messages like “App suspending,” “Starting playback,” or “Update playlist.”
The next code block for message handling addresses the app suspending. At this point, the app can save the task state.
if(MessageService.TryParseMessage(e.Data, out appSuspendedMessage))
{
Debug.WriteLine("App suspending"); // App is suspended, you can save your task state at this point
foregroundAppState = AppState.Suspended;
var currentTrackId = GetCurrentTrackId();
ApplicationSettingsHelper.SaveSettingsValue(ApplicationSettingsConstants.TrackId, currentTrackId == null ? null : currentTrackId.ToString());
return;
}
The following Windows Phone image depicts switching from the background audio sample app to play a song from the SD Card in another app. When this happens, the background audio sample suspends and records the track and position at which playback stopped, so it can start playback from the same place when the app is resumed. Be sure to check out the video near the top of this post to see this in action.
In the code below, we handle the messages for the app resuming. When the app is resumed, it subscribes to the message channel.
AppResumedMessage appResumedMessage;
if(MessageService.TryParseMessage(e.Data, out appResumedMessage))
{
Debug.WriteLine("App resuming"); // App is resumed, now subscribe to message channel
foregroundAppState = AppState.Active;
return;
}
The following code handles messages from the foreground app for starting playback and skipping tracks.
StartPlaybackMessage startPlaybackMessage;
if(MessageService.TryParseMessage(e.Data, out startPlaybackMessage))
{
//Foreground App process has signalled that it is ready for playback
Debug.WriteLine("Starting Playback");
StartPlayback();
return;
}
SkipNextMessage skipNextMessage;
if(MessageService.TryParseMessage(e.Data, out skipNextMessage))
{
// User has chosen to skip track from app context.
Debug.WriteLine("Skipping to next");
SkipToNext();
return;
}
SkipPreviousMessage skipPreviousMessage;
if(MessageService.TryParseMessage(e.Data, out skipPreviousMessage))
{
// User has chosen to skip track from app context.
Debug.WriteLine("Skipping to previous");
SkipToPrevious();
return;
}
The remaining code in the message handling routine covers changed tracks and updated playlists.
TrackChangedMessage trackChangedMessage;
if(MessageService.TryParseMessage(e.Data, out trackChangedMessage))
{
var index = playbackList.Items.ToList().FindIndex(i => (Uri)i.Source.CustomProperties[TrackIdKey] == trackChangedMessage.TrackId);
Debug.WriteLine("Skipping to track " + index);
smtc.PlaybackStatus = MediaPlaybackStatus.Changing;
playbackList.MoveTo((uint)index);
return;
}
UpdatePlaylistMessage updatePlaylistMessage;
if(MessageService.TryParseMessage(e.Data, out updatePlaylistMessage))
{
CreatePlaybackList(updatePlaylistMessage.Songs);
return;
}
}
We’ll also need to handle sending the SMTC information on whether the media player is playing, paused, or closed.
void Current_CurrentStateChanged(MediaPlayer sender, object args)
{
if (sender.CurrentState == MediaPlayerState.Playing)
{
smtc.PlaybackStatus = MediaPlaybackStatus.Playing;
}
else if (sender.CurrentState == MediaPlayerState.Paused)
{
smtc.PlaybackStatus = MediaPlaybackStatus.Paused;
}
else if (sender.CurrentState == MediaPlayerState.Closed)
{
smtc.PlaybackStatus = MediaPlaybackStatus.Closed;
}
}
#endregion
} //Final curly brace for MyBackgroundAudioTask
} //Final curly brace for BackgroundAudioTask
Wrapping Up
Now that you understand how to utilize background audio, you might like to check out the background audio UWP sample on GitHub. It contains both foreground app and background task sample code, and you can use it as a starting point for your own app. You may also be interested in NPR One’s story about implementing background audio.
We are often asked what criteria the Windows Store uses to determine which apps to feature, as well as what developers can do to make their app more visible in the Store. Below I describe six recommendations that can increase your app’s ranking in search results, and also increase the possibility that your app is featured.
We are aware of several bugs impacting the Store that result in some apps not showing up in the Store search; we are working quickly to resolve these issues. If you follow the recommendations in this blog post, and your apps still can’t be found in the Store search, please let us know. The last section of this post describes the steps and information needed to make sure we can identify the root cause of the issues.
#1: Create an original app. Make sure you own the name, brand, icon and content
Customers sometimes look for specific apps or games in the Store. Your app name, title, icon and metadata should only use content that you own or have permission to use. If customers are confused because your app inaccurately uses content that you do not own, the owner could report you for IP infringement and your app and Dev Center account could be removed.
For example, don’t include the name of unrelated, popular apps in your app metadata, and don’t use an icon that might confuse customers into thinking your app is a different, popular app.
It is to your benefit to be original: The Store promotes and programmatically increases search visibility for apps that have original content and that bring unique value to Windows Store customers.
Recommendation: Your app icons, name, description and keywords should clearly communicate the functionality of the app, and must not confuse customers to think your app is a different one. Create a unique, attractive icon that represents the value of your app and attracts customers’ attention.
#2: Make sure your app stands out and has compelling capabilities
There are hundreds of thousands of apps in the Store. Today’s customers are looking for apps that offer distinct value and provide new options. When you build your app, make sure to offer features and experiences that set you apart from the crowd.
For example, if you submit a calculator app with only the generic capabilities already available in other calculators, your app will likely not be found when a customer searches because there are already other apps with unique or additional functions that are more appealing to customers.
Recommendation: Build apps that offer more or different value than apps that are already in the Store. The Store does not favorably rank new apps that provide similar functionality to apps already in the Store.
#3: Build one great app instead of several related apps
Offering one app with more value is usually better than offering multiple similar apps with limited capabilities or content.
For example, if you want to create an app that races cars in different countries, do not build a separate app for each country. Instead, combine all the content into a single app that has allows users to choose in which country to race. This solution offers a richer user experience, and gives you a better opportunity to be discovered in the Store. Another example is an app that is localized in 10 languages, and each language is a separate submission: combine all these apps into a single submission with an option for the customer to choose the language.
Recommendation: Do not submit multiple apps that can be replaced by a single app with more content. Building a richer app will also help it have more opportunities to be considered to be featured in the Store, since a single app that has more content will have wider appeal compared to one app with less content.
#4: Make a good first impression with metadata that’s compelling and accurate
Because the Store listing is often the first contact a customer has with your app, make sure your app description is accurate, clear and polished. For example, if you are building a guide to a game, it should be obvious to the customer that this is a “guide” and the app name and metadata in no way should confuse users into thinking that it is the actual game.
Name: Your app’s name tells customers about your app and its unique value, so make it relevant to your app, and make sure it’s not, for example, a collection of popular keywords that distract and confuse customers.
Description: This is how customers learn more about your app. Your description should be engaging, grammatically correct, accurate and informative. Make sure the description does not include names of other apps that are unrelated to your app’s functionality or could confuse customers. Do not mention apps or brands from other publishers in your description unless it is necessary to do so in order for customers to understand your app.
Screenshots: A picture is truly worth a thousand words, so choose your screenshots carefully. They should accurately represent what is special about your app. Use screenshots to tell a story about what your app does, and ensure they are a polished and distinct representation of your own app.
Keywords: Use terms that are relevant to your app and what it does. Use no more than seven keywords that are relevant to your app and represent its functionality, and make sure not to use keywords that are unrelated to your app. See the Policy 10.1 for more details.
Category; Make sure to choose the most accurate category for your app. Using the “guide to a game” example mentioned above, this type of app must not be published into the Games category, since it’s not an actual game. Books + reference is the more appropriate choice.
Recommendation: Invest in creating your app metadata to make it accurate and engaging. You never get a second chance to make a first impression! Remember that when the Store detects that an app has inaccurate or misleading metadata, we will reduce its visibility. For more tips on creating a great listing, see this blog post from our 10×10 series.
#5: Know and follow the Windows Store certification process and policies
Before an app is available to customers in the Store, it must pass the Store certification process. During certification, Dev Center tests the app for viruses and malware, as well as for technical and content compliance. The Store continuously evaluates apps, even after certification, and monitors comments from customers. If an app is found to be out of compliance at any point, the Store notifies the developer via email (using the account contact email), and the app may be removed from the Store.
Lastly, much like a credit score, your app history will influence the visibility of your current and future apps. Focus on submitting apps that are high quality and follow Windows Store Policies and customers will tend to like, download, and use your apps.
App submissions that will negatively impact your developer reputation include ‘copycat apps,’ apps that use intellectual property you don’t own and thus mislead customers, large numbers of similar apps, apps with misleading titles and/or keywords, apps that are found to violate Store policies, and apps that are removed due to policy violation. Submitting these apps has a lasting negative impact on the visibility of all the apps in your portfolio.
Recommendation: Submit high quality apps that follow these guidelines, and do not submit apps that violate Store policies, to keep your record clean and positively benefit the search rankings of all your apps.
If your app does not appear via direct link
Apps may take up to 24 hours to appear in the Store after they are submitted via Dev Center. If you have submitted an app and the direct link is not functioning after 24 hours, open a support ticket in Dev Center. Please include the following information: the App ID, the direct link, the search terms you tried, and confirmation that you have followed the above recommendations. This data is critical to aid in triage of your Store search issues.
What to do if you can’t find your app in the Store
If you have issues finding your app via Windows Store search, here are the steps to take:
Wait 24 hours after the app has been published. The deep link should work after 24 hours
If more than 24 hours have passed and the app does not appear when using the deep link, please open a support ticket. In the support ticket include the App ID, the deep link, and the date/time the app was published
If the app can be found through deep link but not through Store search, confirm you have followed the recommendations in this blog and confirm that your app has been downloaded by customers and has positive reviews. If that is the case, please open a support ticket and include the App ID, confirmation, direct link provided and the search terms you tried.
And once published, promote your app!
It is also important that you help give your app an initial boost. Promote your new app to your prospects and customers with the Store download badge, through your own website, email, and social media. Run campaigns with promotional ads andhouse ads, and consider letting customers try out your app with promotional codes. And, if you sign up for the Microsoft Affiliate Program, you can earn an additional 7% commission on certain sales through the Store download badge.
These recommendations can help your app be visible and more successful in the Store, while also help customers continue to find high value and relevant apps.
One of the latest trends that has excited many technology enthusiasts in the last few years is Internet of Things (IoT), which has the potential to transform how technology is consumed by enterprises and end users in the coming years. Windows 10 IoT Core already supports popular boards like Raspberry Pi2, MinnowBoard Max and DragonBoard, and because Node.js continues to see a lot of excitement in the IoT and the maker community, we have been actively updating the Node.js support for Windows 10 IoT Core for new scenarios since it was released last year.
Yesterday, Node.js support for Windows 10 IoT Core reached a new major milestone. The Chakra team submitted a Pull Request(PR) to mainline Node.js using the recently open sourcedChakraCore JavaScript engine. Once accepted, this PR will allow us to move at the speed of Node.js while accomplishing two goals. First, growing organically based on community feedback and, second, bringing innovation faster to the developers on Windows 10 IoT Core. As per our roadmap, detailed in this blog, the Chakra team will continue to work closely with the community and the Node.js Foundation to improve module compatibility and evaluate Node.js performance.
The September update for Node.js support for Windows 10 IoT Core made it easier to get started and improved compatibility of some key IoT specific npm modules. This project continues to make progress by keeping it current with Node.js and incorporating community feedback. Today, we are releasing the version 1.5 update to Node.js Tools for Windows IoT. The following are some of the highlights of this new release.
Console Apps
The console application model constitutes a majority of Node.js development on Windows 10 IoT today. This is a familiar Node.js experience wherein developers are used to working with their favorite editor and a command prompt across platforms. Windows 10 IoT Core supported this app model from the beginning, allowing the use of Node.js with Chakra and using PowerShell, SSH, or SMB file transfer to manually deploy their scripts on the device. This experience will continue to work in the 1.5 update using Node.js with ChakraCore. ChakraCore will be developed in the open, will see faster updates, and will work across different Windows OS starting from Windows 7 and higher. Node.js with ChakraCore is aligned with Node.js master and currently supports Node.js v6.0.0. Developers can get started and try it out even with the standalone installer for Node.js with ChakraCore. You can use some of the console app samples like MemoryStatus and Using Cylon, which are available at our site.
Universal Windows Platform (UWP) Apps
Node.js developers for Windows 10 IoT Core also enjoy the benefits of Universal Windows Platform (UWP) model using Node.js. This app model is central to the Windows 10 ecosystem and allows developers to target the entire family of Windows 10 devices. UWP apps built using Node.js are powered by the inbox Chakra JavaScript engine, and the Node.js Tools for Windows IoT v1.5 will install all the relevant tools and binaries needed to create a UWP app in Node.js. This option allows familiar Visual Studio experience. The latest release includes better debugging support, more templates to help developers get started easily, and Node.js support for the latest stable release. It requires Visual Studio 2015 Update 1. The following are some key improvements for this scenario:
Support for Node.js Tools for VS 1.1 The latest NTVS release brings more reliable debugging and IntelliSense, support for npm v3, code snippets, and general stability and performance improvements.
Support for Node v5.4.1
We always want to be on the cutting edge of node.js and the latest build of Node.js Tools for Windows IoT supports the latest stable version v5.4.1
Built-in Template for Johnny-Five Johnny-Five, a popular JavaScript Robotics and IoT programming framework, is well supported with Windows 10 IoT Core; with this release, we are making it even easier to get started with it by including a built-in UWP template for Johnny-Five.
New project dialog inside Visual Studio 2015 showing Johnny-Five UWP template
Candy Robot
Our goal is to continue improving and also provide great Node.js support in Windows 10 IoT Core. As a part of the ChakraCore launch, we recorded a demo that showcases Node.js with the ChakraCore console app running on Raspberry Pi2 with Windows 10 IoT Core. We call it the “Candy Robot.” The demo shown here uses 100+ dependent npm modules including cylon, serialport, firmata, and express (there is also a version which uses Johnny-Five instead of cylon at our repo), just to illustrate the breadth of module support that is already available.
The Candy Robot has a light sensor on it. When it moves, the robot uploads the light intensity data at a given point to a server. The server has an interface to view the average brightness data and exploration time. It further shows an early preview of the Time-Travel debugging feature, which we are working on and will be sharing more about as it evolves.
If you want to play with it yourself and hook it up with some more interesting sensors and functionality, here is the detailed step-by-step instruction for the demo.
It’s a lot of fun working on this project, and we truly value your support and feedback so far, so please keep them coming on our issues page. You can also reach us on Twitter at @ChakraCore or visit ChakraCore’s GitHub repo and leave us a note by opening an issue.
Can’t wait to see what you build!
Written by Arunesh Chandra, a senior program manager on Chakra
Image may be NSFW. Clik here to view.
Welcome to the first in a series of hands-on blog posts for the Windows Bridge for iOS. The Windows Bridge for iOS is an open-source project that allows you to create Universal Windows Platform (UWP) apps that can run on Windows 10 devices using iOS APIs and Objective-C code.
Today, we’re going to build a simple to-do list app in Xcode and use the Windows Bridge for iOS to bring it over to Windows 10, keeping all of the code in a single codebase so the project is completely portable between platforms. If you want to follow the complete, end-to-end journey, you’ll need:
A Mac running Mac OS X 10.11 with Xcode 7 installed. If you want to run the iOS project on an actual iOS device, you’ll also need a paid Apple Developer account.
If you don’t have a PC, you can download one of our pre-built evaluation virtual machines from the Windows Bridge for iOS website. Download the package for your preferred virtualization environment and you’ll be up and running in no time – the package already includes Windows 10, Visual Studio 2015 and the iOS bridge.
If you don’t have a Mac but are curious about developing in Objective-C on Windows 10, you’ll still be able to download the source code, go through the conversion process and edit the code in Visual Studio.
Building a to-do list app in Xcode
First, download the initial to-do list project, which can be found here. Open up the ToDo.xcodeproj file and let’s examine the project structure.
In the Storyboard editor, we have a single UINavigationController as our root view controller and a UITableViewController that will be our main screen. Since the whole app is a single view, a navigation controller isn’t strictly necessary, but it leaves room for extensibility if you would like to experiment with taking the project further.
We’ve built most of the app programmatically, so the only other item of note is the “Clear” UIBarButtonItem, which has an IBAction outlet in the clearAllTodos: method in TDTableViewController.
Now let’s take a look at the classes in the left sidebar in Xcode:
TDItem – this is our barebones data structure for holding to-do list items.
TDTableViewController – this is where most of the logic of our app lies. This class inherits from UITableViewController and manages creating new to-do items and displaying in-progress and completed to dos.
TDTableViewCell – this class inherits from UITableViewCell and provides the layout for both in-progress and archived to dos. It uses a pan gesture recognizer to add the swiping functionality and keeps a reference to its currently displayed TDItem. Its delegate is its parent table view controller, which is notified when a cell is swiped left (to delete a to do) or right (to archive a to do).
TDInputTableViewCell – this class also inherits from UITableViewCell and is used to display the input field for adding new to dos. Like TDTableViewCell, its delegate is its parent table view controller which is notified when a new to do is added.
TDLabel – finally, TDLabel inherits from UILabel and simply provides a mechanism for having a thick strikethrough through its text.
Go ahead and run the app in the iOS simulator in Xcode, and you’ll see our app starts up and runs nicely:
Try adding a few to-do items and swiping right to archive an item and left to delete it. If you quit the simulator and relaunch, you’ll notice your list disappears; we’ll examine methods of persisting data across sessions once we bring the app over to Windows.
Now copy the project directory onto a thumb drive and open it on your Windows machine. (If you’re using a Mac with a virtual machine, you can also just copy the project to a shared directory that is accessible from both the Mac and Windows sides.)
Next, let’s turn our Xcode project into a Visual Studio solution.
Using vsimporter
On your Windows machine, open up the winobjc directory and navigate to winobjc/bin. Inside, you’ll find a file called vsimporter. Vsimporter is a command-line tool that turns an Xcode project file into a Visual Studio solution. It automatically handles Storyboards and Xibs, although Visual Studio does not currently have a Storyboard editor, so any changes to our Storyboard have to be made on the Mac side. (This is why we built most of the layout programmatically.)
In a separate window, open your to-do list project directory in file explorer. Select File > Open command line prompt and you’ll see a command line window appear. Drag the vsimporter file located in winobjc/bin on top of the command line window and you should see its full path appear. With the command line window in focus, hit Enter, and then return to your to-do list project directory, which should now contain a brand new Visual Studio solution file.
Using Visual Studio and the iOS bridge
Double click the new Visual Studio solution file that was just created and Visual Studio 2015 will launch. In the Visual Studio Solution Explorer sidebar, you’ll see the top-level solution file, which you can expand to see the familiar class structure we had in Xcode. Header files are stored in their own directory in Visual Studio, but otherwise the structure should look the same.
Our iOS app is running natively on Windows 10 using Objective-C.
The first thing you’ll notice is the app doesn’t scale properly. Windows 10 runs on a wide variety of form factors with different screen sizes, so to ensure a good user experience, your app should be aware of, and respond to, the configuration it’s being run on. To accomplish this, we’re going to create a Category for our app in our app delegate called UIApplicationInitialStartupMode.
In the Solution Explorer, double click AppDelegate.m. Beneath the very first #import, add the following code:
#ifdef WINOBJC
@implementation UIApplication (UIApplicationInitialStartupMode)
// Let WinObjC know how to render the app
+ (void) setStartupDisplayMode:(WOCDisplayMode*)mode
{
mode.autoMagnification = TRUE;
mode.sizeUIWindowToFit = TRUE;
mode.fixedWidth = 0;
mode.fixedHeight = 0;
mode.magnification = 1.0;
}
@end
#endif
Here, we’re using the #ifdef and #endif preprocessor directives to check to see if the WINOBJC symbol is defined, giving us the ability to include Windows-specific code. This keeps the codebase portable, since the Windows-specific code will simply be ignored if we go back to Xcode and run the app on iOS.
What to do when you find unsupported iOS API calls
With a little digging, we quickly find that we hit bugs when adding new to dos and archiving them. In both cases, we’re using UITableView’s beginUpdates and endUpdates instance method calls, which allow us to edit the underlying data structure and insert and move around rows in our table view and guarantees the validity of the whole transaction. A quick look at the runtime log shows that these methods aren’t supported in the iOS bridge:
First, make sure you file a bug on GitHub. GitHub is the best way to get in touch with our team to let us know what tools you need. If you find unimplemented APIs, features you’d like to see, or bugs anywhere in the bridge, please let us know.
Next, we can use the same preprocessor directives we used to fix the app rendering problems to create workarounds specifically for this use case. Open up TDTableViewController.m in Visual Studio and let’s tweak the toDoItemDeleted:, toDoItemCompleted:, and toDoItemAdded: methods:
This method lets us easily share code between an Xcode project and a Visual Studio solution. When running the app on iOS, we continue to use beginUpdates and endUpdates to manage inserting and moving cells, but on Windows we simply update the underlying data structure and call reloadData which forces the entire table view to rerender.
Hit F5 and your to-do list app should run without errors.
Persisting data
Now, a to-do list app isn’t all that much use if it can’t remember your to dos, and currently our app keeps everything in memory, so every time you launch it you have to start from scratch. We can do better.
Since we have such a simple use case, we can use property list serialization to store our to dos in a .plist file. This way, we can write out the file every time a to do is added, deleted or archived, and simply read the file on app load. (A more robust implementation would only write out the relevant change every time one is made, rather than the complete list of to dos, but for the sake of simplicity we’ll just write everything out after every change.)
Head back over to TDTableViewController.m and add the following methods at the bottom:
In order to store our custom TDItem object in a property list, we’ll need to convert it into an NSDictionary. Luckily, our TDItem implementation has a serialize method that does exactly that and returns an NSDictionary. What a coincidence!
Now, we simply need to update our toDoItemDeleted:, toDoItemCompleted:, toDoItemAdded:, and clearAllTodos: methods to call [self writeToDosToDisk] right before returning and add a call to [self readToDosFromDisk] at the end of viewDidLoad.
Press F5 again to run your app and your to dos will now be remembered across launches, so you’ll never forget anything at the grocery store again. The new app is completely portable across Windows 10 and iOS, so you can open your old Xcode project file up on your Mac and the app will continue to function exactly as expected.
Thanks for following along! You can download the complete to-do list Xcode project from our GitHub wiki, and stay tuned for more tutorial posts – we’ve just scratched the surface of the possibilities with the Windows Bridge for iOS.
Before we dive into talking about the interaction model, we wanted to share that today is the day we open up Twitter voting to select the winner for the Share Your Idea campaign!
The Share Your Idea campaign has generated over 5000 ideas which are now available to the developer community as an idea bank. If you want to build a holographic app, but aren’t sure what you want to build, this is a great place to go to be inspired by the incredibly creative people who have chosen to participate.
With that out of the way, let’s dig in a little deeper into the ways that you can interact with HoloLens.
There are three key elements to input on HoloLens:
Gaze – What you’re looking at, and how you target
Gesture – An “air-tap” gesture that HoloLens will recognize, and which allows you to drive selection
Voice – Full access to the Windows 10 speech engine
Gaze is one of the most natural forms of interaction that we have. On HoloLens, at any time, the system knows where your head is in space, and what is directly in front of you. We leverage gaze to understand what you’re paying attention to at any given time, and to establish what both gesture and voice should be targeting.
As an example, in the Airquarium finalist, one of the core ideas is that you can look at anything and issue a tap to find out more about the animal that you selected. The way the system understands what to give facts and stats about when you issue a command is from gaze. Image may be NSFW. Clik here to view.
Gaze really is that simple, and that powerful. Of course, while you wear the HoloLens, you are generally moving around, so your gaze is also moving. The easiest way to think about it is as having a raycast from the device and which you can determine what object (real world as represented in the spatial mapping mesh or holographic) that ray intercepts with. Once you’re gazing at the animal, and you want to find out more, you need to tell the HoloLens to take an action. This brings us to gesture.
Gesture is the way to take a basic action in HoloLens. Simply raise your hand with your index finger raised, and tap down with your index finger. Now you can target (with gaze), and act (with gesture). We use these two primitives to build up all of the standard interactions that you would expect to have with a screen today, but now freed to interact with holograms embedded into your world.
Voice can really shine when you want to drive deeper interactions. These make voice a powerful input method for HoloLens:
Because HoloLens is a full Windows 10 device, the complete speech engine from Windows 10 is available to you as a developer.
Because the device is head mounted, and we actually understand where your mouth is, we have been able to build array microphones into the device which produce a very high quality audio signal for the purpose of doing speech recognition.
Because gaze is present, you actually have a better user context than is possible to attain for voice driven applications today. It is now possible to understand the object or area of interest which a voice command is intended to target. Because the device can provide this context, the user doesn’t need to try to preface each command with what they’re looking at, which will allow deeper, easier voice driven interactions than have been possible to date.
As an easy illustration, consider the Galaxy Explorer finalist. One of the core ideas is that at any time, you can navigate through the universe using natural voice commands. Image may be NSFW. Clik here to view.
Here you establish context (a planet or other feature) based on gaze, and then use voice to actually drive what you want to have happen. The user doesn’t need to explain that they’re targeting a particular world, because gaze is already telling us that. In this way, gaze will combine seamlessly with voice commands to allow you to explore the universe in a way you’ve never been able to before.
It is particularly satisfying to be able to open up voting on the anniversary of our original product announce, when we first got to share a bit about the amazing technology that we’re working on with the world. We’ve been blown away by the level of enthusiasm that all aspects of our program have received, and look forward to continuing to engage the community as we drive towards the launch of the Development Edition. If you’re interested in a trip down memory lane, you can see a bunch of the content that we’ve released over the last year here.
If your app handles user data, then secure authentication should be one of your primary concerns. Identity management is a hard thing to do well, involving encryption, reset mechanisms, and other security measures. Two-factor authentication is more common nowadays, but it increases complexity for both the user and the identity provider. Moving from less secure password systems to two-factor authentication via Microsoft Passport and Windows Hello can make things more convenient for both parties. In this post, we’ll explore what Microsoft Passport and Windows Hello are, as well as what it takes to use this technology in a Universal Windows Platform (UWP) app for Windows 10.
What are Microsoft Passport and Windows Hello?
You might hear Microsoft Passport and Windows Hello mentioned in the same breath. Windows Hello is the biometrics system built into Windows—it is part of the end-user’s authentication experience. Microsoft Passport is a two-factor authentication (2FA) system that combines a PIN or biometrics (via Windows Hello) with encrypted keys from a user’s device to provide two-factor authentication.
If you sign into Windows 10 with fingerprint or face recognition, then you are already using Windows Hello. This advanced biometric interface enables you to use biometrics rather than the traditional username and password to log in to Windows. Windows Hello is an extensible framework, so while currently you can use fingerprints, facial recognition and iris scanning with it, supported biometrics can be expanded with new hardware.
Note: To enable Microsoft Passport and Windows Hello, the user simply clicks or taps Start > Settings > Accounts > Sign-in options, and selects the options they prefer. Users must have either their Microsoft Account or their Azure Active Directory account connected in Windows settings. After setting up a PIN, Microsoft Passport is available, and Windows Hello can be added to use biometrics.
When Windows Hello recognizes a user, it uniquely identifies and authenticates that user to access Windows on that device. What the user does not see is that Windows Hello releases a stored credential that is used as the second authentication factor by Microsoft Passport. But it isn’t just for logging in to Windows. It also provides a secure way for your app to authenticate an individual user on a specific device.
Note: Businesses can use Passport for Work with (Azure) Active Directory to add more robust management functionality to Microsoft Passport.
The code for implementing this has been made as easy as possible to encourage adoption by the dev community. You don’t need to have a deep understanding of encryption, biometrics, or Microsoft accounts; you don’t even need to know all that much about security to use these features to create a more secure app. Let’s take a look.
Before we get to the code, exactly how does this work?
The trusted platform module (TPM) is the crucial working part of the security. TPM-chips assist in securely storing authentication keys for hardware based authentication.
Microsoft Passport takes the PIN or biometric information from Windows Hello (if available), and uses this information to have the TPM-chip generate a set of public-private keys. The PIN in question is safer than an ordinary PIN or password because it only works with a specific device. Also, the PIN can be of variable length, and may have additional requirements regarding length and complexity in businesses.
The private key remains secured by the TPM; it cannot be accessed directly, but can be used for authentication purposes through the Microsoft Passport API. The public key is used with authentication requests to validate users and to verify the origin of the message.
The following illustration shows how all the moving parts work with each other (see Figure 1).
Figure 1 How Microsoft Passport works with the other components
But what if the user’s device does not have a TPM-chip? While using a TPM-chip is more secure and robust, Windows also contains an alternate software-based mechanism that will be used when no TPM-chip is available. This ensures that your app can function regardless of whether the user’s hardware has the TPM chip or not. An “attestation” can be retrieved for the key to validate whether or not the keys are protected by a TPM-chip and act accordingly (e.g. access to more secure features is only available when TPM-chip is used). Attestation is outside the scope of this blog post, but you can read more about it in the Microsoft Passport and Windows Hello whitepaper.
How you implement Microsoft Passport
To start using Microsoft Passport in your Windows 10 UWP app, you don’t need worry about writing custom code to create asymmetric encryption keys or handle user authentication with their credentials. Microsoft Passport APIs handle all of this so that you can focus on what your app does rather than on how to build your own security system.
First, you should prepare the server side of your app to accommodate the change of storing multiple public keys for each device of the same user, versus the traditional username and password. This is to make sure your app can handle however many devices the user uses your app with. Take a look at this simple database diagram for an example:
Figure 2 An example of the tables you could design for storing keys
One table stores the user information, and it joins to another table that can hold multiple keys for each of their devices. Of course, you will likely need more information stored about your users. This is just a basic example.
On the client side of your app, the first step will be to make sure the user can use Microsoft Passport on their current device—they must have set up a PIN in Windows settings. You can check this with the KeyCredentialManager.IsSupportedAsync() method, which returns true if they are already set up.
// Check if the device is capable of provisioning Microsoft Passport key credentials and
// the user has set up a PIN on the device.
if (await KeyCredentialManager.IsSupportedAsync())
{
// Continue logic
}
If the user hasn’t configured Microsoft Passport via the PIN, you should invite them to do so. However, to be flexible, design your system to allow for the possibility that they continue to use their existing username-password login if you’re migrating from an existing system to using Microsoft Passport.
You should also provide some interface for your user to unregister a specific device for use with your app. For instance, if they want to remove a device they no longer own. Typically, this would be implemented in a web interface that users can access or in an account settings overview accessible from the web and/or the app on other devices.
Once you’ve established that the user has a PIN, your app should create a credential key by invoking the KeyCredentialManager.RequestCreateAsync method. This will…
prompt a dialog to request the user’s PIN or biometric
authenticate the user on this device again
create the asymmetrical public-private key pair
private async Task<IBuffer> CreatePassportKeyCredentialAsync()
{
// Create a new KeyCredential for the user on the device.
KeyCredentialRetrievalResult keyCreationResult =
await KeyCredentialManager.RequestCreateAsync(userId,
KeyCredentialCreationOption.ReplaceExisting);
if (keyCreationResult.Status == KeyCredentialStatus.Success)
{
// User has authenticated with Windows Hello and the key
// credential is created.
KeyCredential userKey = keyCreationResult.Credential;
return userKey.RetrievePublicKey();
}
else if (keyCreationResult.Status == KeyCredentialStatus.NotFound)
{
MessageDialog message = new MessageDialog("To proceed, Windows Hello needs to be configured in Windows Settings (Accounts -> Sign-in options)");
await message.ShowAsync();
return null;
}
else if (keyCreationResult.Status == KeyCredentialStatus.UnknownError)
{
MessageDialog message = new MessageDialog("The key credential could not be created. Please try again.");
await message.ShowAsync();
return null;
}
return null;
}
With the key pair created, your app can request the public key with the RetrievePublicKey method and send it together with the user information to register or enroll the user with the server.
Once the user is registered, you can validate their access to the app’s service or data for subsequent logins. To do that, you create a “challenge” from your app’s server that will be signed by your client app via the RequestSignAsync method. The server validates the signature with the device’s public key. Take a look at the diagram below. It illustrates the backend authorization process (see Figure 4):
Figure 4 Challenge and response between client app and server
Note that the challenge that’s created by the server is something you have to implement for your specific situation, making sure it’s a secure challenge that prevents things such as replay attacks, man-in-the-middle, etc.
For each authentication request, the user will be presented with the Windows system UI to enter their PIN or use Windows Hello. This helps them feel confident that their credentials are being validated by Windows rather than third party software.
After successful signature validation, your regular authentication flow should apply, for example generating a token that is handed to the app to perform subsequent API calls with until the session expires.
Multiple devices and multiple users
Many people own multiple devices and expect to be able to sign into the same app from each of them. With a username-password system, there’s just one account per user. But with Microsoft Passport, you need to provide support for 2FA authorization on each device.
Since we’ve already designed our app to accommodate multiple keys per user, we need only register each new device with the proper keys. Doing this requires exactly the same code as registering the user’s first device: KeyCredentialManager.RequestCreateAsync. To more easily identify a specific device from the user’s other devices, you’ll likely want to store the device name or ID as well. We’ve already added deviceID to the example table in Figure 2. That may suffice, or you may want to add a new table that joins to our UserKeys table by deviceID.
How an extra device is enrolled is at the developer’s discretion, but a smart way would be to require validation on their already registered device to register the new one. Another mechanism, for more secure environments, might involve an SMS message or letter being sent to the user with a code they can use to validate.
Another scenario to consider is multiple user accounts on the same device; users may share a device. For example, if a family shares a tablet for entertainment purposes but each maintains their own user account, they will need to individually register the device with their account.
The GitHub Sample
In December, a sample app implementation for Microsoft Passport was published up on GitHub to demonstrate how this entire process works, including both the client and the server pieces. However, keep in mind that this Microsoft Passport sample is greatly simplified. It is not secure enough for a production environment—it’s just a rudimentary sample, not a prescriptive template.
The solution consists of three projects:
Project
What it’s for
Client
This represents your app
Models
This is a portable class library that contains a classes shared between the Client and Server projects
Server
This imitation server stores user and device data in memory
This sample enables you explore the actual flow from the client to the server and back, as well as how specific interactions work.
Wrapping Up
User security is a top priority, but hopefully this has given you some insight into how Microsoft Passport and Windows Hello can reduce complexity for your implementation. To hear more about using Windows Hello and Microsoft passport in your app, check out this video on Channel 9. You can also see the code in action using the Microsoft Passport GitHub sample. We also suggest the Microsoft Passport and Windows Hello whitepaper, which covers all of this information in greater depth and describes scenarios, such as how to authenticate against your services with Microsoft Passport, how to convert from an existing username/password system, and how to use attestation information for a higher level of security.
This post is a general overview of the Windows Virtual Shields for Arduino library, one of the technologies being used in the World’s Largest Arduino Maker Challenge. If you have not heard about the contest, we have more information at the bottom of this post.
If you’ve used an Arduino, you’re familiar with the concept of a shield. Each shield has a specialized purpose (e.g. a temperature shield, an accelerometer shield), and building a device with multiple shields can be complex, costly, and space-inefficient. Now imagine that you can use a low-cost Windows Phone as a compact set of shields. Your Arduino sketch would be able to access hundreds of dollars worth of sensors and capabilities in your Windows Phone through easy-to-use library calls.
This is exactly what the Windows Virtual Shields for Arduino library enables for developers. And that’s not the best part. This technology works for all Windows 10 devices, so you can use the sensors and capabilities on your PC and Surface as well. Also, the Arduino can offload computationally expensive tasks like speech recognition and web parsing to the Windows 10 companion device!
Now let’s take a closer look at the technology. You can find the Windows Virtual Shields for Arduino library on our GitHub page – this is the library that will be included on your Arduino sketch. You will also need to install a Universal Windows Application on your Windows 10 companion device to help surface the sensors and capabilities. This application can be downloaded from the Microsoft Store. Additionally, the open-source code for the Store application can be found here.
You can control the following sensors and capabilities from an Arduino using the Windows Virtual Shields for Arduino library:
Sensors:
Accelerometer
Compass
GPS
Gyrometer
Light Sensor
Orientation
Capabilities:
Screen
Touch
Camera
Email
Microphone
Notifications
SMS
Speech-to-Text
Speech Recognition
Vibration
Web
Let’s take look at a simple sample
Now that you know what the Windows Virtual Shields for Arduino is, let’s talk about how to use the library.
Quick setup
The full setup instructions can be found here. Briefly, the software setup includes:
Downloading the Windows Virtual Shields for Arduino library from the Arduino Library Manager in the Arduino IDE.
Downloading the Windows Virtual Shields for Arduino Store application on your Windows 10 companion device from here.
Connecting your Arduino to your Windows 10 companion device with a USB, Bluetooth, or network connection.
Writing and deploying your sketch on the Arduino IDE.
Hello Virtual Shields
A skeleton “Hello World” application using Windows Virtual Shields for Arduino looks like this:
#include <ArduinoJson.h>
#include <VirtualShield.h>
#include <Text.h>
VirtualShield shield; // identify the shield
Text screen = Text(shield); // connect the screen
void setup()
{
shield.begin(); // begin communication
screen.clear(); // clear the screen
screen.print("Hello Virtual Shields");
}
void loop()
{
}
As you can see, using a Virtual Shield is simple. In the sketch above, we include all necessary libraries and declare a VirtualShield object. We then declare a specific shield (Screen) object to represent the screen of the Windows 10 companion device in use. The program starts a serial communication, clears the screen of the Windows 10 companion device, and prints the line “Hello Virtual Shields” on the freshly cleared screen.
A glimpse at the architecture
Now that we’ve seen a simple sample, we can take a deeper dive into the architecture at play.
The communication between the Arduino library and the Microsoft Store app is done over a USB, Bluetooth, or network connection. The protocol uses JSON by making use of the efficient open-source library ArduinoJson. This is what a simple transaction looks like across the wire (Arduino on left, Windows 10 companion device on right):
This is a simplified illustration of the basic communication enabled by Windows Virtual Shields for Arduino.
A more complex sample with sensors
Let’s take a look at a more realistic example that includes sensors. All sensors in the Windows Virtual Shields for Arduino library have the four functions listed below:
get – This function is a one-time data request to a sensor. An example would be reading acceleration values off of an accelerometer.
start – The start function begins a series of get calls, performed at a specified interval. The interval could be determined by time (read accelerometer data every second) or value change (report if the acceleration changes by 1 unit).
onChange – This function is exactly like start, except it does not report a data reading the first time it is called. It will begin reporting based on a chosen time interval or change in sensor reading.
stop – This function ends a running start or onChange
Working with GPS
With a base knowledge of how sensors work in Windows Virtual Shields for Arduino, we can take a look at something more specific. The following sample will explore how to pull GPS readings from a Windows 10 device onto an Arduino.
The code for this example is seen below:
#include <ArduinoJson.h>
#include <VirtualShield.h>
#include <Text.h>
#include <Geolocator.h>
VirtualShield shield;
Text screen = Text(shield);
Geolocator gps = Geolocator(shield);
void gpsEvent(ShieldEvent* shieldEvent)
{
// If there is a sensor error (errors are negative)... display message
if (shieldEvent->resultId < 0) {
screen.printAt(3, "Sensor doesn't exist");
screen.printAt(4, "or isn't turned on.");
screen.printAt(6, "error: " + String(shieldEvent->resultId));
return;
}
String lat = String("Lat: ") + String(gps.Latitude);
String lon = String("Lon: ") + String(gps.Longitude);
screen.printAt(3, lat);
screen.printAt(4, lon);
}
void setup()
{
shield.begin();
screen.clear();
screen.printAt(1, "Basic GPS Lookup");
gps.setOnEvent(gpsEvent);
// Check GPS if reading changes by ~1/6 of a mile
gps.start(0, 0.01);
}
void loop()
{
shield.checkSensors();
}
In setup, we initialize the gps.setOnEvent handler to call gpsEvent whenever a response is received. Then in loop, we start the GPS and call the function checkSensors. The call to checkSensors is required to start receiving responses and processing callbacks for any sensor or capability. Finally, the gpsEvent function prints latitude and longitude readings every time the GPS senses a shift greater than our specified delta (0.01 longitudinal/latitudinal degrees).
Here you can really start to see the power of Windows Virtual Shields for Arduino – it’s simple and easy to pull data from the Windows 10 companion device, and the device unifies a large collection of sensors and actuators that would otherwise be complex and costly.
A glimpse at the architecture
In the graphic below, we explore the underlying architecture of the GPS communication sample:
Now that we’ve seen how sensors and simple screen capabilities work with Windows Virtual Shields for Arduino, we can take a look at a more complete project.
Check out this simple Hackster.io project to see the library working in action.
A quick look at more complex capabilities
So we’ve sent text to a companion screen, and we know how to get sensor readings. That’s a good start! But we’ve just scratched the surface of what Windows Virtual Shields for Arduino is capable. In this section, we’ll take a brief glimpse at some of the more advanced capabilities that your Arduino can control on your Windows 10 companion device.
Graphics
Basic graphics instructions and events are handled the same as sensors. A rectangle instruction
(id = screen.fillRectangle(80,120,70,70, YELLOW)) would produce the following communication:
And pressing and releasing the rectangle on the Windows 10 companion device would send back events tied to id.
Speech
The speech functionality of Windows Virtual Shields for Arduino includes Text-to-Speech and Speech Recognition. Here we see another huge advantage of Windows Virtual Shields for Arduino – we can leverage the computational power and APIs of the Windows 10 companion device to enable speech scenarios.
Text-to-Speech is simple and can be initiated by a command such as speech.speak(“Hello World”). This particular command will make the Windows 10 companion device speak the words “Hello World”.
The Speech Recognition functionality returns an indexed list of choices. Issuing the request recognition.listenFor(“yes,no”) would return an event with where 1=”yes”, 2=”no”, or 0=unrecognized (negative values are error indicators). The event can also account for groupings, such as recognizing a variety of words (“yes”, “yeah”, “ok”) as the single option “yes”. Recognition can also handle open-text, but is limited to 100 characters due to the memory and buffer size of an Arduino.
Web
You can also use the web capability to retrieve a web page and parse it before returning a web event to Arduino. This is really useful, as most web pages are larger than the entire Arduino onboard memory. The parsing engine uses an abbreviated instruction set to fully parse a web page.
The following code retrieves a weather dump from NOAA as a JSON blob, then parses the JSON to retrieve the current weather.
The event returns “Redmond WA|This Afternoon|Chance Rain”. As with speech, Windows Virtual Shields for Arduino moves expensive tasks to the companion device, allowing for more free memory on the Arduino.
Where we want to expand Windows Virtual Shields for Arduino
Windows Virtual Shields for Arduino has already come so far, but there are many ways in which we could improve the technology further. The great part is, the library is open-source – any developer interested in expanding this technology is more than welcome. All of the code is available from our GitHub page.
Let’s take a look at three areas we would want to expand upon, if time were no obstacle!
First, we would add even more sensors and capabilities. NFC would make an excellent addition – this would enable scenarios like unlocking a door with your phone or transferring NFC payments. Others desired sensors and capabilities include: an Iris scanner (e.g. on a Lumia 950 XL); FM radio control; and device geofencing (rather than using the GPS and coding it yourself on Arduino). Also, Cortana would make an excellent addition.
Next, we could improve existing sensors and capabilities. For example, GPS returns a latitude, longitude, and altitude, and the sensor can be triggered on a settable delta. However, that delta is singular and applies to all properties equally. If you wanted to monitor a small change altitude, but not latitude or longitude – or ignore a large change in altitude (e.g. a tall building), then the sensor system would need more than one delta to monitor.
A third option would be to expand the scope. The Universal Windows Application currently connects to only one device at a time. We can imagine scenarios where multiple Arduinos can connect to a single app, such as in a home control systems (e.g. self-registering heating ducts opening/closing depending upon where you are).
And of course, there are countless other ways in which this technology can evolve. Explore it yourself, and see what you can build!
The World’s Largest Arduino Maker Challenge
Now that you’ve learned the ins and outs of Windows Virtual Shields for Arduino, it’s time to put your newly-learned skills to the test. The World’s Largest Arduino Maker Challenge would be a great opportunity to make use of the library.
The competition’s title is no overstatement – with more than 3,000 participants and 1,000 submitted project ideas in just the preliminary phase, this is truly the World’s Largest Arduino Maker Challenge. The contest is brought to you by Microsoft, Hackster.io, Arduino, Adafruit, and Atmel.
The parameters of the contest are simple – participants must develop a Universal Windows Application (UWA) that interfaces with an Arduino using a connection. Windows Virtual Shields for Arduino and Windows Remote Arduino are two recommended ways of establishing this connection. Check out the contest site for more details.
We hope you take this opportunity to learn more about the library and submit something great for the World’s Largest Arduino Maker Challenge! We can’t wait to see what you make!
Written by Devin Valenciano (Program Manager) and Jim Gale (Principal Software Engineering Lead) from Windows and Devices Connected Everyday Things team
In the previous post in this series, we talked about using the Windows Bridge for iOS to create Universal Windows Platform (UWP) apps that can run on Windows 10 devices using existing Objective-C code. This post focuses on getting Xcode and iOS developers familiar with the Visual Studio IDE, whether starting from scratch or using existing code from a source repository, such as GitHub.
Modern IDEs, especially those for app development, are becoming very similar. While each may have its own nuances and intricate IDE features, they will all generally offer the same key functionalities. There will be a way to load projects and solutions, lay out controls visually, work with code, and debug with some level of emulation. As a result, once you learn the basics of one IDE, you’ll find you can pretty easily transfer that knowledge to the others.
It is no different moving between Xcode and Visual Studio. In fact, the team at the One Dev Minute blog on Channel 9 put together an excellent summary video that quickly shows a feature-for-feature comparison when putting together a sample app, though it shows older versions of Visual Studio and Xcode.
The first step in working with any IDE is loading up a project. In Visual Studio (click here to get the free Visual Studio 2015 Community edition), the steps are basically the same as starting a project in Xcode. Just point to File → New → Project.
Image may be NSFW. Clik here to view.In this case, we’ll pick a project template from a list of installed templates, set the application and solution name, and select the directory where the files will be stored:
After clicking OK, the template creates a runnable UWP app that compiles and runs but contains no UI or data. We selected the Blank App template above. As with all templates, this will create the minimal required files needed for creating an app:
Packages, libraries, frameworks, and references needed for the app to run
A manifest file (appxmanifest) that describes your app (its title, description, start page, et cetera) and lists all the files that your app contains
Code files for your app
Set of logo images to display in the start menu
Windows Store app image
A temporary key file (.pfx) for signing and deploying your app during development
Splash screen
XAML (xaml) page to get you started coding your UI
Note: If this is the first UWP app you’ve created with Visual Studio, you will need to set your device to “Developer Mode” in order to run and build applications. In fact, you’ll get the prompt whether or not your device is in developer mode.
With the project loaded into Visual Studio, let’s explore some of the main windows in the IDE.
Note: The following assumes you’re using the default window layout in Visual Studio. If you change the default layout, you can reset it in the Window menu by using the Reset Window Layout command (in the toolbar, click Window → Reset Window Layout.
The first thing you will notice is the code window. This window is where you will work directly with the code files used in your application. The code window is tabbed. Every file you open starts a new tab. If you have too many tabs open to be displayed across the top of the window, you can use the drop down arrow on the right to navigate between files.
In the code window, Visual Studio provides an amazing Intellisense (or code completion) experience. Just start typing and contextually relevant objects, properties, and methods will be suggested and then filtered down with each keypress.
For XAML UI files, you will have the option of editing the XML directly or using Design mode and the drag-and-drop WYSIWYG tools for quickly laying out the UI. Many developers often start in Design mode and then jump into the XML to fine tune. Here, we have opened the toolbar and dragged a variety of UI controls (textbox, button, textblock, etc) onto the design grid:
Note: If Design Mode does not show up for you, right-click your project file and, in the application properties page, under Targeting, adjust your target version to the earliest setting. In order to show design elements, the target needs to be equal to or less than the version of Windows installed.
Left and right of the code window are a number of panes for working with the project files. The one you will use most is the Solution Explorer. The Solution Explorer is the hierarchical representation of the file structure of the project. Clicking files in this pane will load the selected file into the code window. Right-clicking and selecting “Properties” from the context menu will load the properties pane for the selected file.
For files, the properties pane is useful for displaying file information or specifying how files are compiled.
When working in Design Mode, the properties pane is how you specify attributes of UI elements (such as control names, borders, and text) and even assign actions.
At the bottom, you have the output window and error list. This list is useful for getting insight into the steps the compiler goes through and any errors or warnings you may encounter.
It is important to note that all of the windows and panes are modular and can be dragged and docked to set locations within the main Visual Studio window or dragged out altogether. Find a layout that works best for you.
Now that we have loaded up the code and had a look at the various Windows and Panes in which we’ll be working, what’s the one thing every developer does as soon as a project is loaded? Try to compile it. In Visual Studio terminology, this is called “Build.” Generate the application executable/package causes Visual Studio to analyze the code, search for errors in syntax or logic, validate all references and links, and generate the application executable/package .
When building, you have a couple of configuration options. By default, solutions are loaded in “Debug” mode. Debug mode includes full symbolic debug information in the compiled files to enable easy debugging and does not optimize the binary it produces. You can also change the project to release mode. Release turns on the optimizer and the extra debugging information is not included. Release mode is that last step for final QA, performance testing, and publishing to the app store.
There is a handy dropdown in the upper toolbar that allows you to quickly change between debug and release mode.
Just select your build options and then click F5 or, from the toolbar, click DEBUG → Start Debugging. The build will start, and once deployed, will launch on the device you selected. Below is a sample of a deployed app using the Simulator. Because the simulator is running on the PC, we choose x86 architecture. If it we were being deployed to a device, you’d choose ARM.
These panes serve a variety of purposes while debugging. At a very high level…
Autos—displays variables used on the preceding lines while debugging
Locals—displays all variables that are currently in scope
Watch—displays selected variables that you want to watch while debugging
Call Stack—displays where you are in the code at the current breakpoint
Breakpoints—displays all defined breakpoints in the app
Exception settings—allows you to define when to break execution when exceptions are thrown
Command Window—allows you to execute commands within the VS IDE
Immediate Window—allows you to execute statements and commands during debugging
Output—displays status messages for various features in the IDE
To use the advanced debugging functionality, you will need to define breakpoints throughout your code. You can do this from the context menu or by simply clicking in the far left margin:
A red circle will be added to the left margin indicating that a breakpoint has been set. With a breakpoint defined, run your app by pressing F5. When the executing assembly hits the breakpoint, execution will be halted. From here, you have a couple of options. Just like in Xcode, you are able to Step Over, Into, and Out of blocks of code while debugging. Visual Studio provides a toolbar button with a corresponding key on the keyboard:
Step Into. Pressing F11 will continue the execution of the code one statement at a time. If the current line is a method, step to the first line of that method. This is the most granular way to chase down every line of code that is executed.
Step Over. Pressing F10 will execute the current line. If the current line is a method, it will execute the entire method and proceed to the next line of the current block.
Step Out. Pressing Shift + F11 will execute the remaining code in the current block and return the cursor to the calling method.
As you step through your code while debugging, the various debugger windows will be populated with information that will allow you to track down issues in the code more easily.
In many cases, you will be working with an existing code base that resides in source control of some sort. Whether it be TFS, Subversion, or GitHub, the process for loading it up is all basically the same.
Let’s take GitHub, for example.
First, you want to make sure you have the GitHub extension for Visual Studio installed (if you didn’t already select the option when installing Visual Studio).
Once the GitHub extensions are installed, let’s “commit” or “check in” the project we just created to our GitHub repository.
To commit a project to a GitHub repository, in the Solution Explorer pane, simply right-click your solution and select “Add Solution to Source Control.”
Right-click your newly created repository, then click “Open.” On the Team Explorer Home screen, click the “Sync” button, then click “Publish to GitHub.”
This will create a new remote on your GitHub account. From here, go to the Team Explorer home screen and click the “Changes” button. Enter a “Commit Message,” then click the “Commit” button.
The code on your local repository and the code on the server are now synchronized.
With code already “committed” and “synced” to GitHub, loading a solution is as simple as providing the path to your repository. In the Team Explorer pane, select “Manage Connections” and then the “Clone” link.
That’s it! You’re now connected to source control and can commit, sync, and manage code and builds. If you double-click your newly created repository, click the “Open” link, and select the “.sln” file, Visual Studio will go out, grab the code, and then load the solution.
As you can see, working in Visual Studio is not very different than working in Xcode. Whether creating and loading projects, working with code, or debugging, the Visual Studio toolset should feel familiar to you.
For more information on Visual Studio and what you can do with it, check out these links:
