Tag Archives: UWP

UWP and the evolution of touch development

How is programming for touch development on the Universal Windows Platform (UWP) different from mouse and keyboard development in Windows Forms? This post will cover some of the subtle differences between the two and how to use the most advanced tools for building smooth touch experiences.

Fig 1. Command prompt

The ways we communicate with our computers have gone through many changes over the years. For a long time, interactions were governed by the keyboard. Then, the Graphical User Interface (GUI) came along, which not only introduced the mouse, but drastically altered how home screens and apps looked. The success of Windows 95 and Mac OS cemented that user experience, popularized personal computing and changed our computing landscape.

Fig 2. Graphical user interface in Windows Form

While Natural User Interfaces (NUI) have been around for a long time, the transition to touch interfaces has happened both more gradually and more quietly. In part, this is because it occurred hand-in-hand with the growth of smartphone-based mobile computing – and we have a tendency not to see our phones as centers of computing power, but rather as accessories or appliances. In part, though, the smooth transition occurred because the creators of development tools such as Visual Studio made a conscious effort to protect developers from these changes by making touch and mouse (or tap and click) appear to be the same thing. As a consequence, we moved from a mouse-centric development world to touch-friendly development world without really noticing the tectonic shift that occurred beneath our feet.

What does touch-friendly mean?

When touch-enabled tablets first arrived for Windows, you pretty much just used your finger as if it was a mouse to manipulate applications designed for the mouse. It was difficult because buttons tended to be too small and you couldn’t see visual affordances, designed for mouse interactions, hidden beneath your fingers. Even if your device supported touch, the apps running on it continued to be mouse-centric. Similarly, early mobile devices came with a stylus because a stylus could manipulate those tiny buttons.

Fig 3. Natural user interface in Windows Phone

Phone apps mark the transition from mouse-centric to touch-friendly development. Phone apps weren’t just touch-first, of course. They were touch-only. They forced changes in the design, layout and controls used in apps to make interaction easier for smartphone users. These in turn were eventually incorporated into the UWP platform. While the UWP platform supports both touch and mouse interactions, as well as a variety of other inputs, when you develop apps and controls for it, you should think of it first as a touch interface. Mouse interactions should be added on secondarily.

There are many overlaps between touch gestures and mouse interactions that make this easier. For instance, when you tap on a UWP button or click on it, both the Tapped event and the Click event are triggered. Similarly, events such as ManipulationStarted and ManipulationCompleted do not differentiate between touch and mouse. Given the amount of effort that has gone into blurring the difference between touch and mouse in UWP, it is worth asking ourselves, when is a click not a click?

The age-old question: click or tapped

The Button control is an interesting island of GUI behavior in a touch-first world. If you double-click on a button in the Visual Studio designer, Visual Studio will wire up a Click event handler for you in XAML and in code-behind. This is there for backwards compatibility since, as pointed out above, touch and mouse interactions will both throw Click as well as Tapped events.

In order to develop in a touch-first way, however, you should handle the Tapped event rather than the Click. This becomes important when you need to distinguish Tapped from other touch events like DoubleTapped and Holding (the latter cannot even be emulated with a mouse).


<Button Content="My Button" 
        Click="Button_Click" 
        Tapped="Button_Tapped"
        RightTapped="Button_RightTapped"
        DoubleTapped="Button_DoubleTapped"
        Holding="Button_Holding"
        ManipulationMode="All" 
        ManipulationStarted="Button_ManipulationStarted" 
        ManipulationCompleted="Button_ManipulationCompleted"   
/>

Once you have confirmed that your app works well for touch, you should add interactions for the mouse and other input vectors. For instance, you can capture clicks of the right mouse button by handling the oddly named RightTapped event.


    <VisualStateManager.VisualStateGroups>
        <VisualStateGroup x:Name="CommonStates">
            <VisualState x:Name="Normal" />
            <VisualState x:Name="PointerOver"/>
            <VisualState x:Name="Pressed"/>
        </VisualStateGroup>
    </VisualStateManager.VisualStateGroups>

More importantly, you should also have visual states for hover (PointerOver) and Pressed states. In the touch world, these are not particularly useful since your fingers will typically occlude these state animations. Visual affordances and visual feedback can be extremely useful, however, for mouse, pen and touchpad interactions that do not block the user’s view.

Swiping right: online and offline gestures

Touch gestures come in two varieties. There are direct manipulations of objects, which happen automatically when you move one or more fingers across your screen. These are sometimes also known as online gestures. The other kind of gesture is only successful once the user completes a series of steps such as moving an object on the screen from one position to an offset from that position, such as a swipe. These kinds of gestures are easy to identify because they involve thresholds. If the user doesn’t move the object far enough, it fails a distance threshold. If it doesn’t complete the movement in a set amount of time, it fails a time threshold. These are also known as offline gestures.


<Canvas ManipulationMode="None" Margin="0,12,0,0" MinHeight="400">
    <Border x:Name="manipulateMe" 
            ManipulationMode="All" 
            ManipulationDelta="ManipulateMe_ManipulationDelta" 
            Background="LightGray" Height="200" Width="200" 
            HorizontalAlignment="Left" 
            VerticalAlignment="Top"/>
</Canvas>

Direct manipulations can be implemented in XAML by taking advantage of the various UIElement manipulation events. While the ManipulationStarting event can be useful, the only event you really need to handle is ManipulationDelta. You will also want to set the ManipulationMode property, which determines what sorts of manipulation are allowed, e.g. Scale, Rotate, TranslateY, TranslateX. All allow any kind of direct manipulation on the target element.


