UWP? UWP !, Uwp

UWP? UWP !, Uwp
UWP? UWP! -What about Build 2015?

Build 2015 ended successfully. I wonder how many of you watched the live video during the night? In any case, you may be curious about what amazing news Microsoft has published at this Microsoft developer feast. I have sorted out some UWP-related content, but it is not comprehensive. I hope readers can correct me more.

(The images involved in this article are all from Build)

4. New Features of UWP development framework

As a brand new application type, UWP naturally has a brand new development framework. In C # + XAML, The UAP development mode is basically maintained, but many features are added. Here is a simple example.

New universal control

In UWP, since there is no platform difference, almost all controls become cross-platform controls, rather than the use restrictions of different platforms in UAP. Some of the new controls worth noting are:

• Remark: Yes, it is the familiar remark that can be used on all platforms now. The difference is that the behavior and display methods are slightly different in the big screen environment.
  
  
• AutoSuggestBox: a search box with auto-completion function, which replaces the traditional SearchBox.
• UniversalMaps: a cross-platform map control. You no longer need to design different Map Display logics for positioning applications on different platforms.
• SplitView: provides a scalable navigation bar for navigating the pages in containers. As a brand new control, it has extremely high page adaptability, the self-adaptation technology described below allows you to easily adapt to complex pages.
  
• InkCanvas: New encapsulated controls to support User Notes. There are still many application scenarios, which can save the developer's effort in these cases. After all, it is not easy to implement a user-friendly image version.

Auto-adaption assistance

Since UWP will face complicated and changing application resolutions, the days of designing pages for some fixed resolutions will never go forever. In this regard, UWP is closer to webpage design. But for html, We have relative and stream layout. For XAML, we cannot always implement self-adaptation in the csharp code, right? Don't worry. XAML is enough to do most of the work. See:

VisualStateManager

This is an element of XAML. Its function is simply to manage the attributes of each element on the page under different conditions and its transition mode during switchover. Let's take a look at the following code:

<VisualStateGroup x:Name="WindowSizeStates">    <VisualState x:Name="WideState">        <VisualState.Setters>            <Setter Target="splitView.DisplayMode" Value="Inline" />        </VisualState.Setters>        <VisualState.StateTriggers>            <AdaptiveTrigger MinWindowWidth="720" />        </VisualState.StateTriggers>    </VisualState>    <VisualState x:Name="NarrowState">        <VisualState.Setters>            <Setter Target="splitView.DisplayMode" Value="Overlay" />        </VisualState.Setters>        <VisualState.StateTriggers>            <AdaptiveTrigger MinWindowWidth="0" />        </VisualState.StateTriggers>    </VisualState></VisualStateGroup>

The purpose of the above Code is to adjust the splitView. DisplayMode attribute to inline when the page width is greater than 720; otherwise, Overlay is used. Its syntax and rules are quite simple. You only need to define the corresponding Trigger and Setter in different visualstates. You can also define the switching animation between different States if necessary.

It is worth noting that the Trigger is not as simple as the Trigger specified by the Framework. It can be customized. Let's look at the example below:

public class InputTypeTrigger : StateTriggerBase{        private FrameworkElement _targetElement;        private PointerDeviceType _lastPointerType, _triggerPointerType;        public FrameworkElement TargetElement        {            get { return _targetElement; }            set            {                _targetElement = value;                _targetElement.AddHandler(FrameworkElement.PointerPressedEvent, new PointerEventHandler(_targetElement_PointerPressed), true);            }        }        public PointerDeviceType PointerType        {            get { return _triggerPointerType; }            set { _triggerPointerType = value; }        }        private void _targetElement_PointerPressed(object sender, PointerRoutedEventArgs e)        {            _lastPointerType = e.Pointer.PointerDeviceType;            SetActive(_triggerPointerType == _lastPointerType);        } }

The Custom Trigger is used to determine that the type of an element is mouse/finger, and Trigger when the condition is met. Let's take a look at its usage in XAML:

