前言
这篇博文是关于评价 XAML Controls 部分组件的呈现效果的，在写下这篇文字之前，我分别在 Windows 10 和 Windows Phone 10 上体验了 XAML Controls 应用，以求对XAML有一个尽可能全面的认识。
使用Windows Phone 10来进行体验，一定程度上让我对某些组件的设计有了更深的认识，让体验的结果显得不是那么片面，我会在后面的部分详细探讨这个问题。
由于小方编程功力尚且不足，一些看法在内行眼里可能显得有些幼稚，如果不正确之处还望大家海涵。
体验
FlipView
FlipView 在 Android 上也有相似的实现，名字称为 ViewPager ，功能都是在固定区域进行翻页操作。
但是从示例上看，FlipView的翻页动画过于单一，可以放置什么组件也没有被提及，所以无法确定FlipView是否达到和ViewPager的同等水平的程度，于是我使用了老师提供的 超便捷uwp开发助手 快速进入了FlipView的说明文档。
FlipView属性
从这个FlipView的不同属性，我们就可以分析出，FlipView存在的目的就是把图片显示出来，这和ViewPager相比“格局”就小了很多，我们几乎可以以ViewPager为底层任意扩展，从电子书阅读器到广告展示任何滑动内容的场景都可以使用ViewPager。
由此我们看出FlipView的不足，同样的组件在Android中只能是第三方开发者的作品，不知为何在uwp中却作为官方的组件被提出。
Flyout
Flyout 同样可以在Androd上找到类似功能的组件进行对比参考——SnackBar 和 Toast
在安卓上使用Toast显示一条通知
1
Toast.makeText(this, "This is a Toast", Toast.LENGTH_SHORT).show();
或者使用SnackBar显示一个带按钮的通知
1
2
3
4
5
6
Snackbar.make(context, "This is a Snackbar", Snackbar.LENGTH_SHORT)
.setAction("Cancel", (v)->{
})
})
.show();
通过这两个Android组件，Fluout的功能已经基本实现，但是我注意到，Flyout的代码是写在界面布局上的，它的代码长这样：
1
2
3
4
5
6
7
8
9
10
<Button Content="Empty cart">
<Button.Flyout>
<Flyout>
<StackPanel>
<TextBlock Style="{ThemeResource BaseTextBlockStyle}" Text="All items will be removed. Do you want to continue?" Margin="0,0,0,12" />
<Button Click="DeleteConfirmation_Click" Content="Yes, empty my cart" />
</StackPanel>
</Flyout>
</Button.Flyout>
</Button>
代码阅读性不佳的问题暂且不提，我在想：让做界面的开发者去决定哪里显示一个提示听起来似乎是一个好主意，但它真的那么完美吗？
将提示绑定在界面上的一大问题就是，很多后台应用没有办法显性的告诉用户发生了什么，只是显示内容貌似还可以使用系统通知来解决，如果涉及到了确认取消操作，貌似系统通知能做的就很有限了。
另一个问题是，Flyout的可扩展性不强，为了保证UWP开发设计的一致性，Flyout没有办法进行太多的扩展，它依赖于其他组件而存在的本质是不会改变的，这从一定角度上限制了开发者的自由。
安卓Toast的扩展
hub
1
2
3
4
5
6
7
<Hub .../>
-or-
<Hub ...>
oneOrMoreComponents
</Hub>
从演示效果上看，ScrollViewer与hub有着相似的功能，把一组内容连续显示出来。
但正是这个地方让我们可以一起批评这两个组件，相似的功能真的需要两个组件吗？反观Android中的ViewPager，它将翻页抽象出来，开发者不必考虑使用什么组件来实现功能，只需要实现其中的翻页类就可以。
Android官方的ViewPager翻页动画类示例
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
public class DepthPageTransformer implements ViewPager.PageTransformer {
private static final float MIN_SCALE = 0.75f;
public void transformPage(View view, float position) {
Log.d("DepthPageTransformer", view.getTag() + " , " + position + "");
int pageWidth = view.getWidth();
if (position < -1) { // [-Infinity,-1)
// This page is way off-screen to the left.
view.setAlpha(0);
} else if (position <= 0) { // [-1,0]
// Use the default slide transition when moving to the left page
view.setAlpha(1);
view.setTranslationX(0);
view.setScaleX(1);
view.setScaleY(1);
} else if (position <= 1) { // (0,1]
// Fade the page out.
view.setAlpha(1 - position);
// Counteract the default slide transition
view.setTranslationX(pageWidth * -position);
// Scale the page down (between MIN_SCALE and 1)
float scaleFactor = MIN_SCALE
+ (1 - MIN_SCALE) * (1 - Math.abs(position));
view.setScaleX(scaleFactor);
view.setScaleY(scaleFactor);
} else { // (1,+Infinity]
// This page is way off-screen to the right.
view.setAlpha(0);
}
}
}
mediaPlayer
在不同设备上使用 mediaPlayer 让我有了不同的想法。 首先，我在PC上试用播放控制器，让我感觉困惑的是，这个控制器是不能被任意放置的，在我们一般使用的应用中，播放控制器都是可以随意拖放的。
可以随意拖放的控制器
在一般印象中，手机上的媒体控制器是不能被拖放位置的，于是我又尝试了一下 Windows Phone 10 上的mediaPlayer，这一次使用体验变得很好，一些比如快速跳转、投屏等功能还是很完善的。
Windows Phone 10 播放器
由此我们可以看出，想要评价UWP，就不能脱离多平台。我想之所以在pc端没有实现拖动处理，一方面是为了保证uwp平台设计的一致性，另一方面也给编程实现减小了压力，是多种因素共同影响的结果。
richeditBox
1
<RichEditBox x:Name="editor" Height="200"/>
我们使用很短的代码就可以在uwp应用中添加一个富文本编辑器，减少了第三方开发者的开发难度，但是从另一方面看，这个富文本编辑器真的是太简单了，如果说简简单单的几个按钮是给人以侘寂的美感，但是于细节处的缺失就成了一个败笔。
侘寂美感的富文本编辑器
我们可以尝试输入一串加粗的字符，然后用鼠标选择几个字符，这时候一般的富文本编辑器会高亮加粗按钮来显示当前文字应用了加粗效果，而这个富含“侘寂”美感的富文本编辑器，并没有任何提示，这在有些场景会给用户带来一些小障碍。
如此富含美感的编辑器在细节处有着不小的缺失可以说是一种遗憾。
结语
经过了这次 XAML Controls 的试用，我对微软UWP应用的设计风格有了更深的认识（虽然还是更喜欢苹果家的设计），尤其是看到微软在最近一次更新中增加的磨砂效果，心中还是认为微软的审美更近了一层楼。
如果有机会，希望可以对上述组件中存在的不足之处仔细研究，争取做一版用户更友好的组件系统。