private TransformGroup transforms;
    private MatrixTransform previousTransform;
    private CompositeTransform deltaTransform;

    private void InitManipulationTransforms()
    {
        transforms = new TransformGroup();
        previousTransform = new MatrixTransform() { Matrix = Matrix.Identity };
        deltaTransform = new CompositeTransform();

        transforms.Children.Add(previousTransform);
        transforms.Children.Add(deltaTransform);

        // Set the render transform on the rect
        manipulateMe.RenderTransform = transforms;
    }

To move and rotate the target UIElement you need to keep track of the transforms being applied to it.


void ManipulateMe_ManipulationDelta(object sender, ManipulationDeltaRoutedEventArgs e)
    {
        previousTransform.Matrix = transforms.Value;

        // Get center point for rotation
        Point center = previousTransform.TransformPoint(new Point(e.Position.X, e.Position.Y));
        deltaTransform.CenterX = center.X;
        deltaTransform.CenterY = center.Y;

        // Look at the Delta property of the ManipulationDeltaRoutedEventArgs to retrieve
        // the rotation, scale, X, and Y changes
        deltaTransform.Rotation = e.Delta.Rotation;
        deltaTransform.TranslateX = e.Delta.Translation.X;
        deltaTransform.TranslateY = e.Delta.Translation.Y;
    }

Then, every time the ManipulationDelta event indicates that the user is trying to move the element, you update the element with the new information.

Making touch manipulations smooth as butter

Today’s users expect touch-driven content to be smooth and immediate. Using ManipulationDelta events can’t completely ensure this because it runs on the UI thread. When there is heavy processing occurring on the UI thread, users may end up experiencing some lag in response to their touch gestures.

To get the best touch experience, it is important to move touch processing off of the UI thread by using the InteractionTracker class. InteractionTracker was introduced with the Composition APIs, and allows interactions and visual feedback at a much lower level than previous UI programming models in UWP. In order to drive composition animations with the InteractionTracker, you need to associate it with a VisualInteractionSource. In the sample code below, the source is a backing visual for the root element of the page.


_tracker = InteractionTracker.Create(_compositor);
 
var interactionSource = VisualInteractionSource.Create(viewportVisual);
 
interactionSource.PositionXSourceMode = InteractionSourceMode.EnabledWithInertia;
interactionSource.PositionYSourceMode = InteractionSourceMode.EnabledWithInertia;
 
_tracker.InteractionSources.Add(interactionSource);

// bind the InteractionTracker outputs to the contentVisual. 
var positionExpression = _compositor.CreateExpressionAnimation("-tracker.Position");
positionExpression.SetReferenceParameter("tracker", _tracker);
contentVisual.StartAnimation("Offset", positionExpression);

For an even more sophisticated implementation of low-latency touch input, you can use the CoreIndependentInputSource class as demonstrated in this sample on GitHub.

Closing the circle

It’s taken a long time to move from DOS prompts to the natural user interface. One of the peculiarities of all these user experience changes is that rather than supplanting each other, these variations just supplement. The keyboard has never gone away, and like a hipster vinyl revival, the popularity of PowerShell and the Linux Bash Shell on Windows suggest that command prompts won’t either. For more information on touch interactions, please follow these links:

Introducing XAML Standard and .NET Standard 2.0

XAML Standard

We are pleased to announce XAML Standard, which is a standards-based effort to unify XAML dialects across XAML based technologies such as UWP and Xamarin.Forms.

XAML Standard is a specification that defines a standard XAML vocabulary. With that vocabulary, frameworks that support XAML Standard can share common XAML-based UI definitions. The goal is for the first version, XAML Standard 1.0, to be available later this year.

Post-specification plans include support of XAML standard in Xamarin.Forms and UWP. You can continue developing your UWP and Xamarin.Forms apps as you do today. When XAML Standard support is enabled, you will be able to reuse and share between the frameworks and expand into more platforms.

To visualize what this support would look like, here’s a side-by-side comparison between today’s XAML in Xamarin.Forms and in UWP:

In the above example – once XAML Standard is supported by Xamarin.Forms, you can use <TextBlock /> and have it supported in a Xamarin.Forms app targeting iOS and Android instead of needing to know and use <Label /> as shown above. In addition to a TextBlock, here are some of the currently proposed items for standardization.

We are at the beginning of a journey that makes it easy for you to reuse your XAML source files between some simple Xamarin.Forms and UWP views. For example – a Settings.xaml page, where you typically have some text, toggle switches and some buttons. You’d only need to design and create one XAML file to describe this UI and that can be used everywhere.

Nothing changes for existing developers – you can continue to use the same APIs you have always used in both frameworks. XAML Standard will help you reuse/share any common UI code that you wish to share between end points.

The XAML Standard v1 draft spec is being defined in the open, we encourage you to start a discussion or give us direct feedback in the GitHub repo here.

.NET Standard 2.0

We are also happy to announce .NET Standard 2.0! .NET Standard is the set of APIs which work in all .NET implementations. A good way to think about it is how HTML5 is today. There are many different browsers which implement HTML parsing and rendering, but the HTML standard is the common glue that holds the web together and allows for interoperability.