<VisualStateGroup x:Name="InputTypeStates">    <VisualState>        <VisualState.StateTriggers>            <triggers:InputTypeTrigger TargetElement="{x:Bind ActivityList}" PointerType="Touch" />            <triggers:InputTypeTrigger TargetElement="{x:Bind ActivityList}" PointerType="Pen" />        </VisualState.StateTriggers>        <VisualState.Setters>            <Setter Target="GoToTopButton.Visibility" Value="Visible" />        </VisualState.Setters>    </VisualState></VisualStateGroup>

If you are skilled, it can play an exceptionally powerful role.

RelativePanel

Some readers may wonder: even if there is a powerful and customizable Trigger, isn't all I can do is customize some attributes? If I want to adjust the position and size according to the actual situation, what should I do, or can I only resort to code? Of course not: RelativePanel will provide what you want:
Have you ever thought about the html stream layout? Have you considered the implementation of css attributes such as float in xaml? RelativePanel is the container that supports them. Please refer to the following code: (omitting the properties special to this control)

<RelativePanel>    <Image x:Name="img" …/>    <TextBlock x:Name="title" RelativePanel.RightOf="img" RelativePanel.AlignTopWith="img" …/>    <TextBlock x:Name="authors" RelativePanel.RightOf="img" RelativePanel.Below="title" …/>    <TextBlock x:Name="summary" RelativePanel.RightOf="img" RelativePanel.Below="authors" …/>    <Button Content="Download" RelativePanel.RightOf="img" RelativePanel.AlignBottomWithPanel="True" …/></RelativePanel>

The actual results are as follows:

Have you seen any attribute similar to Rightof/below? This relative layout method is the essence of RelativePanel, which enables zero code to adapt to pages, web page designers who are proficient in stream layout can simply use them to adapt their pages to webpages. Of course, in combination with the attribute settings of VisualState, they can bring extremely flexible page behavior, enough to meet most page layout requirements, and only a few of the relatively customized page behavior needs to write code.

Controls that have been adapted to the device

Controls that are commonly used by everyone have different effects when running on different devices. They are specially designed by Microsoft to adapt to different control types and screen sizes. In this regard, you can save a lot of effort on page designers. For example:

• The MenuFlyout control does not have the same menu spacing when the mouse is triggered or when the finger is triggered, so as to provide the best user experience for the two control methods.
• The positions of the selected labels on screens of different sizes are different to facilitate single-handed touch.

New binding method: Binding during compilation

The new XAML provides a different binding method: compile-time binding ({x: bind }). The binding relationship will be checked during compilation, and only data dependency between them exists during runtime. For this reason, the efficiency of such binding during runtime has been greatly improved. From the data displayed by Build, the binding efficiency, attribute modification response efficiency, and resource savings have all been improved several times.

<DataTemplate x:DataType="model:FileItem">　　<Grid Width="200" Height="80">　　　　<TextBlock Text="{x:Bind DisplayName}" />　　　　<TextBlock Text="{x:Bind prettyDate}" />　　</Grid></DataTemplate>

Although binding at compilation has the disadvantages of no dynamic modification at runtime and no style binding, its efficiency indicates that this will be the development direction of the data binding mode in the future. Wait and see ~

Improved interface response speed

How can we adapt to various varied deployment platforms if the UWP is to be implemented and the efficiency is insufficient? Microsoft is also painstaking in this regard, greatly improving its operation efficiency and stability, in order to use UWP to replace the traditional pe file as the main force of Microsoft products. You can see the UWP-style Office in the Build display. It can be seen that the Office and even VS in the future may be the things in the UWP bag. So what exactly are the changes?

• The inertia loading feature of XAML elements: I'm sure you have heard of some concepts of inertia evaluation in functional programming languages. This concept is transplanted to interface rendering. Inert loading can ensure faster program start time and user response speed under normal circumstances.
• Improved text rendering efficiency: UWP improved text rendering efficiency by 50%
• Binding acceleration: As mentioned above, it is not described here.
• The new Visual Layer access API allows developers to touch some lower-Layer rendering mechanisms to achieve higher efficiency in animation, transformation, and other operations.

5. Can it be more powerful?

For more information about Build, visit
Http://channel9.msdn.com/events/build/2015? Media = true & wt. mc_id = build_hp
View more videos and ppt presentations.