由于新一波react-native制作的app开始开发，因此也开始继续深入的从native角度了解和使用React-Native。编写Native Modules已经是用得轻车熟路了，随着版本更新这方面的改动也不是很大并不是什么问题，而编写Native UI Components随着多端ui控件统一和业务上需要一些定制性较高针对性较高的界面元素，提上了日程。因此，在实际业务编写中便携多个Native UI Components并有一些关键的问题，记录以下。

之前制作TabCalendar的过程中，在下拉部分的事件处理感觉还是写得比较稚嫩，因此自我感觉还需要再练练手。因此这次选择下拉刷新组件开刀，原因有3点：
1.在业务使用中有需求，实际app中很少有使用android自带下拉刷新的，都是仿iOS的重置版本，因此我们也需要一个。
2.虽然只是一个简单的交互，但能够在他上面耍的花样很多，值得抽象整理一次。
3.其涉及到双层滚动等各种触控问题，值得整理一次。

嗯，因此这次抽象了SwipeRefreshAbs作为基础抽象，并尝试了多个交互设计的实现。下面挑重点的记录。

在面向b端的app制作过程中，我们经常遇到以日期为单位进行交互和数据展示的展示性界面。大概是由于b端app多是密集的数据展示性质的，而一般的业务数据最常见的展示方式就是以天或者周为单位进行展示。因此我们曾经多次遇到，以日期为TabLayout的单位制作TabLayout+ViewPager的标准界面。然而，用TabLayout来呈现日期，其实有很大的缺陷的。

1.首先，仅仅把天罗列在一起，无法呈现出周的意味，需要添加多余的文字来描述星期信息。

2.另外由于TabLayout是单纯的横向滑动切换的，导致进行跨较长的日期进行查看的时侯操作异常困难。

3.同时，若在一旁添加点击展开日历控件进行选择，虽然可以解决问题，却会导致界面交互繁琐不具有连贯性。
因此，参考各方交互设计，实现了将TabLayout和Calendar组合在一起的控件：TabCalendar。如下是交互浏览视频：

如果说在使用RecyclerView的过程中，我们偶尔还能提到ItemDecoration，那么ItemAnimator这张东西估计是写一百个列表都不会提一次，有些人一辈子都没动过了。初学RecyclerView都会稍微提到一下ItemAnimator，它是做RecyclerView的item增删改动画的工作，是RecyclerView一对一的标配，拥有默认实现DefaultItemAnimator而且效果还不错（真的效果还不错）。那么，如果DefaultItemAnimator可以满足我们的业务需求，我们在其之上，还需要做些什么呢？

深究

ItemDecoration是我们在使用RecyclerView的时候常常会提到的，惟一的可插拔的样式性的拓展。我们一般经常会下载一些现成的ItemDecoration来完成一些特定的功能，比如官方提供的DividerItemDecoration来实现RecyclerView的分割线，第三方的PinnedItemDecoration来完成item吸顶效果。

深究

通过类名我们就可以知道，使用它可以为item进行样式上的装饰，这么宽泛的概念，我们到底怎么使用它，或者说它究竟本设计出来做什么的比较好呢？
  

在上文中我们已经将RecyclerView拆分称为了数个基本结构，其中仔细观察的话，最重要且最复杂的部分就是dataSource和adapter的相互结耦和交互了。而这两个元素拆分来看，dataSource已经是功能完善的现成的对象了，可以取来直接使用，而adapter则需要复杂的绑定操作才能完成配置。因此，我们首要要进行封装的说简单点就是一个adapterBuilder了。

最近花费了两周的时间对RecyclerView进行了再解耦和结耦封装，以达到以更优雅的方式满足业务需求，并且能方便的应用到之后的业务中去。最终目标是对于不复杂的列表，可以在数行代码内搞定列表配置与数据绑定；对于较为复杂的列表，可以以非常清晰的代码完成工作。

在做比较复杂的界面交互的时候，不可避免的会遇到用户手势识别和处理。最简单的触控事件处理当然是对touch事件获得的MotionEvent对象进行记录与分析即可。当然，这种较为原始的方法并不适合复杂的交互处理，应该安卓sdk也提供了比较高级的手势（Gesture）处理机制。

1.GestureDetector

GestureDetector是最方便的处理手势的方式，创建它的时候需要实现一个listener，这是GestureDetector的核心处理接口。这个listener有两种，一种是：

最近前端在对业务基础框架进行整理，在reactNative部分，我们发现非常常用且需要native支持的基础组件需求还是不少，而且大部分都急需解决跨平台的兼容性问题。从基础组件拆分的角度来将，当然我们的目标是将它们中与业务逻辑不相关的部分，完全node方式模块化，以第三方库的方式引入。经过对实际业务中使用reactNative的项目进行分析和抽象，我大概规划了一下需要单独抽出的库：
1.界面：toast与弹窗（在js层难以实现或易出bug），地图（功能复杂，代议）
2.功能：系统常量（js可用的环境变量），消息与通知，定位

反射是在初学java的过程中反复提及的概念与操作方式。浅显的理解反射的话，它是一组api，让你可以在程序运行时了解并获得程序内部结构，就像镜子一样，在镜子中看到程序自己本身。然后，动态的对程序本身进行修改与操作。当然，这种看起来另辟蹊径的程序运行方式一般来说并不推荐，适用场景往往出现在需要动态注入代码，调用非可见属性方法等需要高灵活性的使用场景中。那么在oc中，是否也有类似的功能呢？有过之而无不及，oc的runtime库就可以完全做到这些东西。