[Flutter Package]类iOS使用方法的SectionTableView

此控件的package我已经托管到了 pub仓库

十余年的缙云网站建设经验，针对设计、前端、开发、售后、文案、推广等六对一服务，响应快，48小时及时工作处理。营销型网站建设的优势是能够根据用户设备显示端的尺寸不同，自动调整缙云建站的显示方式，使网站能够适用不同显示终端，在浏览器中调整网站的宽度，无论在任何一种浏览器上浏览网站，都能展现优雅布局与设计，从而大程度地提升浏览体验。创新互联建站从事“缙云网站设计”,“缙云网站推广”以来，每个客户项目都认真落实执行。

如果你被墙住了，也可以看 国内镜像

使用方式就是在你的flutter pubspec.yaml中添加依赖：

然后flutter packages get更新依赖即可

最近写demo时发现Flutter自带的ListView widget很简陋，没有分隔线，没有section/row之分，也没有sectionHeader，如果要实现一个有分割线，有section区分，有section header的ListView，耦合会非常严重：

在 上没有找到封装好的这种TableView，于是乎决定自己写一个，命名为SectionTableView

本人是iOS开发，所以习惯了iOS上的UITableView的调用风格，所以在实现flutter的SectionTableView时，决定实现如下功能

为了实现这些功能，并且方便后期增加滚动功能，上下拉刷新功能，使用了StatefulWidget作为父类：

接着在对应的_SectionTableViewState中的build方法中，返回ListView：

熟悉flutter ListView的同学知道，ListView的builder类方法，有一个itemBuilder回调函数，参数是当前的上下文，和将要渲染的行索引index，index对应想要获取的某一行控件(cell或者叫ListItem)，返回非空的组件就证明这个index有值，返回null就表示列表到尽头了。

我们需要做的就是对index进行映射，判断当前index对应的控件，应该是列表里的section header，还是分隔线devider，还是某一行的真正内容cell。

出于性能的考虑，不可能每次调用 _buildCell的时候，都计算一遍index对应的section和row的位置，所以定义了一个类成员变量indexPathSearch，是数组，数组长度就是ListView所有的行，当 _buildCell 的参数index大于等于indexPathSearch的长度的时候，就返回null，表示列表内容到此为止了。

indexPathSearch里每一个元素，就是index对应的section和row（称为indexPath），index指向实际行(cell)的时候，section和row都是大于等于0的，当section大于等于0，row==-1的时候，表示这里是一个section header，当两者都等于-1的时候，表示这里是一个分割线：

计算好了index到indexPath的映射，剩下的就好说了，在_buildCell中，提取indexPath并判断indexPath的内容，返回对应的控件：

这是我的第一个flutter package，目前还很简陋，flutter目前尚且如此，所以大家一起改善它，

下一步将优化如下内容：

如果大家喜欢，请多多star我的 项目GitHub

flutter Dart语言List如何获取索引值

其他语言像是js，提供的迭代器是可以直接获取element，index的，但是用dart的map()发现无法获取下标，实际上dart的迭代器只支持获取element自身，想要获得index，就需要借助asMap()，Dart提供的asMap()将列表转换为Map。

Dart提供了List.generate方法获取index

Flutter 城市列表AzListView 索引&悬停

AzListView，Flutter 城市列表，联系人列表，自定义Header，索引，悬停效果。

flutter Set集合妙用

Set是不能重复的集合，所以可以用Set去重；

String、int、double类型示例，如下：

String类型：

int类型：

double类型：

可以看到， Set集合可直接对String、int、double类型去重 ；

Map、List、bool类型和String、int、double类型对比示例，如下：

可以看到，当自定义对象实例化为同一个对象时，Set会过滤掉同一个实例化的对象；当自定义对象实例化为不同对象时，Set不会去重，即使对象数据内容一样，这不符合我们的业务；

可以看到，重写自定义对象==方法，Set还是不能去重；

上面重写自定义对象hashCode和==方法，以title不同区分不同对象；

可以看到，重写自定义对象hashCode和==方法，Set集合对自定义对象去重才有效；并且Set集合里有相同对象时(相同对象为上面自定义对象title值相同的对象)，后面相同的对象就不会被加入Set集合里了( 如上面title一样，boolValue不一样，这样被认为相同的对象，因为重写自定义对象hashCode和==方法，以title不同区分不同对象；Set集合里最开始加入的TestModel('a', boolValue: false)，数据不会被相同对象TestModel('a', boolValue: true)覆盖 )。