.NET Standard was introduced in June of 2016 to bring consistency to the .NET ecosystem. With the .NET Framework, Xamarin & Mono, .NET Core and then UWP, there were many different implementations of .NET and it was very difficult to write code or a library that could work across all of them. Using .NET Standard, and the tooling in Visual Studio, makes it possible to build libraries and NuGet packages that work literally everywhere .NET runs.

The feedback we received on after .NET Standard’s introduction last year was generally phrased as “We like the direction you’re going in, but the set of APIs isn’t large enough to be useful.” The goal with .NET Standard 2.0 is to respond to that feedback and add a large set of .NET’s “greatest hits” into .NET Standard. To do this, we looked at the intersection of APIs between the .NET Framework and Mono. This lead to the 2.0 definition including over 20,000 new APIs and those APIs enable the top 70% of existing NuGet packages to work.

With the addition of .NET Standard 2.0 support for UWP with the Fall Creators Update, .NET developers will be able to share code across all Windows 10 devices, in the cloud and through the rest of the .NET ecosystem. This will also make it easier to reuse existing WinForms and WPF code as many of the most frequently used APIs like DataSet/DataTable, and popularly requested APIs like SqlClient, are now part of .NET Standard 2.0.

You can learn more about .NET Standard here.

Forming the shape of the future

We invite you, the .NET community, to join the discussion and help shape the future of XAML Standard and .NET Standard. You can provide your feedback, both suggestions and issues, at the following locations; .NET Standard on Github and XAML Standard on Github.

Resources:

Announcing Microsoft Build Tour 2017

Figure 1 Sign-up at http://buildtour.microsoft.com

On the heels of the Build conferences these last few years, we have had the pleasure of meeting thousands of developers around the world. Their feedback and technical insight has helped us to continue the tradition and explore more technical depth.

Today, I’m excited to announce the Microsoft Build Tour 2017, coming to cities around the globe this June! The Microsoft Build Tour is an excellent way to experience Microsoft Build news first-hand, and also work directly with Microsoft teams from Redmond and your local area.

This year, we’re bringing the Microsoft Build Tour to these locations:

Dates

City

June 5-6 Shanghai, China
June 8-9 Beijing, China
June 12 Munich, Germany *
June 13-14 Seoul, Republic of Korea
June 14-15 Helsinki, Finland
June 19-20 Warsaw, Poland
June 21-22 Hyderabad, India
June 29-30 Sydney, Australia

The Microsoft Build Tour is for all developers using Microsoft platform and tools. We will cover a breadth of topics across Windows, Cloud, AI, and cross-platform development. We will look at the latest news around .NET, web apps, the Universal Windows Platform, Win32 apps, Mixed Reality, Visual Studio, Xamarin, Microsoft Azure, Cognitive services, and much more.

We also want to go deeper into code, so this year we’re bringing the tour as a two-day* event. You can decide to attend just the sessions on the first day, or sign-up for a deep (and fun!) hands-on experience on the second day.

  • Day 1: Full day of fast-paced, demo-driven sessions, focusing primarily on new technology that you can start using immediately in your projects, with a bit of forward-looking awesomeness for inspiration.
  • Day 2: Full day hackathon where you’ll use the latest technologies to build a fun client, cloud and mobile solution that meet the requirements of a business case given at the beginning of the day. Seating is limited for Day 2, so be sure to register soon!

In most locations, on both days, we’ll also have a Mixed Reality experience booth where you’ll be able to sign up for scheduled hands-on time with Microsoft HoloLens and our latest Windows Mixed Reality devices.

To learn more and register, visit http://buildtour.microsoft.com. Can’t make it in person? Select cities will be live-streamed regionally to give you a chance to view the sessions and participate in the Q&A.

We can’t wait to see you on the tour!

*Munich is a single day, session-focused event.

Announcing Windows Template Studio

Today, we are pleased to announce the next evolution in your File New Universal Windows Platform app in Visual Studio – Windows Template Studio. Windows Template Studio addresses a top community ask in our developer survey to make it easier and provide guidance to create new projects that target the Universal Windows Platform. In this post, we’d like to spend a few minutes introducing Windows Template Studio and show you how it works.

Windows Template Studio uses a dev-friendly wizard to get your UWP apps to F5 in no time, bringing together the pages, frameworks and features that you want. Our wizard walks developers through four steps to quickly scaffold a new UWP app:

  1. Project Type: Select between standard layouts and predefined controls.
  2. Framework selection: Select the structure of your UWP app with in-house and third-party support.
  3. App pages: Select which pages that make sense for the app, that you are trying to create.
  4. App features: Easily add features such as background tasks with one click.

Furthermore, we’re open-sourcing Windows Template Studio, welcoming UWP devs to take the generation engine further – adding additional capabilities and app pages, improving the implemented best practices and patterns – and encouraging UWP devs to make the engine their own – tailoring it to their company’s specific needs.

Windows Template Studio is the evolution of Windows App Studio. App Studio was a free, online app creation tool that allowed developers and enthusiasts to quickly build Windows Universal Apps. We are taking our learnings from the code generation engine and the existing wizard to provide a strong foundation for our code generation and developer experience in Windows Template Studio.

A Lap Around Windows Template Studio

We kick off Windows Template Studio by creating a new UWP app project. In the Visual Studio 2017 ‘New Project’ dialog, select the Visual C# Windows Universal node.

Here you’ll see the Windows Template Studio project. Select the project type, enter in your new UWP app’s name and click ‘OK’. Windows Template Studio will now fire up and walk you through the UWP app creation wizard, step by step.

Step 1: Project Type

