Predidit
[功能请求]可不可以请求在云同步中加入同步追番列表的功能
其实这部分代码已经写好并提交到仓库了，只是没有启用。
主要的问题是测试结果不理想，在线webDav服务由于运营商缓存等各种原因，表现不是很稳定。
简单说就是，我们经常会拿到旧的同步文件。这在历史记录同步时问题并不大，通过差分更新，最多是偶尔有一些历史记录没有提交，不会出现在其他设备上。
但在追番列表这样需要全量更新的场合，这会造成追番莫名其妙丢失，即使在加入追番的那台设备上也是如此。这在我看来是无法接受的，所以相关代码没有启用。
如果有什么好的解决办法，欢迎告诉我。
其实这部分代码已经写好并提交到仓库了，只是没有启用。
主要的问题是测试结果不理想，在线webDav服务由于运营商缓存等各种原因，表现不是很稳定。
简单说就是，我们经常会拿到旧的同步文件。这在历史记录同步时问题并不大，通过差分更新，最多是偶尔有一些历史记录没有提交，不会出现在其他设备上。
但在追番列表这样需要全量更新的场合，这会造成追番莫名其妙丢失，即使在加入追番的那台设备上也是如此。这在我看来是无法接受的，所以相关代码没有启用。
如果有什么好的解决办法，欢迎告诉我。
能否通过给同步文件名称添加时间戳的方式来避开缓存
其实这部分代码已经写好并提交到仓库了，只是没有启用。
主要的问题是测试结果不理想，在线webDav服务由于运营商缓存等各种原因，表现不是很稳定。
简单说就是，我们经常会拿到旧的同步文件。这在历史记录同步时问题并不大，通过差分更新，最多是偶尔有一些历史记录没有提交，不会出现在其他设备上。
但在追番列表这样需要全量更新的场合，这会造成追番莫名其妙丢失，即使在加入追番的那台设备上也是如此。这在我看来是无法接受的，所以相关代码没有启用。
如果有什么好的解决办法，欢迎告诉我。
这些缓存一般也都是遵循HTTP标准，可以试着参考： HTTP 缓存
可以尝试两种方法：
- 标准方法：设置请求头 Cache-Control: no-cache
- 添加查询参数：在请求的 URL 后面加上时间戳或随机数，例如 file.txt?v=123456
对于第二种方法，一般的缓存策略，带参数都会忽略缓存的，但是也有专门配置忽略请求参数的，两者可以结合一下使用看看效果
附议，建议先加上手动同步功能。我个人的使用场景是手机和家中PC同步。所以我的做法是在PC上开一个本地WebDav服务，晚上回家后将手机上在公司的浏览记录和收藏与PC同步，然后PC继续。这个场景手动同步就能解决问题，家里其他设备由于连在一个局域网，也能同步。
我之前写过一个webdav同步的思路，不一定很好，可以作为参考，大概如下：
- 0.需要同步的数据，创建一张变动表，记录增删改的动作以及对应的变动值，webdav上同步一个变动表的json文件
- 1.在webdav下创建一个lock.txt文件，在一台设备同步的时候，读取这个文件，当它有值，且值的时间戳在10分钟以内，跳过本次同步，之所以有个10分钟的判断，是为了防止有的设备因为一些问题没有同步成功，导致没有去删除这个时间戳，所以这个时间戳等同于一个带超时的锁
- 2.在lock.txt没值或者时间戳超出十分钟的时候，往里面写入一个时间戳，并且开始同步：对变动表json进行遍历，与本地的变动表进行对比，如果有相同ID的变动操作，取最近的记录，同时在本地进行相应的增删改操作，并把本地的变动表合并后生成新的json上传到webdav，同时删除lock.txt的值
- 3.为了避免长时间积累下的json文件过于庞大，新增一个覆盖同步的按钮，这个按钮会清空json内容，并且生成一条删除所有记录的变动，然后创建一个新增本地当前数据的记录，覆盖webdav的json文件
然后缓存的问题，我之前是没有遇到，或许可以试试前面朋友提到的地址加参数的方案？回头我抽时间看看代码，看看有没有办法提供一些帮助
我之前写过一个webdav同步的思路，不一定很好，可以作为参考，大概如下：
- 0.需要同步的数据，创建一张变动表，记录增删改的动作以及对应的变动值，webdav上同步一个变动表的json文件
- 1.在webdav下创建一个lock.txt文件，在一台设备同步的时候，读取这个文件，当它有值，且值的时间戳在10分钟以内，跳过本次同步，之所以有个10分钟的判断，是为了防止有的设备因为一些问题没有同步成功，导致没有去删除这个时间戳，所以这个时间戳等同于一个带超时的锁
- 2.在lock.txt没值或者时间戳超出十分钟的时候，往里面写入一个时间戳，并且开始同步：对变动表json进行遍历，与本地的变动表进行对比，如果有相同ID的变动操作，取最近的记录，同时在本地进行相应的增删改操作，并把本地的变动表合并后生成新的json上传到webdav，同时删除lock.txt的值
- 3.为了避免长时间积累下的json文件过于庞大，新增一个覆盖同步的按钮，这个按钮会清空json内容，并且生成一条删除所有记录的变动，然后创建一个新增本地当前数据的记录，覆盖webdav的json文件
然后缓存的问题，我之前是没有遇到，或许可以试试前面朋友提到的地址加参数的方案？回头我抽时间看看代码，看看有没有办法提供一些帮助
好完整的方案，思路真的非常棒，变动记录应该可以解决大部分问题，我看看怎么实现。如果你对本项目感兴趣的话，可以PR吗。
我正在 @dujianchi 观点的基础上进行原型设计，但是还是遇到了一些问题
我打算只维护变动表而不考虑锁，因为我们需要较高频率的自动同步
这里有一个难以解决的问题，当同时多台设备修改追番列表时将出现竞态
我们将需要在每次修改本地列表前拉取云端变动表以确定云端没有新的变动，这样才能防止在本地生成新变动表并同步到云端，导致云端已有但还没同步到本地的变动丢失
这相当耗时，让每次同步变得缓慢
我想我已经完成了初步的工作和测试
@ErBWs @xxfttkx
可以帮忙在现在的主分支上测试 webDav 同步追番列表的功能吗
除了可能的 bug 之外有如下两个问题
- 当前的同步设置选项卡非常杂乱，也许我们需要重新设计。追番页面的同步按钮的视觉效果也需要优化
- 确认可能的运营商缓存的影响
webdav 上是有文件了，但是报错
flutter: ┌───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
flutter: │ #0 KazumiLogger.log (package:kazumi/utils/logger.dart:33:11)
flutter: │ #1 <asynchronous suspension>
flutter: ├┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
flutter: │ ⛔ webDav download collect changes failed DioException [bad response]: null
flutter: │ ⛔ Error: Not Found
flutter: └───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
flutter: ┌───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
flutter: │ #0 KazumiLogger.log (package:kazumi/utils/logger.dart:33:11)
flutter: │ #1 <asynchronous suspension>
flutter: ├┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
flutter: │ ⛔ webDav get collectibles from file failed PathNotFoundException: Cannot open file, path = '/Users/Library/Containers/com.example.kazumi/Data/Library/Application Support/com.example.kazumi/webdavTemp/collectibles.tmp' (OS Error: No such file or directory, errno = 2)
flutter: └───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
其他端能不能同步现在电脑上传的之后测试
关于 UI，CircularProgressIndicator 看着太突兀了，用 KazumiDialog.showLoading 可能会比较好。icon 可以换成 cloud_sync，作用看起来更加直观。
感觉也可以再放一个同步按钮到 同步设置 页面里，放在追番页和 同步设置 页感觉各有使用场景。不过我没细看代码，不知道能不能放过去
话说为什么不把 WEBDAV 的同步开关做成一个，而是做成了一个追番同步开关和一个观看记录开关，WEBDAV 这个 SettingsSection 只保留 WEBDAV 的同步开关 和 WEBDAV配置，其他的放到其他 SettingsSection 可能会解决杂乱问题
这个报错是正常的，因为第一次同步时云端没有文件。我花了相当多的精力处理这些特殊情况，应该可以正常工作，但是报错被保留以方便调试。
由于同步的步骤很多，耗时很长，我不是很想使用 showloading 。
可以，同步追番的函数封装得很好。
我最终没能实现自动追番同步，同步一次的耗时阻止了我们这样做。追番同步相关开关是为了在未设置相关 webdav 凭据时给出干净的错误提示，但感觉确实可以和 webdav 开关合并。
由于同步的步骤很多，耗时很长，我不是很想使用 showloading 。
那可以用一个宽高都是 24 的 SizedBox 包裹 CircularProgressIndicator，这样大小就和按钮一致了，会协调一点
或者用 FAB，用 FAB 也需要 SizedBox 就是了
我正在 @dujianchi 观点的基础上进行原型设计，但是还是遇到了一些问题
我打算只维护变动表而不考虑锁，因为我们需要较高频率的自动同步
这里有一个难以解决的问题，当同时多台设备修改追番列表时将出现竞态
我们将需要在每次修改本地列表前拉取云端变动表以确定云端没有新的变动，这样才能防止在本地生成新变动表并同步到云端，导致云端已有但还没同步到本地的变动丢失
这相当耗时，让每次同步变得缓慢
抱歉，最近在放假，所以没有很及时查看消息。
是的，我最初设计这个锁就是为了防止多台设备竞争，因为我原本的同步允许我延迟半小时以上，甚至一整天都没问题，因为我的场景是绝大多数情况下，用户不会在短时间内切换设备。
看到您已经完成追番功能，我感到非常欣喜，感谢您的努力！