百合會論壇App (已更新v0.0.8)

thenano

# stable-v0.0.5
喜歡這個App的話，歡迎到github上幫我打顆星星 ⭐ ~
(連結入口在"我的>關於>Github", github要登入)

新增 :
- 雲端同步系統(同步歷史紀錄/更新紀錄/設定/收藏，數據將會安全存儲在你的百合會私人日誌，數據不會外流)[雲端同步需要在"我的>雲端同步"頁面手動啟動，推薦開啟前先在"我的>本地資料備份"確認有最新的備份檔案，畢竟我不知道會不會出未知bug]
- 小說/漫畫單頁模式觸控區域反轉選項
修復 :
- 對HTTP405(waf攔截)做應急的針對性修復
- 閱讀器滾動條/進度提示顯示失真
- 簽到桌面通知在部分況下不自動移除
- 部分簡體中文翻譯
- 系統通知圖標未能正常顯示
- svg頭像未能正常顯示
- 無法正常載入圖片
- webview網頁載入完成卻卡在載入中白屏
更改 :
- 改善閱讀器進入時的延遲/卡頓問題
- 優化關於遇到HTTP405錯誤時的提示

yuugure

最近我遇到新收藏的帖子没下载的时候已经失效的情况。感觉是否可以增加一个把某收藏夹设置为加入时自动下载帖子内容的选项。
另外，分享收藏夹的时候，我希望有选项允许把离线的内容一并分享。虽然这样的分享会比较大，但失效的收藏帖子也可以传播了，不然分享的收藏夹里失效的帖子无法导入，并且，只有一个用户一个手机里有下载的帖子的话，失效的帖子还是会失传，比如换手机后下载的内容就没了。

thenano

# stable-v0.0.6

喜歡這個App的話，歡迎到github上幫我打顆星星 ⭐ ~

修復 :
- 修復 HTTP 405/WAF 驗證後首頁、下拉重新整理、雲端同步、同步百合會收藏及收藏更新仍無法正常取得資料
- 修復部分內嵌 Base64 圖片無法載入或未置中
- 修復 Cloudflare 保護的 Email 在個人簽名等內容中無法正常顯示
更改 :
- 改善閱讀器長按拖動、滾動及閱讀進度保存時的卡頓問題
- 延長登入狀態的保存期限(30天>400天,目前為實驗性質的更改)

將來預計的更新 :
- IOS版本的APP? Maybe?

thenano

# stable-v0.0.7

喜歡這個App的話，歡迎到github上幫我打顆星星 ⭐ ~

新增 :
- 定時檢查"我的消息"更新並推送桌面通知(可設定)
- 首次收藏時自動跳出下載選項(可關閉)
修復 :
- 更新檢查時不會掃描小集合的問題
更改 :
- 將"下載"與"本地資料備份"的資料夾設定入口移動到"儲存空間
- 優化收藏夾/閱讀歷史紀錄載入時間

將來預計的更新 :
- ios端上架? 或許有機會(?

十字架shizijia

老师做得很好，就是感觉图片加载似乎更慢了一点，是我的问题吗？

yuugure

最近尝试了v0.0.7，一些问题反馈：

• 云端同步，点强制上传本地数据之后，还是传不上去，几天来两个手机都卡在了分段上传中，最近结果分别是尚未开始同步与已排定APP启动同步。原因未知，可能是有收藏的帖子被删了，可能是收藏夹过大，等等；
  test.zip (22.45 KB, 下载次数: 2)
  2026-9-23 22:03 上传

  点击文件名下载附件
  测试用的收藏夹
  
  ↑就是这个收藏夹
  云端同步不上去的同时，其中一个手机开了自动同步（那个手机的收藏夹是导入的本地文件），于是，每天都会看到收藏夹被清空(Update: 更新v0.0.8之后又导入了收藏夹，不再清空了)……应该就是因为自动同步的原因。
  关于导入收藏夹，我用“我的”里的“载入备份”会报错，，用“收藏”里的“载入收藏夹”可以正常导入。
• 几次尝试之后，我把收藏夹里所有能本地下载的帖子都下载下来了，发现在多选批量下载帖子后，需要一段时间慢慢把所有帖子解析加入下载列表，在所有帖子均被加入下载列表前，不能点开下载管理——否则极容易触发闪退，帖子越多越容易闪退，即使是一个帖子也可能闪退；闪退之后，还没加入下载列表的帖子就不会加入；然后下一次重新多选帖子下载时可能会重新下载一遍已经下载了的帖子（希望有已经下载过的页不重复下载的选项）；
  一部分帖子不知道为什么只会下载第一页，如这个；
  如果帖子的一页中有一张图是失效的外链图片，这整一页将下载失败，因此尤其是许多老帖的第一页很容易下载失败。百合会论坛过去有十几年是强烈反对上传图片而建议使用外链图片的，而外链图片绝大多数都已经失效了。
  

liangchen

反馈一个导入备份时的问题：
导入时提示「收藏項目與分類關聯無法解析」。AI 看了一下代码，报错似乎是因为备份文件中的 favorites.items 和 favorites.itemCategories 的数据没对应上，导致解析失败(master分支BackupRepositoryImpl.kt#L473)
这个问题会让整个备份都无法导入
能否在写入备份时增加数据校验，确保导出的备份能够正常导入；或者考虑在导入流程中增加一个选项，让用户选择：
1. 取消本次导入；
2. 跳过异常数据，仅导入其余无异常部分。这样即使备份中有一部分关联数据损坏，也不至于整个备份都不可用

贴上 Claude 的分析结果：
favorites.items 共 115 条，itemCategories 共 119 条，多出的正是这 4 条。最大 item id 是 160，1..160 中缺了 45 个 id（历史删除的收藏项），但只有这 4 个 id 留下了“孤儿关联”。
为什么会产生
- 导出是原样 dump 表的（BackupRepositoryImpl.kt:111-113 读 items，:173-175 读 itemCategories），不会过滤，所以文件如实反映了库里的脏数据；
- LocalFavoriteItemCategoryCrossRef.sq:1-4 是 INSERT OR IGNORE，没有检查 itemId 是否真存在，两张表也没有任何 SQL 外键（9.sqm）——写进去就永久留下；
- 目前所有删除路径（deleteFavoriteItems、cleanupOrphanItems）都会先删关联，还原路径也有 itemIdMap[...] ?: return
  兜底，所以不是删除逻辑漏删，而是某个调用方把一个“已经不存在（或当时就不存在）的 item id”传进了 setItemLocations / addItemsToLocations 这类接口。嫌疑最大的是收藏页用
  rememberSaveable 保存的多选集合（FavoritePage.kt:161，在 :785/:938/:1161 被写回），选择项在其它入口（详情页取消收藏、百合會同步、云端同步下发删除）后被删掉时，id
  就成了幽灵；
- 4 条全部指向默认分类（id 1），因为 deleteCategory 拒绝删除默认分类（FavoriteStoreRepositoryImpl.kt:229-230），所以 deleteByCategoryId(1)
  永远不会执行，这类脏行没有任何清理路径——这也是为什么“重新导出备份”依旧会是坏的。

感谢大大做的 APP，体验很不戳！

wqy382

哇，巨佬！还在持续更新中吗？真的很厉害呢

curry30th

试用了一下 很好用 静候IOS版本