You begin by selecting a project type. We’ve started you with the most common types such as: blank, navigation pane and pivot and tabs.

Step 2: Framework

Once you have selected a project type, you need to select a framework. You can select from Code behind, MVVM Basic or the very popular MVVM Light.

Step 3: Pages and app lifecycle features

Once you have selected a project and framework, then it is time to add in pages and features. We’ve already added the most common pages such as Master/Detail, Settings and Web view. You can also easily add in Application Lifecycle features such as Suspend and Resume as well as Background Work and User Interaction.

Best practices and patterns

To wrap all of this up, with a couple of simple clicks, you can wire up an app that uses the Navigation Pane, MVVM Light framework, a Master Detail page and a couple of features such as suspend and resume and Azure hub notifications. You save time, your app is adhering to our design guidance and industry standard patterns and practices come free.

Below is an example of an app generated with Windows Template Studio. Again, we provide the foundation of a great UWP app and get you to F5 in a couple of clicks.

Get Started Today

Windows Template Studio v1.0 is available now and you can expect updates every 6 weeks. We have extremely easy to use instructions for installing the VS extension on our GitHub page as well. A public roadmap is currently available and we’d encourage you to check out The Tips and Tricks for UWP Developer session that was shown at Build to learn more. You can get started creating your own app in three simple steps:

  1. Download Visual Studio 2017 and select Universal Windows Platform development under Workloads.
  2. Install the Visual Studio Extension for Windows Template Studio by downloading the VSIX from the Visual Studio Gallery.
  3. Once installed, open Visual Studio 2017 and select FileNew Project→ C# → Windows Universal and you should see the new template that was just added.

And Best of All…Windows Template Studio is Open Source

Windows Template Studio is completely open-source and available now on GitHub. This project is community led and we’re very excited to already have contributions from the following community members: Matt Lacey and James Croft. We would love for you to contribute to the project and would encourage you to read our contribution guidelines for next steps.

In the spirit of being transparent, the roadmap for the next release is always available. If you have a bug that you would like to report or share a feature request, then please add it to our issue tracker.

We would love to hear how your experiences are using it and the helpfulness of the project. You can reach Clint at @clintrutkas and Michael at @mbcrump.  What are you waiting for? Go and try it out for yourself now!

Announcing Project Rome iOS SDK

Project Rome is a platform for enabling seamless cross-device and cross-platform experiences. The philosophy behind Project Rome is simple. App experiences shouldn’t be tied to a single device any more than data should be tied to a single device. Your apps, like your data, should travel with you.

Previously, this meant switching between devices, while maintaining a single user experience, on a different Windows device. A few months ago, Project Rome features were extended to the Android platform, allowing you to start an app session on your Android phone and continue it on a Windows PC, an Xbox One or even a Surface Hub.

Now, Project Rome support is also being extended to the iOS platform. You can download the Project Rome SDK for iOS here.

Revisiting the Contoso music app

If you have been following the evolution of Project Rome, you’ll be familiar with our developer friend Paul and his example Contoso Music app. Paul was originally introduced in a blog post on Cross-device experiences to help us understand a typical Project Rome scenario.

He expanded his UWP music streaming app to run across multiple Windows devices tied to the same Microsoft Account (MSA). Using Project Rome, Paul changed how his app worked so a user streaming a song on a Windows PC could then transfer that song to his Xbox. Then, as he got ready to go out for a run, he could transfer the current playlist to his Windows Phone.

In the subsequent post, Paul developed an Android version of Contoso Music app and used the Project Rome Android SDK to allow a user to start playing a song on her Android phone and continue playing it on a Windows device when he or she got home. The Contoso Music app was now cross-platform, transferring smoothly from one platform to the next.

Extending to iOS

Let’s imagine that based on the success of his Windows and Android versions, Paul develops an iOS version of Contoso Music. When examining his telemetry after a few months, Paul sees that all his apps are doing well, like his Windows and Android versions. However, there is a common theme in the user feedback; users are finding it difficult handling device switching. So, Paul wants to enable a scenario in which a user can listen to music on the iPhone over headphones, then enter the living room and immediately switch to playing the same music over his Xbox, connected to quality speakers.

With the Project Rome iOS SDK, Paul can create a bridge between iOS devices and Windows devices in two stages:

  • The RemoteSystems API allows the app to discover Windows devices the user owns. The RemoteSystems API will allow the Contoso Music app to discover these devices on the same network or through the cloud.
  • Once discovered, the RemoteLauncher API will launch the Contoso Music app on another Windows device.

How Paul gets it done

In order for Paul’s user to switch from playing music on an iOS device to a Windows device, his app must find out about the other device. This action requires using MSA OAuth to get permission to query for devices and then attempting to discover additional devices, as shown in the diagram below.


// Asynchronously initialize the Rome Platform.
  // Pass in self as class implements the CDOAuthCodeProviderDelegate protocol.
  [CDPlatform startWithOAuthCodeProviderDelegate:self completion:^(NSError* clientError) {
                                              if (clientError)
                                              {
                                                  // Handle error
                                                  return;
                                              }

                                              // Handle success, show discovery screen
                                      }];

// Implementation of CDOAuthCodeProviderDelegate
// The Rome SDK calls this delegate method when it needs an OAuth Access Code from the application.
- (NSError*)getAccessCode:(NSString*)signinUrl completion: (void (^)(NSError* error, NSString* accessCode))completion {

// Stash away the callback the SDK gives us
_getTokenCallback = completion;

  // Show the interactive OAuth Web View flow.
  // Once the OAuth flow completes or fails, invoke this callback.
  ...

// Return nil as there was no error
  return nil;
}

