Featured in Architecture & Design

Monal Daxini presents a blueprint for streaming data architectures and a review of desirable features of a streaming engine. He also talks about streaming application patterns and anti-patterns, and use cases and concrete examples using Apache Flink.

Featured in AI, ML & Data Engineering

Joy Gao talks about how database streaming is essential to WePay's infrastructure and the many functions that database streaming serves. She provides information on how the database streaming infrastructure was created & managed so that others can leverage their work to develop their own database streaming solutions. She goes over challenges faced with streaming peer-to-peer distributed databases.

Compile Time Bindings in Universal XAML

The headliner for this presentation is the available of common controls including the much missed date/time picker. Previously one would have to create custom controls and then manually swap them out depending on the platform. The promise with this version of Universal XAML is the controls will always work and look correctly by default, even on XBox or Raspberry Pi 2.

Part of the process is the normalization of behavior across devices. For example, password boxes have an optional way to show the password that differs in Windows desktop and phone. Under the new model, they default to the same behavior with an optional property to switch back to the previous behavior.

Controls that were only available on one platform are being extended to all platforms in Windows 10. The Pivot control is now available on desktop applications. In that environment, it looks more like a tabbed experience with full support for touch, keyboard, and mouse based input.

With dramatically different screen sizes, one still needs to tailor the application to different platform. A common example of this is how desktop applications often show a master and detail view side by side while phones would only show one or other. New controls like Spilt View will automatically handle this by changing behavior based on available screen size.

For custom work, the Visual State Manager for Universal XAML has been extended to support what’s called an “Adaptive Trigger”. This trigger understands the applications states and fires when changes are made to properties as current screen size. This isn’t just tied to the platform, which means if you shrink a desktop application window to the size of a phone app, the visualizations will automatically switch to phone mode. This creates a surprisingly pleasant experience without resorting to the Windows 8, always full-screen design pattern.

For you web developers, Microsoft describes adaptive triggers as a “really powerful version of media queries”. Details are not available yet, but developers will even be able to create their own adaptive triggers.

Another control that Microsoft is working on for responsive UIs is the “Relative Panel”. This panel automatically lays out all of its controls relative to other controls in the same panel. The specific relationships are defined by referencing the names of controls in extension methods such as RelativePanel.Below="title".

Fulfilling the Vision of WPF and Windows 6

Before it was abandoned and replaced by Windows Vista, there was the Windows 6 project. Part of this project was to replace the Win32 based OS applications with WPF based alternatives. Unfortunately the performance wasn’t adequate and the plan was shelved.

Shelved, but not forgotten. With Windows 10 and Universal XAML, Microsoft is once again trying to achieve a consistent experience across all applications regardless of who created them. Everything that the Windows 10 UI does for OS applications is supposed to be available to application developers as well. And since Universal XAML is always running, Microsoft has been highly focused on performance and memory consumption across the board. Work on this has resulted in features such as better bindings.

Compile Time Bindings

Bindings in XAML are reflection based and thus quite slow. Because of this, Microsoft considered dropping support for bindings entirely. However, even Microsoft’s own internal teams refused to follow this guidance; bindings are just too useful to ignore.

Since they were unable to kill the feature, they instead decided to add a compiled bindings feature. If you use the {x:bind} markup extension instead of {binding}, the bindings will be resolved at compile time. This means that that is isn’t only faster at runtime, any typos will be caught before the application is run. In order to make this work, you also need to indicate the data type for the data context using x:DataType.