网上介绍flutter Set集合时一般会介绍Set没有顺序，这点不太理解，可能是不能通过索引来获取对应的值吧，像Java语言的Set集合确实是无序的，但flutter的Set集合保持着子元素的有序性。 如下：

可以看到，将Set通过toList()方法转为List后，List里子元素的顺序和子元素插入Set集合的顺序是一致；对于自定义对象亦是如此，可自行验证。

为什么Set集合会保持子元素插入顺序呢

我们看下Set源码，如下：

从源码我们可知，Set()是一个工厂构造方法，根据工厂构造方法的特点，Set是由LinkedHashSet实例化的。

从上面注释可知，HashSet是无序的，LinkedHashSet保持着子元素插入的顺序。而Set是由LinkedHashSet实例化的,所以Set保持着子元素插入的顺序。

如想要深入分析LinkedHashSet，LinkedHashSet源码中有很多external声明的方法，可参考 如何找到flutter external声明方法的实现

demo传送门

flutter源码系列 PageView源码分析以及监听事件

最近一个项目要实现可以无限循环的PageView，主要思路是在初始化pageview的list的时候在开始和结尾多加一个结尾和开头的widget，当滑动到开头和结尾的时候手动进行页面的切换，详细可以搜索pageview无限轮播。

这种方法有一个要点就是要维护两个索引，一个是内部list的索引，一个是外部显示的索引，由于list的容量是比显示的数量多2的，所以如果要在外部进行一些比如指示器或者计时器功能要进行和页面同步显示或者切换页面操作时，需要将显示的索引转换成list的索引。

不过网上说的都是一些比较简单的实现，看到比较多的就是当滑动到要手动切换的时候进行一个时延，这样可以避免直接切换页面造成的卡顿和跳动现象。但是存在一个问题，如果要同时实现一个跟随页面切换的指示器，就会出现当页面切换过去之后指示器才会跟着过去，因为页面切换的时候执行了时延，而时延之后才会真正改变索引，此时才会setstate，之后指示器才能响应到索引的切换，但是如果在时延之前就切换的话又会出现指示器先行的情况。因此这种方法其实是存在一些问题的。

所以解决这个问题的关键在于如何进行页面切换的判断。这里可以有两种思路实现，第一种是实现viewpage的onpagechanged方法，在里面进行逻辑的判断，然后用controller来进行页面跳转，不过这种方法存在当controller跳转的时候又会回调onpagechanged，所以就会出现多次对索引不必要操作，而且如果有比如计时器等额外的功能的话可能不方便将页面逻辑分开，而且依旧无法解决指示器延迟问题，同时也很难进行细粒度的操作。

第二种方法我们就要去看pageview的源码了，从源码的角度来解决问题才是正确的方法。首先我们点进去pageview的源码

看到这里其实已经有一些思路了，我们之前难点在于重写了onpagechanged方法导致问题无法很好的解决，现在我们找到了onpagechanged调用的地方，只要找办法避免掉就可以实现了。

当然这里我们要说到NotificationListener，以及flutter对应的冒泡事件传输机制，这里大家可以去看看这篇 文章 。

我来总结一下，其实就是flutter对于notification这个组件，有一中事件规则叫冒泡传递，底层的notification如果在它的 onNotification写的逻辑中返回是false以及它不是根结点，就会去向上遍历寻找它的祖先notification组件，知道遇到root节点或者某一个返回true，则事件传递结束。

而且在onNotification中可以对多种事件进行监听和处理，所以我们可以把对viewpage页面跳转对索引处理的逻辑写在这里，而且我们可以分别处理比如滑动开始的start事件和结束的end事件，分别进行细粒度的逻辑的处理，这样就可以在外部进行操作和别的功能实现了。

因此不仅无限轮播事件可以通过这种方法来解决，如果有其他的操作也可以这样进行处理，而且因为我们没有传入onpagechanged方法，所以不存在多次调用的问题，pageview那里判断onpagechanged是null方法就不会进去了，会直接我们写在pageview外面的notification的逻辑。

最后的结构大概这样