Once initialized, Paul’s app can discover all devices in the user’s MSA device graph by initiating discovery using CDRemoteSystemDiscoveryManager. Information about discovered devices are raised through the CDRemoteSystemDiscoveryManagerDelegate protocol. In In our example, we store each discovered device within an NSMutableArray property called discoveredSystems.


// Create instance and pass ‘self’ as the delegate as it implements CDRemoteSystemDiscoveryManagerDelegate.
CDRemoteSystemDiscoveryManager* remoteSystemDiscoveryManager = [[CDRemoteSystemDiscoveryManager alloc] initWithDelegate:self];

// Start discovery.
[remoteSystemDiscoveryManager startDiscovery];

// CDRemoteSystemDiscoveryManagerDelegate implementation
- (void)remoteSystemDiscoveryManager:
            (CDRemoteSystemDiscoveryManager*)discoveryManager
                             didFind:(CDRemoteSystem*)remoteSystem {
  @synchronized(self) {
     [self.discoveredSystems addObject:remoteSystem];
      // Refresh UI based upon updated state in discoveredSystems e.g. populate table
   }
}

- (void)remoteSystemDiscoveryManager:
            (CDRemoteSystemDiscoveryManager*)discoveryManager
                           didUpdate:(CDRemoteSystem*)remoteSystem {
  NSString* id = remoteSystem.id;

// Loop through and update the Remote System instance if previously seen.
  @synchronized(self) {
    for (unsigned i = 0; i &amp;lt; self.discoveredSystems.count; i++) {
      CDRemoteSystem* currentRemoteSystem =
          [self.discoveredSystems objectAtIndex:i];
      NSString* currentId = currentRemoteSystem.id;

      if ([currentId isEqualToString:id]) {
        [self.discoveredSystems replaceObjectAtIndex:i withObject:remoteSystem];
        break;
      }
    }

       // Refresh UI based upon updated state in discoveredSystems e.g. populate table
  }
}

The user can now select the device he wants to transfer music to from the list of devices that have been discovered. From the selected CDRemoteSystem, an instance of CDRemoteSystemConnectionRequest is instantiated as shown in the sequence diagram below. Using CDRemoteLauncher, Paul is then able to remotely launch the app on the selected device while also including necessary additional contextual information, such as the song currently playing.

Here’s how to remote-launch http://www.bing.com to your device:


// Create a connection request using the CDRemoteSystem instance selected by the user
  CDRemoteSystemConnectionRequest* request =
       // Using the RemoteSystem above, [self.discoveredSystems addObject:remoteSystem];
      [[CDRemoteSystemConnectionRequest alloc] initWithRemoteSystem:system];

NSString* url = @”http://www.bing.com”;

  [CDRemoteLauncher
           launchUri:uri
           withRequest:request
           withCompletion:^(CDRemoteLauncherUriStatus status) {
            // Update UI on launch status
            }];

Voila! Paul has easily augmented his app with cross-device support for iOS.

Wrapping up

Project Rome breaks down barriers by changing notions about what an “app” is and focusing on the user no matter where they are working or what device they are using. An app no longer necessarily means something that is tied to a given device, instead it can be something that exists between your devices and is optimized for the right device at the right time. Today, Project Rome works on Windows 10, Android and iOS. Stay tuned to see what comes next.

To learn more about Project Rome, check out the links below.

Windows is home for developers with Windows 10 Fall Creators Update

It was an amazing day today at Build 2017. With the Windows 10 Fall Creators Update, we continue to grow the Windows platform so that Windows is home for all developers. As I reflect on the day, I want to highlight how Windows and VS are creating the best end-to-end development process and enabling developers not only to maximize their code reuse, but also to create experiences that are engaging, powered by intelligence and connected across devices.

.NET Development Improvements

With today’s announcement that .NET Standard 2.0 for UWP and XAML Standard will be coming later this year, .NET is now the most complete cross-platform development framework.  This combination, along with Visual Studio, makes it easier than ever before to write fully native and full-featured apps for all your target platforms in C#, including Windows, iOS, Android, Linux and, of course, the cloud!

.NET Standard 2.0 and XAML Standard

.NET Standard 2.0 is expanding the UWP surface by over 20,000 APIs to make sure your code is more interoperable than ever. We also know that about 70% of NuGet packages are API compatible with .NET Standard 2.0. Your most requested APIs for UWP, such as Reflection and SqlClient, will be fully accessible to you from the Windows 10 Fall Creators Update. In addition, XAML Standard allows you to keep much of your UI code common and still maintain a native look and feel across Windows, iOS, and Android. Your experience on Windows will automatically provide Fluent UI and all input interaction models for free.  Our goal is to unify our XAML dialects across UWP XAML and Xamarin Forms, making cross platform development easier than ever. We encourage you to give us direct feedback in the GitHub repo – http://aka.ms/xamlstandard.

Microsoft Graph and Creating Connected Experiences

We are connecting Windows to the Microsoft Graph, enabling amazing new Windows shell features such as Timeline, Cloud Clipboard, and Pick up Where I Left Off (PWILO). And you can use the same APIs to enhance your own applications too.

Devices in the Microsoft Graph

Using the Microsoft Graph API, you can now access your all of your users’ devices, enabling you to break down boundaries between devices. You can call apps and app services on each device, allowing for cross-device coordination of experiences.

