公司 app 开发时需要实现邮件详情页预览功能，看似一个小的功能却包含了许多细节。
为什么呢？
- 在选中邮件列表中的某一封邮件时，预览选中的邮件；
- 在非搜索状态/重要文件夹中 删除/移动 邮件时，预览删除或移动的下一封邮件（多选情况下预览最后一封选中邮件的下一封邮件，如果存在的话；否则不预览）；
- 在搜索/重要文件夹中，逻辑删除 或 移动 仅更新邮件所在的文件夹，故当前预览内容不变；若该封邮件被物理删除，则预览该封邮件的下一封。
邮件预览的详情页内容时需要获得具体的邮件信息--> 我们代码中是定位某一封邮件是根据邮件当前所处的 Group【按照“最近一天”、“最近一周”，“最近一个月”，“longlongago” 分成了不同的 group】 和 邮件在当前 Group 的 index 来定位的。
在需要预览下一封邮件时就涉及到 Group 和 Index 的一个计算，看是否有下一封邮件可预览。由于只有在删除/移动成功后才需要进行预览更新操作，所以这个会被放到回调函数中。
如某封邮件在当前 group 的 index 为 3，当它所在的 group 在其上面有两封邮件被删除/转移出当前邮件列表时，它的 index 就更新为 1。但是这个 Index 1 只有在前两封邮件删除/移动成功时的结果。
- 首先来看一下普通的邮件预览情况；
Navigation("待解析来判断导航页面的信息") .navDestionation("具体的解析和展示相应的页面")
- 获取即将被预览的邮件的基本信息； 由于时间排序不同时， Group 的展示顺序不同。需要获取当前 Group 与 Index 之间的关系；以及各个 Group 中包含哪些邮件。
由于每次在更新筛选条件/搜索条件/文件夹时都会触发更新，所以我们在邮件列表展示组件的 aboutToAppear 生命阶段注册获取函数；每次只有在公共层调用时会调用获取的函数，不调用则不会获取数据，同时可以节约资源。
- 1 是否多选？ 如果多选，需要选择多选邮件列表中位置最靠下邮件的下一封邮件；
- 2 计算最靠下邮件所在的 group 和 index，看其是否是当前 group 最后一封邮件；若是，根据索引获取下一个 group，若下一个 group 存在，则获取首封邮件；否则没有邮件可以预览。
- 如何正确获取预览邮件的 index ? 因为这个是在删除成功后调用的该方法，所以我们当时使用的是，(最靠下index + 1 - 该 group 移动的邮件数)。根据是否 搜索/重要文件夹/物理、逻辑删除，区分要移动的数目，从而获取正确的邮件索引。
