laoyang
|
8ca1eb76e0
|
fix(月视图): 首屏不变色 —— 真正根因是外层 ForEach key 不变 #6
上一版只改内层 key 没修好,因为问题不在内层。
## 真正根因
外层 ForEach 的 key 是:
(cells) => String(cells[0].dateMs) // "这页第一天"
重建前后这个值**完全相同**(还是那个月的 1 号)。
⇒ ArkUI 判定"这一项没变" ⇒ **不重新执行 itemGenerator**
⇒ 里面的 chunkCells(cells) 不重算
⇒ 内层 ForEach 收到的还是**旧的 cells 数组**,旧数组里 hasEvent 仍是 false
内层 key 再怎么改都没用 —— 内层压根没被重新调用。
## 修法
新增 `@State monthDataVersion`,每次 rebuildPages 后自增,拼进外层 key:
(cells) => `${cells[0].dateMs}_v${this.monthDataVersion}`
key 一变 → 外层重建 → 内层重新执行 → 颜色正确。
为什么不用"把整页 hasEvent 拼成 key":一页 42 格,key 会长很多,
且会参与 diff 比较,有性能代价。版本号是 O(1),语义也更清楚。
## 同时补了诊断日志
buildMonthCells 里输出:事件条数 / 有事件日期数 / 本页命中格数 / 当前版本号。
用来判断问题卡在哪一层:
· "有事件的日期 0 天" → 数据层没算对
· "命中 X 格" 但界面没变色 → 渲染/key 问题
## ⚠️ 教训(两层 ForEach 嵌套时)
这类 bug 我第一轮判断错了:只看到最内层 key 缺 hasEvent 就改了,
没意识到**外层 key 不变会让整棵子树被复用**,内层改什么都没用。
排查嵌套 ForEach 的刷新问题时,要从**最外层**往里查,
每一层的 key 都必须随数据变化。
|
2026-11-02 17:12:55 +08:00 |
|
laoyang
|
d49b041a2c
|
fix(月视图): 首屏农历不变红,切视图才生效 #6
用户反馈:刚打开应用时,月视图里有事件的日期农历没变红;
切到周视图再切回月视图,才变红。
## 根因:ForEach 的 key 不完整
月视图的 key 是:
(cell) => `${cell.dateMs}_${cell.dateMs === this.selectedDate}`
**没有包含 hasEvent。**
首屏时序:
1. aboutToAppear → rebuildPages(),此时 events 为空,hasEvent 全 false
2. reloadEvents() 拉回数据 → rebuildPages() 再次重建,hasEvent 变 true
3. 但每个格子的 key 完全没变(dateMs 和选中态都没变)
⇒ ArkUI 判定"这些项没有变化",**复用旧组件、跳过重绘**,颜色停在旧值
切视图能恢复,是因为切回来时整棵子树被重新创建,绕过了 diff。
## 修法
把影响渲染的**全部**状态纳入 key:hasEvent / isToday / 是否选中。
key 变了 → ArkUI 视为新项 → 重建该格子 → 颜色正确。
## 顺带加固
中间层"每周"的 key 原来是 `String(idx)`(0..5),跨月翻页时序号永远重复,
会让 ArkUI 误判为同一周而复用旧节点。改为用该周首日的 dateMs 做 key。
## 为什么不改成 @Observed / @ObjectLink
monthPages 是二维数组(MonthCell[][]),buildMonthCells 返回新数组、
chunkCells 又一次切片,改成可观察对象要动整条构建链路,
牵涉面大且容易引入其它 diff 问题。用 key 是最小、最稳的改法。
⚠️ 通用教训:ArkUI 的 ForEach 用自定义 key 时,**key 必须覆盖所有影响渲染的
字段**。漏一个字段,该字段更新后界面就不刷新 —— 而且这类 bug 只在
"同一项的数据变了、key 没变"时出现,首次渲染永远是正常的,很容易漏测。
|
2026-11-02 17:10:38 +08:00 |
|
laoyang
|
fa3dbc6157
|
style(月视图): 有事的日期标记色改为红色 #6
用户要求先看红色效果,蓝色太不显眼。
## 新增 event_mark 语义色
不直接复用现有的 `error`(#E02020):
error 是语义色,到处被"失败/危险"复用。把日程标记挂上去,
以后想调错误提示的红就会连带改掉日历标记,两件事被耦合。
所以单独加一个 event_mark。
色值(农历只有 8px,小字对对比度要求高):
· 浅色 #D93025 —— 比 #E02020 更沉,压在白底/浅灰底上更清晰,
也不像"出错"那么刺眼
· 深色 #FF6B60 —— 黑底上要亮一点才够,纯红会显脏
## 改动范围(3 处)
· 月视图(非宽屏)农历文字
· 月视图(宽屏)补位小圆点
· 周视图农历文字
选中日仍用 button_text(白):那天日期数字坐在深红底上,
农历必须白色,否则红字压深底看不清。
|
2026-11-02 17:06:21 +08:00 |
|
laoyang
|
ff62cf7f00
|
fix(月视图): 事件标记改为农历文字变色,修圆点位置错乱 #6
用户反馈:圆点位置很怪,离农历很远、落在两个日期中间。
根因:圆点塞在农历行的 Row 里,而农历用了 layoutWeight(1) 撑满整行,
圆点被挤到格子最右侧;格子宽 133px 远大于文字宽,
视觉上就成了"贴着下一个日期"。
采纳用户方案:把标记合并到农历文字本身
· 有事件 → 农历字用主题色并加粗
· 无事件 → 保持原来的 hint 灰
好处:不再额外占空间、位置天然跟着文字走、也不会像满屏圆点那样显乱
("点太多显得乱"正是上一版被砍掉的原因)。
对比度:选中日的日期数字坐在深色底上,农历若仍用主题蓝会看不清,
所以选中日改用 button_text(白),与原圆点方案的策略一致。
周视图同步统一为农历变色:两种视图用两套标记会让人以为是不同含义。
宽屏(wideLayout)农历被省略,保留一个小圆点补位(此时格子窄,圆点居中,无位置问题)。
|
2026-11-02 16:58:56 +08:00 |
|
laoyang
|
788171d1b2
|
feat(待办): 支持循环任务(标准 CalDAV / VTODO RRULE)#5
只按标准 CalDAV 实现,不依赖家书的自定义机制。
群晖等标准服务器:RRULE 写在 VTODO 上,由客户端负责展开。
## 核心语义决策
循环待办「勾完成」= 这一轮做完了,推进到下一周期,而不是结束。
若照搬非循环逻辑(置 COMPLETED 就完结),用户每勾一次循环任务它就永久结束,
循环规则等于白设。所以:
· 非循环 → 置 COMPLETED,永久结束
· 循环 → DUE 推到下一周期 + 状态复位 NEEDS-ACTION
## 关键修复:DTSTART 与 DUE 必须分开
原 parseTodos 把 DUE 和 DTSTART 都写进 startTime,后出现的覆盖先出现的。
但循环下两者语义完全不同:
· DTSTART = RRULE 的重复基准
· DUE = 这一条的截止时间
混在一起会导致重复基准被截止时间覆盖,算出来的发生日全错。
现在拆成独立字段,数据库补 dtstart 列(rrule 列已有)。
## 顺带修掉两个既有 bug(测试连带查出)
rewriteTodoCompletion 与 rewriteTodoFields 里,插入阶段的块序号
vtodoIdx 在遇到 END:VTODO 时被重置成 -1 ⇒ 每块都从 0 重新数,
多 VTODO 文件里永远匹配不到目标块,字段加不上(静默失败,
表现为「点了没反应」)。三处一并修正,vtodoIdx 改为全局块序号。
## 实现
- IcsUtil.incForFreq:按 FREQ 推周期,处理月末溢出
(1/31 + 1月 → 2/28 钳制,不跳到 3 月;2/29 + 1年 → 2/28)
- IcsUtil.freqOfRrule / rewriteTodoRecurrence
- TodoService.setRecurrence / completeRecurringRound
- 写回时同时给 DTSTART + DUE:RFC 5545 里 VTODO 的 DTSTART 是 OPTIONAL,
但缺它时各客户端对 RRULE 基准理解不一致,显式给能消除歧义
- 待办行显示「↻ 每周」标记(否则循环任务和普通待办长得一样,
用户勾完发现「又冒出新的」会困惑)
- 编辑弹框加 每天/每周/每月/每年 选择,再点一次取消
## 验证
scripts/test-ics-todo-recurrence.js:24 项全通过
(月末钳制、闰年、字段保留、取消循环、多 VTODO 定位、结构完整性)。
编译 BUILD SUCCESSFUL。
## 说明
服务器若不支持 RRULE(如群晖 Calendar 规格里未提及循环任务),
则循环只在客户端可见,同步到其它客户端会退化为普通任务。
|
2026-11-02 16:53:30 +08:00 |
|
laoyang
|
9066a12bbc
|
feat(待办): 按日历本分组 + 编辑/删除 + 修整行点击误完成 + 周视图圆点 #5 #6
## 1. 修 bug:整行点击都会勾选完成
上一版把 onClick 挂在最外层 Row 上,点标题/点截止时间/点空白都会改状态。
改为:
· 只有左侧圆圈 → 勾选/取消完成
· 其余内容区 → 打开编辑弹框(不改变完成状态)
## 2. 待办按日历本分组
用户:待办应按日历本分类,未完成里也能按家庭/生活分开,要有区分度。
未完成/已完成 两大段内部,再按日历本聚合:
· 分组标题前带该本颜色圆点(这是区分度的来源)
· 组标题显示 本名(数量)
· 组内按截止时间升序,无截止时间排最后
· 组之间按组内最早截止时间排序(最紧急的本在前)
CalendarDataService.loadTodos 补 d.calName(原来只带 calKey,分组标题没名字)。
## 3. 待办编辑弹框
点内容区弹出,可改:标题 / 备注 / 截止时间(含日期+时间选择器,可清除),
另有删除(二次确认)。只读本禁用编辑并提示。
⚠️ 用**整页覆盖层**而不是 bindSheet:ArkUI 同一组件只能挂一个 bindSheet,
Index 已用 detailShow 挂了日程详情,再挂会被覆盖(EventEditPage 顶部记过此坑)。
写入仍走「GET 原文 → 改字段 → PUT」,只动 SUMMARY/DESCRIPTION/DUE,
**不动 STATUS/COMPLETED**(改内容不该重置完成状态),
并保留 PRIORITY/CATEGORIES/X-* 等本地没存的字段。
## 4. 周视图圆点
weekStripDays 原来没算 hasEvent;补上与月视图**共用同一份**事件日期集合
(buildEventDaySet),口径完全一致。
颜色:用主题色 brand(选中日换白),**不取日历本的颜色** ——
圆点只表示这天有安排,若取本色会误导成只有那个本有日程。
## 验证
scripts/test-ics-todo-fields.js:19 项全通过
(保留 PRIORITY/CATEGORIES/X-扩展、特殊字符转义、多 VTODO 只改目标、
缺字段补齐位置、结构完整性)。编译 BUILD SUCCESSFUL。
## 未做
子任务(父子层级 / RELATED-TO):需先确认服务器是否支持,另开工单。
|
2026-11-02 15:47:03 +08:00 |
|
laoyang
|
98c4b6a96f
|
feat: 待办可勾选完成 + 月视图事件圆点 #5 #6
== #6 月视图事件标记(每日期最多一个圆点)==
应用市场反馈希望有事件的日期带标记。此前该功能存在但被移除,
原因是**按日历本逐个渲染**:3 个本 3 个点,15 个本满屏都是点。
- MonthCell 只加**一个布尔** hasEvent,不存每本一个的集合
- 用 buildEventDaySet() 一次遍历把有事件的日期收进 Set,
渲染时 O(1) 查(避免 42 格 × N 事件的 O(n²),本机近 3000 条数据会卡)
- 判定口径与 eventsOfDate 一致(区间相交)→ 跨天事件覆盖的每一天都有点
- 待办不计入(无时间点语义,混进来点会失去意义)
- 视觉用主题色 5vp 小点而非纯红:42 格里 30 个红点会吵,
正是用户嫌乱的同类问题;选中日深底下换白色保证对比度
- 无事件时用等高透明占位,避免行高跳动
== #5 待办勾选完成 ==
先回答关键问题:**系统未开放待办 API**。
本机 SDK 检索 @ohos.calendarManager 全文,todo/VTODO/task 零命中,
Calendar/Event 只处理 VEVENT ⇒ 第三方应用无法读写系统「待办」页签。
故只能在本应用内实现,并已在待办页注明不会出现在系统待办中。
现状是**只读**(点击提示请在源端修改),本次补上写回:
- TodoService.setCompleted():GET 原文 → 改状态字段 → PUT 回写
- EventDb: queryById / setTodoCompleted
- DavClient.getRawStrict():失败**抛错**(原 getRaw 失败返回 HTTP 4xx
字符串,若当 ICS 内容 PUT 回去会把待办覆盖成一句错误信息)
- IcsUtil.rewriteTodoCompletion()
⚠️ 两个关键设计:
1. **不重建 VTODO,只在原文上改字段**
VTODO 有 SUMMARY/DESCRIPTION/DUE/PRIORITY/CATEGORIES/X-* 等字段,
本地库只存了少数几个。重建后 PUT 会把没存的字段全部抹掉(丢数据)。
2. **两遍处理,与字段顺序无关**
RFC 5545 不规定字段顺序。单遍实现若 STATUS 出现在 UID 之前,
matched 仍为 false → 状态改不到 → 用户点完成没反应。
改为第 1 遍定位目标 VTODO 块、第 2 遍在块内改写。
插入补字段时按**块序号**定位而非行号(改动会删掉旧 COMPLETED 行,
行号不再对齐,会让字段落到 END:VCALENDAR 之后,部分服务端直接 400)。
同步维护三个字段(按 RFC 5545,缺一个各客户端显示就不一致):
STATUS / COMPLETED / PERCENT-COMPLETE。
UI:顶部新增「待办」标签(月/周/列表/待办),未完成在前、已完成在后,
点击勾选即写回;写回失败本地状态不变(避免界面与服务器不一致)。
验证:scripts/test-ics-todo.js 覆盖 26 项(状态在 UID 前/后、取消完成、
多 VTODO 只改目标、缺 STATUS 补字段、折行、结构完整性),全部通过。
编译 BUILD SUCCESSFUL。
|
2026-11-02 14:48:43 +08:00 |
|
laoyang
|
d993dd3d4b
|
移除定位权限:地理编码不需要 LOCATION(AGC 隐私标签审核)
AGC 以「未如实填写隐私标签」退回本次提审。核查后发现根因是
申请了两个用不到的敏感权限,与隐私标签无法自洽。
依据(本机 SDK API 26,targetSdk 26.0.0):
- @ohos.geoLocationManager.d.ts 中 getCurrentLocation / getLastLocation /
on('locationChange') 均有 @permission APPROXIMATELY_LOCATION;
- 而 getAddressesFromLocationName(地址→坐标)与 getAddressesFromLocation
(坐标→地址)**没有 @permission**,只有 @syscap ...Location.Geocoder。
- 本应用从不调用 getCurrentLocation,本就不读设备实时位置,只在「一键导航」
时把用户填写的地址换算为坐标。
改动:
- module.json5:删除 LOCATION、APPROXIMATELY_LOCATION(现仅 5 个权限)
- Index.ets:删除 ensureLocationPermission(),openInAmap() 直接调
geocodeAddress();同步清掉随之无用的 abilityAccessCtrl / bundleManager 导入
- string.json:删除 perm_location、perm_location_approx
- AppSettings.ets:更新权限一致性注释,警示后续勿再照旧文档写错政策
验证:assembleHap BUILD SUCCESSFUL;解包 hap 与 .app 内 module.json 均只剩
5 个权限、LOCATION 零命中;真机 hdc install -r 成功,aa start 无崩溃。
注意:华为旧文档 @ohos.geolocation(API 9 已废弃)仍写"需要权限 LOCATION",
那是老接口,勿据此判断——应以本机 .d.ts 为准。
|
2026-10-28 23:14:08 +08:00 |
|
laoyang
|
942f71bfdf
|
0.0.8 上架收尾:移除同步记录落盘 + 镜像空清单防护 + 前台默认间隔 15 分钟
三处改动(均来自 2026-10-16 真机日志实测):
1) 移除「同步记录」落盘
· LogUtil 顶部新增 ENABLE_FILE_LOG=false(发行版只输出 console),
真机排查时改 true 即可恢复落盘,所有调用点无需改动;
· init() 里顺手 unlink 历史版本遗留的 sync.log / mirror_diag.txt,
保证升级上来的设备沙箱也干净;
· SystemCalendarMirror 删掉 dumpDiagnosis 整个方法(不再导出 mirror_diag.txt),
连带去掉已无引用的 fs 依赖;
· SettingsPage「清理残留镜像账户」提示语由"见同步日志"改为"见下方"(清单本就在页面上)。
2) 镜像防护:系统日历清单为 0 时跳过创建
· 依据:2026-10-16 07:55:00 日志 `系统日历账户清单(共 0)` →
`镜像完成:本=0 … 失败=12`,12 个 bookId 连续 `201 CreateCalendar failed!`。
· 真因:设备重启后尚未解锁(direct boot),日历数据在加密存储里读不到,
getAllCalendars() 返回空列表 ⇒ createCalendar 必然失败,还可能留下半创建账户。
· 正常设备至少有一个本机日历,故"清单为 0"只可能是服务未就绪 ⇒ syncNow()
在 plan/syncBook 之前直接跳过本轮,等解锁后的下一次同步自然恢复。
3) 前台自动同步默认间隔 1 分钟 → 15 分钟
· 依据:2026-10-16 17:16–17:20 日志,5 分钟内连跑 5 轮
"12 本全量比对 + 出站镜像 + 提醒刷新",随后
`17:20:43 短时任务超时(配额用尽),后台同步将被挂起`
—— 前台把短时任务配额烧光,反而拖垮了真正的后台同步通道。
· 设备 preferences 里并无 sync_interval_minutes 键 ⇒ 走的就是这个默认值。
· AppSettings.getSyncIntervalMinutes 默认值 + Index.startAutoSync 的
setOrCreate 与 ?? 兜底 + SettingsPage 的 @State 初值,四处一并改为 15。
· 用户仍可在设置页选 1/5/15/30 分钟 或 1 小时。
验证:assembleHap 与 assembleApp 均 BUILD SUCCESSFUL。
|
2026-10-16 19:38:21 +08:00 |
|
laoyang
|
17d7602d7d
|
重复日程:新增结束条件(到某天/共几次);修复仅这一次失效与标题被清空
新增能力:
- 新建重复日程时可设"结束条件":永不结束 / 重复到某天 / 共重复几次
(之前只能选重复频率,无法指定次数或截止日期)
- 编辑既有重复日程会**回显**服务器上已有的 COUNT / UNTIL 并可修改
修复三个真 bug:
1. ⭐ "仅这一次"失效(实际改了全部):重复日程在列表里展开后,所有次共用
主事件的 id,编辑页只拿到 id、拿不到"用户点的是哪一次" → occStartMs 被当成
主事件的第一次发生 → EXDATE 排除的是第一次、覆盖行写在第一次上,
用户当次既没排掉、系列属性又被动过,看起来就是"全改了"。
修法:Index 打开编辑页时用 pendingOccurrenceTs 传入被点那次的 startTime;
seriesBoundaries 再把该时刻"吸附"到真实发生(容差 12h),确保 EXDATE 能匹配。
2. ⭐ 已有标题被删空:original 快照漏拷贝 title/description/location/reminders,
restoreRowById 于是把主事件行还原成空标题。
修法:快照补全全部字段。
3. ⭐ setExdate/setRrule 被 restoreRowById 覆盖(顺序错误):
先写 EXDATE 再还原 → 快照里的旧 exdate 又把排除覆盖掉。
修法:一律"先还原主事件行、再写 EXDATE/截断 RRULE"。
其它:
- 编辑页现在显示"被点那一次"的实际时间(此前显示的是主事件第一次的时间)
- 'all' 分支改为把改动写到主事件行,整系列一起改
- 复用唯一底部弹层(新增 sheetMode='repeatEnd' 选截止日期),仍保持只挂 1 个 bindSheet
|
2026-10-10 07:05:32 +08:00 |
|
laoyang
|
5e6f347fc6
|
修复:编辑重复日程缺范围选择;同步并发不再误报失败
问题1(用户反馈):删除重复日程有"仅这一次/此次及以后/全部"三选项,编辑却没有。
根因:save() 把 validate() 与 chosenBook() 检查放在 isSeriesOccurrence() **之前**,
任一不满足即提前 return,永远到不了范围选择弹层;delete 路径则是先判范围。
修法:
- save() 把"重复日程先选范围"提到最前(与删除路径一致),校验推迟到 doSave() 内
- chosenBook() 增加兜底:展开编辑时若该日程所属日历本不在"可写清单"里
(被标记只读/写权限探测失败),用该日程自己的 calKey/href 构造目标;
initPage 里还会用 CalendarDataBridge.lookupBook 把它补进选择列表(带真实名称/颜色)
- 新增 original 原始行快照:doSave 会就地改写 this.event 的 calKey/startTime,
而 EXDATE/UNTIL/拆系列必须依据原值 —— 否则范围计算用错系列
- applySeriesEdit 的 one/future 分支在改写当前行后,用 EventDb.restoreRowById 还原原行,
避免原系列残留幽灵行
- 加保存判定日志(脱敏)便于诊断
问题2(用户反馈):同步进行中再点手动同步/账号管理确定,提示"同步失败"造成误解。
根因:互斥锁抛的是普通 Error,三个调用点统一按"失败"提示。
修法:
- SyncEngine 新增 SyncBusyError 专用类型 + isSyncing/isAnySyncing 查询;
锁命中时抛 SyncBusyError,且 catch 不再把它包成普通 Error
- Index.syncSingle / AccountsPage.syncSingleAccount:命中→提示
"有同步任务正在进行中,请耐心等待",不显示失败
- Index.syncAll:命中记为 busySkipped(不算失败),全部被跳过时也只提示等待
|
2026-10-09 22:19:31 +08:00 |
|
laoyang
|
32162b8f04
|
修复折叠屏合盖旋转不再切换布局的回归
上一版为满足"接近1:1屏幕横竖屏布局一致",把宽屏判据改成纯短边≥840vp,
导致长条形屏幕(普通手机、折叠屏合上后的外屏)旋转横屏也不出双栏。
现在两条判据满足其一即双栏:
① 短边≥840vp(展开态/平板)——旋转不变,维持商店合规要求;
② 横屏且宽高比≥1.5(长条形屏幕)——旋转正常切换,恢复 0.0.2 行为。
判据实现由 mediaquery 改为 windowSizeChange(px→vp),旋转/折叠展开均实时生效,
并记录窗口尺寸日志便于真机排查。
|
2026-09-29 09:09:06 +08:00 |
|
laoyang
|
2f4657ced3
|
上架自检两项整改:横竖屏布局一致性 + 页面转场改为淡入淡出(弹簧曲线)
一、横竖屏(意见 1:折叠屏展开态 / 平板需支持横竖屏切换;接近 1:1 的设备横竖屏布局需保持一致)
- 主界面布局判据由"是否横屏 (orientation: landscape)"改为"窗口短边是否达到大屏断点 840vp":
min(宽,高) >= 840vp 等价于 (width >= 840vp) && (height >= 840vp),用两条 mediaquery 合成。
- 短边在旋转时不变(宽高互换),因此横竖屏布局天然保持一致 —— 屏幕比例接近 1:1 的设备
(折叠屏展开态、平板)在旋转时不会再出现"单栏 ⇄ 双栏"的布局跳变。
- 不锁死屏幕方向(module.json5 仍为 auto_rotation_restricted),折叠屏展开态与平板
依旧可以自由横竖屏切换显示。
二、转场动效(意见 2:使用系统转场,淡入淡出,曲线优先弹簧曲线)
- 全部 7 个 @Entry 页面新增 pageTransition():只做 opacity 淡入淡出,
不调用 .slide() / .translate(),即不做左右平移 / 上下位移 / 单帧直接切换。
- 转场曲线使用 curves.springMotion() 弹簧曲线。
|
2026-09-28 14:20:14 +08:00 |
|
laoyang
|
736a0a6587
|
新增系统日历镜像功能,镜像与备份目标统一改用 bookId;修复重复日程覆盖行、备份目标随勾选漂移等一批问题
- 新增 SystemCalendarMirror / MirrorSnapshot / MirrorInbound:把选定的 CalDAV 日历本镜像写入系统日历(供小艺、桌面日历卡片、手表可见),并做入站对账,区分"自己写入的 / 用户改的 / 用户删的 / 用户新建的",镜像标识一律用稳定的 bookId(accId-href哈希),不再用会随勾选顺序漂移的 calKey
- 后台同步接入镜像:同步前先做入站对账、同步后自动出站镜像,无需用户手动触发
- 系统日历备份目标改用 bookId:当用户取消同步某个日历本导致目标失效时,自动清空目标并把模式回退为"仅显示";开启备份必须先选定目标本,不再自动挑第一个本
- EventDb:覆盖行保留 RECURRENCE-ID,排除主事件对应发生改用 overrideKey(calKey, uid, recurrenceId, startTime),修复重复日程出现"幽灵条目"的问题
- 新增 WRITE_CALENDAR 权限声明及其用途说明;添加日历不再出现"本机",日历本对齐显示;版本升至 0.0.3(300)
|
2026-09-19 23:07:03 +08:00 |
|
laoyang
|
69a4a86a04
|
更改了周视图颜色的对比度,现在看起来更舒服了。
Signed-off-by: laoyang <laoyang@example.com>
|
2026-09-16 22:05:27 +08:00 |
|
laoyang
|
d7c49db304
|
增加修复了深色模式,完全沉浸的深色模式完成了。
Signed-off-by: laoyang <laoyang@example.com>
|
2026-09-16 21:40:11 +08:00 |
|
laoyang
|
353473127a
|
应用在首次打开或运行中,在用户未主动点击权限对应的相关功能或服务时,提前向用户弹窗申请开启【读取全部日程】权限,不符合相关法律法规要求。该问题已被修复。
Signed-off-by: laoyang <laoyang@example.com>
|
2026-09-16 20:54:41 +08:00 |
|
laoyang
|
76d82886e4
|
修复了进入日历没有日程卡片的bug。
Signed-off-by: Yang Yongquan <i@yangyq.net>
|
2026-09-16 12:34:39 +08:00 |
|
laoyang
|
cc7523a8ec
|
修复了从卡片进入日历无法定位当前日期的bug。
Signed-off-by: Yang Yongquan <i@yangyq.net>
|
2026-09-16 11:38:01 +08:00 |
|
laoyang
|
2173b06b43
|
新增了列表显示模式,用户可以在设置中进行选择。
Signed-off-by: Yang Yongquan <i@yangyq.net>
|
2026-09-16 10:07:57 +08:00 |
|
laoyang
|
7cf9203ec3
|
修改了用户协议等打开方式。
Signed-off-by: Yang Yongquan <i@yangyq.net>
|
2026-09-15 15:07:42 +08:00 |
|
laoyang
|
5eaeeb0f4c
|
增强了安全配置。
Signed-off-by: Yang Yongquan <i@yangyq.net>
|
2026-09-15 12:51:58 +08:00 |
|
laoyang
|
088f7b3773
|
增加了用户隐私协议等,增加了引导卡片。
Signed-off-by: Yang Yongquan <i@yangyq.net>
|
2026-09-15 09:06:15 +08:00 |
|
laoyang
|
64a58170ac
|
更改了几处交互逻辑。
Signed-off-by: Yang Yongquan <i@yangyq.net>
|
2026-09-14 21:53:15 +08:00 |
|
laoyang
|
c04a9a28cf
|
更改了日程的样式显示,现在按照时间轴显示。
Signed-off-by: Yang Yongquan <i@yangyq.net>
|
2026-09-14 21:28:51 +08:00 |
|
laoyang
|
fa152415cd
|
为日程列表增加了一条当前时间的横线,用来表示当前进度。
Signed-off-by: Yang Yongquan <i@yangyq.net>
|
2026-09-14 10:18:31 +08:00 |
|
laoyang
|
3c9b4dcfdd
|
1.修改了2x2的卡片样式。
2.为卡片增加了添加按钮,可以通过卡片直接添加日程。
Signed-off-by: Yang Yongquan <i@yangyq.net>
|
2026-09-14 09:07:47 +08:00 |
|
laoyang
|
d1252ed2b7
|
1.修改了设置页面的展示顺序。
2.在设置页面新增了软件特性和使用帮助。
3.设置页面中,静音和只读合并。
|
2026-09-14 08:24:36 +08:00 |
|
laoyang
|
5b6be08d9a
|
完成了用户账户加密,更改了只读日程的显示样式;日程中的地址,可以通过高德地图导航了。
|
2026-09-14 07:55:52 +08:00 |
|
laoyang
|
6899a5074b
|
修改了通知相关的功能,能够正常通知了。
|
2026-09-13 23:35:52 +08:00 |
|
laoyang
|
0fef40c7f3
|
修复了部分日程没有提醒时间的问题。
|
2026-09-13 21:50:28 +08:00 |
|
laoyang
|
04fdf3d386
|
1.增加了重力感应,也就是横屏响应式布局。
2.修改了沉浸式布局。
3.修改了添加日程和编辑日程页面,增加了重复、提醒等功能。
4.修改了权限问题,如果日历本是只读,则有删除线做标识。同时,对于只读的日程,点击后将不再进入编辑页面,而是展示详情。
5.系统日历的处理。给用户两个选择,第一个选择就是只显示系统日历。第二种选择,用户可以选择一个caldav账户中的某一个日历本,把系统日历中的日程,包括日历日程和应用创建的日程,都读取出来,然后加入到这个日历本下,最后同步到caldav的服务器上,这样的好处是,手机丢失了,或者换了手机品牌型号,手机上的日程仍然在自己的caldav服务器上有一个备份。当然,系统日历中的caldav日历,就不会再读取了。
|
2026-09-13 20:25:18 +08:00 |
|
laoyang
|
61bd6fc75f
|
修复了重复日历第一次不显示的问题。
|
2026-09-13 17:48:39 +08:00 |
|
laoyang
|
e0c6aa46d0
|
删除了日视图,感觉跟列表视图差不多,有点鸡肋。周视图改为和月视图一样,左右滑动进行切换。
|
2026-09-13 16:44:33 +08:00 |
|
laoyang
|
2af19637b6
|
在日历首页上,将按钮进行合并收拢,放在一个设置按钮下。
|
2026-09-13 16:08:03 +08:00 |
|
laoyang
|
bbb3ec5334
|
首次提交:SyncCalendar 项目
|
2026-09-13 15:50:37 +08:00 |
|