Activities in the Microsoft Graph

Starting with the Windows Fall Creators Update, we are releasing the UserActivity APIs, enabling you to drive engagement in your apps, across devices and platforms. A UserActivity is the unit of user engagement in Windows, and consists of three components: a deep-link, visuals, and metadata. When a UserActivity session is created by an application, it accrues engagement records as users interact with the application.

You can download the ‘Project Rome’ SDK for Android and iOS over at GitHub.

Adaptive Cards

Activities in the Microsoft Graph provide a great way to store and track your activity across all your devices. Being able to visualize those activities is a critical part of the experience your customers will expect. Adaptive cards provide developers a visualization, using an open format, that works across multiple applications and experiences. The visualization for all the activities in the Timeline is provided by attaching an adaptive card to the activity using the Project Rome APIs. Adaptive cards are based on a JSON schema that enables app/content providers to have a rich visualization surface that can be represented in numerous experiences. The experience that hosts the card has control over exactly how the card is represented so that the card feels like a natural extension of the UI of the host app.

You can find all the latest info on adaptive cards at http://adaptivecards.io

Microsoft Fluent Design System

With the Fluent design system, we are taking a significant step forward in re-envisioning the way we develop the next generation of apps and experiences that translate seamlessly and naturally across devices. Our world is increasingly being driven by multiple devices – phones, tablets, PCs, game consoles, mixed reality headsets, etc. We don’t use just one device, we use many, and we’re constantly expressing ourselves by creating and consuming content across them. Each of these devices behaves differently and fulfills different needs. Some rely on touch and ink, some read our voices and gestures. It’s because of this world we live in today that Microsoft is making a big investment in our design system.

Fluent Design enables the creation of more expressive and engaging experiences that work continuously across devices—from large screens, to small screens, to no screen—all in a way that will drive higher engagement and love for your apps.  There are 5 fundamentals to Fluid design system – light, depth, motion, materials and scale. All of these join together in concert to give us the capabilities to build immersive, rich apps that scale continuously across the device ecosystem:

  • Light – Light helps enable the ability to draw someone’s attention, or more clearly guide them through their navigations
  • Depth – Depth helps us understand how things relate to each other when they’re within a more layered, physical environment
  • Motion – Motion is a powerful way to establish context and imply relationships between content in natural, subtle and delightful ways
  • Material – Material can help take full advantage of the available screen space to celebrate content. It can also bring a sense of lightweight, ephemeral user experience
  • Scale – Scale allows us expand our toolbox for more dimensions, inviting innovation across new device form factors

You can learn and get more familiar with Fluent at http://dev.windows.com/design.

Test, Deploy and Manage More Quickly

Testing and a secure deployment system is critical, so I’m particularly excited by Visual Studio Mobile Center, which allows you to have a CI/CD pipeline for UWP (in addition to iOS and Android) and integrates with our Store to make publication and distribution of your apps a breeze! We are also adding Windows devices to our test cloud, to enable developers to see how the app will look on the various devices and to help find issues before publishing.

Windows is the ultimate dev box

Our ambition is to make Windows the best dev box – for any dev, writing any app, targeting any platform.

Last year at build, I announced that bash was coming to Windows through the Windows Subsystem for Linux. We heard your feedback that deployment was a bit challenging, so we are streamlining deployment to come directly from the Windows store. In addition, we are working with Suse and Fedora Linux to enable multiple Linux distributions to run simultaneously. On top of these additional distros, there are loads of improvements under the hood, such as USB device communications support (e.g. deploy your Raspberry Pi bits via USB from Bash), USB drive mounting (for FAT32/exFAT/NTFS formatted USB drives), network share mounting, improved network configuration sync between Windows and Linux, and deeper syscalls to improve the breadth and depth of WSL’s compatibility with Linux apps.

In addition, there’s now the Xamarin Live Player which allows you to deploy, run, test and debug iOS apps directly from a Windows PC. Never before have you been able to build for so many platforms on one dev box!

Getting started now

Finally, I love seeing what our developer community can create, and the amazing experiences you are bringing to Windows. Just a couple of days ago I had the opportunity to celebrate with some of you our first windows developer awards:

Thank you, and I look forward to trying your applications soon.

Master the Master-Detail Pattern

In the world of information consumption in applications, it’s crucial to have a clear and easy way to navigate and inspect that information. The master-detail design pattern has become one of the most popular approaches in applications today. In this post, we’ll discuss what this is, determine if it’s appropriate for your application and show how you can use it!

What is a master-detail?

The answer to this will depend on what kind of information your application is trying to show, but at a high level, the “master” is an area in the UI where you have a list of something and the “detail” is the area that shows the relevant information of a selection in the master.

You can find a great example of the master-detail pattern in the Windows 10 email app, “Mail.”  The master is the list of emails and the details is the selected email.

The master-detail pattern is easy to understand and doesn’t need a lot of explanation to the user. When the user selects something in the master, they see the information and any actions relevant to that detail item. For example, selecting an email shows the body of the email as well as the buttons for: reply, reply-all and delete.

The pattern works well for these types of application scenarios:

  • You have a list where it makes sense to show details (e.g. list of contacts, products, etc.)
  • You have a large list that has items that need to be prioritized (e.g. RSS readers)
  • You need to switch between items frequently but want to stay in the same context (e.g. email)

Let’s use the Microsoft RSS Reader UWP example app to illustrate the master-detail pattern’s features.

If you want to follow along or see the code first-hand, find the RSS Sample’s source code here on GitHub.

Master-detail modes

The master-detail pattern works well on a wide range of device types and display sizes. However, you should consider how you want to use the pattern on different display sizes.

There are two popular modes that will help with this:

  • Side-by-side
  • Stacked

The determination between which approach to take comes down to how much horizontal room your app has. Here’s a table of typical effective pixels available per “size class” (if you’re not familiar with Effect Pixels (epx) see this one minute video).

Size class small medium large
Typical screen size (diagonal) 4″ to 6″ 7″ to 12″, or TVs 13″ and larger
Typical devices Phones Phablets, tablets, TVs PCs, laptops, Surface Hubs
Common window sizes in effective pixels 320×569, 360×640, 480×854 960×540, 1024×640 1366×768, 1920×1080
Window width breakpoints in effective pixels 640px or less 641px to 1007px 1008px or greater

Side by side

There many scenarios in which your application will have plenty of horizontal space to stretch.  The recommended guidelines for this mode is when your application has 720 epx or more available; this puts us in to the “Medium” and “Large” size classes seen above.

A few of these are:

  • Devices that let you size the app window larger (PC, HoloLens, Surface Hub)
  • Windows 10 Mobile running Continuum
  • Windows 10 Mobile (landscape orientation)

In the side-by-side approach, you can have both the master view and the detail view showing simultaneously. Using our RSS example, here’s the side-by-side approach:

Stacked

If your application is running in between 320 to 719 epx, you can’t comfortably fit the master and details next to each other, so we’ll need another way to display the master and detail.

A few examples of this scenario are:

  • Any device that lets you resize the app window (e.g. PC, HoloLens)
  • Windows 10 Mobile (portrait orientation)

For this case, you can use the stacked approach. In stacked, the master view gets the full screen space, then, when a selection is made, the detail view gets the full screen space.

With this approach, we’re “stacking” the pages in a single area and navigating between them. For example, the user selects an item in the master, the app will navigate to the Details View. When they want to see another item, they’ll navigate back to the master and select another item.

The stacked approach can be implemented with page navigation within a Frame element. In the diagram below, the “page control” you see is where the navigation occurs between the master view and the detail view.

Using our RSS sample app, here are a couple screenshots of the master and detail in stacked mode. Note that the app is running on a desktop PC, but with the window sized small, you’ll see the same appearance as it were on a mobile device. What matters is not the device, but the available screen space!

The “Breaking Point”

You’ll notice that we have this point where we need to change between the two different modes, depending on the current app width. For our master-detail, we’ve decided to do this at 720 epx. This means that once the application window gets resized to above or below 720 epx, we should be switching between side-by-side or stacked mode.

The Universal Windows Platform has a great feature to help with changing modes: the AdaptiveTrigger. Using an AdaptiveTrigger in your view’s VisualStates, you can adapt the UI when the application’s window size reaches that “breaking point.”  In the RSS sample, you can see how this is done on the MasterDetailPage.xaml.

First, let’s look at the master-detail layout; there’s a Frame element for the master content (ListView of feeds and articles) and a WebView for the detail content (the selected article). Notice the default width of the MasterColumn is set to 360.


    &lt;Grid.ColumnDefinitions&gt;
        &lt;ColumnDefinition x:Name=&quot;MasterColumn&quot;
                          Width=&quot;360&quot; /&gt;
        &lt;ColumnDefinition x:Name=&quot;DetailColumn&quot;
                          Width=&quot;*&quot; /&gt;
    &lt;/Grid.ColumnDefinitions&gt;

    &lt;Frame x:Name=&quot;MasterFrame&quot; /&gt;

    &lt;WebView x:Name=&quot;ArticleWebView&quot;
             Grid.Column=&quot;1&quot;
             Visibility=&quot;Collapsed&quot; /&gt;
&lt;/Grid&gt;

Now, let’s look at line 49 in the VisualStateGroups. You’ll see the VisualState named “NarrowState.” In this visual state, the MasterColumn.Width changes to * (star, which means “take all the available space”) and the DetailColumn.Width changes to 0.

Because the AdaptiveTrigger is set to 720, anything between 0 and 719 will use the NarrowState and anything 720 or larger will use the DefaultState.


&lt;VisualStateManager.VisualStateGroups&gt;
    &lt;VisualStateGroup&gt;
        &lt;VisualState x:Name=&quot;DefaultState&quot;&gt;
            &lt;VisualState.StateTriggers&gt;
                &lt;AdaptiveTrigger MinWindowWidth=&quot;720&quot; /&gt;
            &lt;/VisualState.StateTriggers&gt;
        &lt;/VisualState&gt;
        &lt;VisualState x:Name=&quot;NarrowState&quot;&gt;
            &lt;VisualState.StateTriggers&gt;
                &lt;AdaptiveTrigger MinWindowWidth=&quot;0&quot; /&gt;
            &lt;/VisualState.StateTriggers&gt;
            &lt;VisualState.Setters&gt;
                &lt;Setter Target=&quot;MasterColumn.Width&quot; Value=&quot;*&quot; /&gt;
                &lt;Setter Target=&quot;DetailColumn.Width&quot; Value=&quot;0&quot; /&gt;
            &lt;/VisualState.Setters&gt;
        &lt;/VisualState&gt;
    &lt;/VisualStateGroup&gt;
&lt;/VisualStateManager.VisualStateGroups&gt;

To see this in action, run the RSS reader example and resize the window from big to small and back. You’ll see the visual states change and switch between the side-by-side and stacked modes.

Additional Detail Functionality

In the beginning of this article, we briefly touched on how you can have context-aware functionality when using a master-detail. The example was having a “reply” button for an email app. However, you can go much further with it. Here are some more examples of functionality you can put into the detail view:

  • Product list: Order, track, add to wish list
  • Contact list detail options: Call, email, drive to
  • Inventory list detail: Reorder, mark damaged, ship

Another takeaway is that you can share the same controls (e.g. Buttons) for frequently used functionality and that functionality would intuitively be for that selected item in the detail view.

UWP Community Toolkit

If you’re building an application that could benefit from a master-detail implementation, you can skip a lot of the work by using the MasterDetailView control in the UWP Community Toolkit. With as little as a few lines of code and a couple DataTemplates (one for the master’s items and the one for the detail view), you can be up and running quickly.

Here’s the example from the UWP Community Toolkit demo app:


&lt;controls:MasterDetailsView
          ItemsSource=&quot;{Binding Items}&quot;
          ItemTemplate=&quot;{StaticResource ListTemplate}&quot;
          DetailsTemplate=&quot;{StaticResource DetailsTemplate}&quot;&gt;
&lt;/controls:MasterDetailsView&gt;

Resources

Windows Developer Awards: Honoring Windows Devs at Microsoft Build 2017

As we ramp up for Build, the Windows Dev team would like to thank you, the developer community, for all the amazing work you have done over the past 12 months. Because of your efforts and feedback, we’ve managed to add countless new features to the Universal Windows Platform and the Windows Store in an ongoing effort to constantly improve. And thanks to your input on the Windows Developer Platform Backlog, you have helped us to prioritize new UWP features.

In recognition of all you have done, this year’s Build conference in Seattle will feature the first-ever Windows Developers Awards given to community developers who have built exciting UWP apps in the last year and published them in the Windows Store. The awards are being given out in four main categories:

  • App Creator of the Year – This award recognizes an app leveraging the latest Windows 10 capabilities. Some developers are pioneers, the first to explore and integrate the latest features in Windows 10 releases. This award honors those who made use of features like Ink, Dial, Cortana, and other features in creative ways.
  • Game Creator of the Year – This award recognizes a game by a first-time publisher in Windows Store. Windows is the best gaming platform–and it’s easy to see why. From Xbox to PCs to mixed reality, developers are creating the next generation of gaming experiences. This award recognizes developers who went above and beyond to publish innovative, engaging and magical games to the Windows Store over the last year.
  • Reality Mixer of the Year – This award recognizes the app demonstrating a unique mixed reality experience. Windows Mixed Reality lets developers create experiences that transcend the traditional view of reality. This award celebrates those who choose to mix their own view of the world by blending digital and real-world content in creative ways.
  • Core Maker of the Year – This award recognizes a maker project powered by Windows. Some devs talk about the cool stuff they could build–others just do it. This award applauds those who go beyond the traditional software interface to integrate Windows in drones, PIs, gardens, and robots to get stuff done.

In addition to these, a Ninja Cat of the Year award will be given as special recognition. Selected by the Windows team at Microsoft, this award celebrates the developer or experience that we believe most reflects what Windows is all about, empowering people of action to do great things.

Here’s what we want from you: we need the developer community to help us by voting for the winners of these four awards on the awards site so take a look and tell us who you think has created the most compelling apps. Once you’ve voted, check back anytime to see how your favorites are doing. Voting will end on 4/27, so get your Ninja votes in quickly.

Just released – Windows developer evaluation virtual machines – April 2017 build

We’re releasing the April 2017 edition of our evaluation Windows developer virtual machines (VM) on Windows Dev Center. The VMs come in Hyper-V, Parallels, VirtualBox and VMWare flavors. The evaluation version will expire on 07/07/17.

Evaluation VM contain:

If you want a non-evaluation version of the VM, we have those as well. They do require a Windows 10 Pro license, which you can get from the Microsoft Store.

If you have feedback on the VMs, please provide it over at the Windows Developer Feedback UserVoice site.

Now available: Windows Developer training course on Desktop Bridge

We are happy to announce that the Microsoft Virtual Academy training course, Developer’s Guide to the Desktop Bridge, is now available on demand.

This video course, delivered by the Desktop Bridge Program Management team, aims to help developers understand the concepts and benefits of the Desktop Bridge tooling in the Windows 10 Universal Windows Platform. Watch the video and find the relevant sample code here to start bringing your desktop apps to the Windows Store and to take advantage of new Windows 10 features of the Universal Windows Platform in your WPF, WinForms, MFC or other type of Win32 apps.

Do you want to distribute your desktop application in the Windows Store? We cover that in the course. Do you want to take advantage of modern Windows 10 app-to-app features in your existing desktop application? We cover that in the course. Do you want to light-up Windows 10 features, and still distribute your app to Windows 7 users? We cover that, too. Modernizing your desktop app gradually with UWP components? We cover all of these and more in the course.

There are eight modules:

  1. Intro to the Desktop Bridge
  2. Desktop App Converter
  3. Debugging and Testing Your Converted Apps
  4. Distributing Your Converted Apps
  5. Enhancing Desktop Applications with UWP Features
  6. Extending and Modernizing with UWP components
  7. What’s Next for the Desktop Bridge
  8. Post-Course Survey

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

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

Feedback or feature suggestions? Submit them on User Voice.