laoyang
|
a808ae5f42
|
备案材料:更新为真实 Release 证书数据,修正取错根 CA 的 MD5
## 修正的错误(要紧)
旧材料里的签名 MD5 是 `7d0c4b46b7c1c0d23c6e4316e5c996a3`,
那是**华为根 CA 的指纹**,不是开发者证书的。
原因:`.cer` 是三层证书链(根 CA → 中间 CA → 你的证书),
`openssl x509 -in xxx.cer` 只读第一张,取到的就是根 CA。
这个值若填进备案系统,签名校验必然失败。
正确做法是先拆链再取最后一张:
先按 BEGIN/END CERTIFICATE 切分成 m0.pem m1.pem m2.pem,
再 `openssl x509 -in m2.pem -noout -fingerprint -MD5`。
## 本次实测值
| 项 | 值 |
|---|---|
| 包名 | familybook.yangyq.net |
| 证书主体 | CN=杨永全(1845816276425949633), Release |
| 有效期 | 2026-11-01 → 2029-11-01 |
| 签名 MD5 | 95d2b3d31de21fad563ee8f71df16c65(已去冒号、小写) |
| 公钥 | MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEEU+Of... |
## 顺带
- APP 名称统一为「岁月家」
- 删掉旧文件 APP备案材料.md(含错误 MD5,留着易误用)
- 补充三项提交前必查前提:服务器付费方式、子域名备案、正式证书
- 服务内容说明按工具类口径写好,避开前置审批
|
2026-11-01 23:08:34 +08:00 |
|
laoyang
|
b32501535e
|
日程改为全量同步 + 修复大响应超时(laoyang/FamilyBook#31)
## 背景
用户 2026-10-30:「全部拉取,全量同步」。
起因:切到下个月再点某一天,端上没数据(即使服务端有)。
根因是请求范围写死成「今天-7 ~ +60」且切月不重拉 ⇒ 窗口外的日子永远空。
## 改动
### FbModuleLoad.loadModule
- `name` 参数从 `FbModuleName` 放宽到 `string`
日程改成全量后,缓存键要带请求窗口(`calendar:1970-01-01:2100-12-31`),
否则"旧窗口的数据"会被当成新窗口的数据显示。
- 新增可选 `timeoutMs`
全量约 9.3MB / 28628 条,默认 15 秒在移动网络下会超时;
超时后 `FbModuleRepo` 退回旧缓存,表现成"翻月没数据"且极难查。
### FbModuleRepo.load
- 透传 `timeoutMs` 给 `FbApi`。
### FbCalendarPage
- 请求改为全量范围(`CAL_FULL_FROM` ~ `CAL_FULL_TO`),超时放宽到 60 秒。
- 缓存键带窗口(`calendar:<from>:<to>`):某次请求失败后 `FbModuleRepo`
会把**旧范围**的缓存 sink 回来,端上就把"只含 10~12 月的数据"当全量显示
—— 这是该 bug 的帮凶,加窗口标识后从根上消失。
- `agendaDays()` 的 `-7 ~ +60` 现在**只决定列表显示多少天**,
不再兼作请求范围(原来两个数必须同步的约束随全量同步作废)。
- 删除 `agendaFrom()` / `agendaTo()`(不再需要按当前日期算窗口)。
### 恢复 canEdit 的写权限判断
本轮改动曾把
`isEventWritable(this.detailBase, this.books)`
回退成
`isEditableEvent(this.detailBase)`
这是**工单 #31 已修过的 bug 回退**:只判 kind/id/calId 不看本的可写性,
导致只读共享日历里的日程也显示「编辑」按钮,用户改完点保存才报
「这本日历你没有写权限」。
已恢复,并与首页 `FbHomePage.ets:1517` 保持同一口径
(否则同一事件"从首页进能编辑、从日历页进不能")。
## 验证
`build_hap debug` → `BUILD SUCCESSFUL`(33 tasks)。
⚠️ **未做真机验证**。全量同步的实际耗时与内存占用需在真机上确认
(28628 条约 9.3MB,解析 150~300ms,主要成本是流量)。
## 备注
这 3 个文件的改动来自 2026-10-30 那一轮,因故未提交;
本次一并整理提交,与品牌改名(家书→岁月家)无关。
|
2026-11-01 22:54:22 +08:00 |
|
laoyang
|
d2129c9aab
|
配置 AGC Client ID(Map Kit 地点联想与 Account Kit 登录都依赖它)
原值是可读的占位符 REPLACE_WITH_AGC_CLIENT_ID,占位期间:
- Map Kit 联想不返回任何候选(错误 1002600003 App authentication failed)
- 华为账号手机号登录也会失败
⚠️ Client Secret 不入库:它是服务端凭据,纯鸿蒙客户端不需要,
且一旦进 git 历史就无法真正清除。
|
2026-11-01 20:44:50 +08:00 |
|
laoyang
|
825008657b
|
品牌改名:家书 → 岁月家 (laoyang/FamilyBook#38)
## 起因
用户 2026-11-01:「家书已经有人做了,八月份刚上线的」。
核实:「家书 HomeBook」(广州家书科技有限责任公司,粤ICP备2026096420号,
2026-06 成立、08 上线)。功能**部分重合**(家庭记录 + 相册 + 家谱)。
华为审核指南 1.3「应用名称不得和其他应用名称相同,避免混淆」,
虽然个人与企业主体查重不互通、技术上能过,但被人工驳回概率高。
## 定名过程(用户逐个否掉)
| 候选 | 否决原因 |
|---|---|
| 寸草 | — |
| 家卷 | ❌ 与「家眷」同音,口头传播会打错字 |
| 家时光 | ❌ App Store 已有「家·时光」定位几乎一致;且「家+时光」是常见组合,辨识度低 |
| 家纪 | ❌ 已有重名 |
| **岁月家** | ✅ 搜不到同名应用;是口号的直接展开(岁月 + 家) |
## 最终定稿(用户明确指定)
```
应用名 岁月家
主标语 一家人用岁月写成的一本书 ← 不变
一句话简介 一家人用岁月写成的一本书 ← 改为与标语相同
官网标题 岁月家 · 一家人用岁月写成的一本书
英文名 FamilyBook ← 不变
包名 familybook.yangyq.net ← 不变
```
## 改动范围(17 + 18 处,12 个文件)
### 应用名(17 处)
`AppScope/resources/base/element/string.json` 的 app_name,
`entry/.../string.json` 的 16 条(应用名、卡片名、无障碍描述)。
### 用户可见文案(18 处)
`FbBackgroundSync` / `EntryAbility`「正在同步家书数据」、
`FbAttachOpen`「家书附件」相册名、`FbHttp` 地址校验失败提示、
`FbCardData` / `FbCardMediaData` 卡片空态「先在「家书」里填写服务器地址」、
`TopBar` / `Drawer` / `FbLoginPage` 的应用名文本、`FbSettingsPage` 的说明。
## 刻意不改
- **包名 / bundleName**(用户明确要求不变,且改了等于换一个应用)
- **英文名 FamilyBook**、目录名、仓库名(改了会让 git 历史、部署脚本、证书路径全跟改)
- **代码注释**里 200+ 处「家书 FamilyBook · 某模块」—— 不影响运行时,
改了只会制造噪音 diff,让将来 blame 变难
- **主标语**里一个字都没动
## 验证
### 编译
`BUILD SUCCESSFUL`,33 tasks。
### 产物实测
解包 `.hap` 的 `resources.index`:
- 「岁月家」出现 **17** 次
- 「家书」出现 **0** 次
### 全局一致性校验(31 项全过)
`_tooling/check_rename.js`:
- 客户端 app_name / EntryAbility_label / 产物内容
- .ets 用户可见文案无残留(排除注释)
- 服务端非注释代码无残留
- `Auth::homeTitle()` 用「某某某的家庭岁月」
- `DEFAULT_SLOGAN` 未被改动
- 官网线上 5 个页面无「家书」、标题含岁月家、渲染后 h1 是品牌名
- 材料 app_name / 一句话简介 / 包名 / versionCode / 域名
⚠️ 校验过程中我自己的判据出了 2 次假红:
① 注释识别不全(漏了 `/**` 单行块注释和 `<!--` HTML 注释)→ 补齐 isCommentLine
② 「为什么叫岁月家」整节重写后,旧断言还在查「书信」「家与书」
(那是**旧名字**的逻辑)→ 改成查「岁月」+「家」的拆解
## 一处语义决策(问过用户)
网页端 `Auth::homeTitle()` 生成「某某某的家书」—— 这是**产品核心语义**
(每个家有自己的那一本),直接换成品牌名会读成「某某某的岁月家」,不通。
用户定:改成 **「某某某的家庭岁月」**。
兜底(无姓名时)仍用品牌名「岁月家」。
## 连带影响(不阻塞)
- 上架材料 7 个文件已同步(含软著全称改为「岁月家家庭生活档案管理软件」)
- 官网已部署,线上标题已是新名字
- 软著申请尚未提交 —— 正好一次写对新名字,不需要变更
|
2026-11-01 19:55:36 +08:00 |
|
laoyang
|
c0d5fdff01
|
docs(上架): 应用商店上架 / 正式证书 / APP 备案 全套材料
## 背景
用户要同时办三件事:① 上架华为 AppGallery ② 申请正式发布证书 ③ 在阿里云做 APP 备案。
本目录是这三件事的全部材料,信息**全部取自真实代码与实测**,不是套模板。
## 材料清单
| 文件 | 用途 |
|---|---|
| `README总览.md` | 先看这个:材料索引 + 三件事的先后关系 + 你现在就能做的 |
| `商店上架文案.md` | AGC 各字段可直接复制的文案(一句话简介/应用介绍/更新说明/分级问卷/隐私标签) |
| `商店信息_结构化.json` | 同上,机器可读 |
| `隐私政策.md` | 完整隐私政策正文 |
| `用户服务协议.md` | 完整用户协议正文 |
| `正式证书与签名切换.md` | 发布证书申请 + release 打包全流程 |
| `APP备案材料.md` | 阿里云 APP 备案逐字段填写指引 |
| `图标/app_icon_216.png` | AppGallery 图标(216×216,9.7KB) |
| `图标/app_icon_1024.png` | 备案图标 + 1024 规格(112KB) |
| `verify_materials.py` | 校验材料与代码一致(42 项) |
## 实测核对过的事实(材料里的数字都从这里来)
- 包名 `familybook.yangyq.net`、版本 `0.8.0` / versionCode `800`(`AppScope/app.json5`)
- 应用名「家书」(`AppScope/resources/base/element/string.json`)
- 权限 **只有 3 个且全是普通权限**:INTERNET / GET_NETWORK_INFO / DETECT_GESTURE
(`entry/src/main/module.json5`)—— 定位、通讯录、相机、麦克风、设备标识符**一个都没申请**
- 第三方 SDK:**无广告、无统计、无推送**
- 后端域名 `family.yangyq.net`,服务器阿里云 `47.104.72.161`(中国大陆)
权限少是审核优势:「权限滥用」是驳回第一大类原因,家书直接绕开。
隐私政策第二节与第十节做了**权限逐条对照表**,可直接给审核看。
## 图标为什么要重做
包内 `fb_logo.png` 是 **192×192 且自带圆角**(四角透明,半径约 33px)。
AppGallery 两种规格都不达标(要 216 或 1024,且「square-shaped icon」)。
→ 取内部主色 #F2E9D8 铺满方形画布补掉缺角,图案原样叠加、不裁切不缩放,
生成 216 与 1024 两版。图案与包内完全一致(审核要求后台图标 = 包内图标同一图案)。
第一版直接用 LANCZOS 放大,**保留了圆角**,被 `verify_materials.py` 抓到并修正 ——
这就是写那个校验脚本的意义。
## 四个必须先解决的问题(已写进总览,不隐瞒)
1. **现在是调试证书** → 备案要正式证书的公钥/MD5,上架要正式签名(调试包报 991/1014)
2. **没有「家书」软著** → 备案不强制;华为要求但可用《免责函》过渡(6 项现有软著均无关)
3. **隐私政策页面还不存在** → 站点无 privacy 路由;建议用华为自带托管服务(SyncCalendar 用的那个,实测 200)
4. **阿里云服务器是否包年包月** → 备案硬性要求,需用户去控制台确认
## 顺序(三者有依赖,不能乱)
```
① 申请正式证书(10 分钟,AGC 即时出证)
↓ 拿到后才能
② APP 备案(1~20 工作日,最慢,先提交)
③ 打 release .app 包
↓ 拿到备案号才允许提审
④ 提交 AppGallery 审核(1~7 工作日)
↓
⑤ 公安联网备案(上架后 30 日内)
```
## 校验
`python3 verify_materials.py` → **42 项全过**:
包名/版本/名称与代码一致、权限集合完全一致、隐私政策"未申请"的声明与代码相符、
字数限内、三份文档互相不打架、图标尺寸与四角不透明、已知缺口如实记录。
## 没做的事(刻意的)
- 不生成截图:必须真机原生界面,不能是设计稿(审核明确禁止)
- 不填备案表:实名主体必须本人操作,且工信部短信核验要发到本人手机
- 不碰 AGC:需要登录用户账号,部分环节要扫码/人脸
|
2026-11-01 09:56:04 +08:00 |
|
laoyang
|
96168811a3
|
Map Kit 地址联想:module.json5 补 client_id metadata 占位 (laoyang/FamilyBook#33)
官方「开发准备 - Map Kit」要求 entry 模块的 module.json5 里有
metadata: { name: "client_id", value: <AGC 应用 Client ID> }。
只在 AGC 打开地图服务开关、不配这里,仍会报
1002600004 The Map permission is not enabled(错误码表"可能原因"第 2 条就是它)。
当前 value 是占位 REPLACE_WITH_AGC_CLIENT_ID —— 拿到 AGC 的 Client ID 后替换。
占位期间不会崩(认证失败 ⇒ fbGeoTips 返回空 ⇒ 输入框退化成普通文本框)。
验证:BUILD SUCCESSFUL(33 tasks,27 executed);
产物 entry-default-signed.hap 的 module.json 里 metadata 实测
[{"name":"client_id","value":"REPLACE_WITH_AGC_CLIENT_ID"}]。
|
2026-11-01 09:39:47 +08:00 |
|
laoyang
|
5661312679
|
日程编辑:确认「开始」后结束时间自动 = 开始 + 1 小时 (laoyang/FamilyBook#34)
用户 2026-11-01:
「当我选择了开始时间并确定之后,结束时间要跟着开始时间变成开始时间加1个小时。
也就是说,所有时间我们都默认它是一个小时。如果不是一个小时,再让他自己去改。」
## 改前
`applyPicker()` 只在**会变成负时长**时才动结束时间:
if (this.fEndDate < iso || (this.fEndDate === iso && this.fEndTime < hm)) { ... }
⇒ 用户改了开始、结束还挂在老位置,实际时长变成随机的。
## 改后
点「开始」确定 ⇒ 结束**无条件**重置为「开始 + 1 小时」。
改「结束」那条路一个字不动(改结束不影响开始)—— 这是「默认一小时、
不像一小时再自己改」的另一半。
全天日程跳过这段:时刻部分本来就不生效,改了不会落到服务端,
但会让"切回非全天"时看到一个莫名的时间。
## 新增 fbPlusHours()
`FbDateTimeField.ets` 里加 `fbPlusHours(date, time, hours)`,返回 `{date, time}`。
**不复用现成的 `fbAddHour()`**,因为那个有两个问题:
return fbPad2(Math.min(hh + 1, 23)) + ':' + mm;
① `Math.min(hh+1, 23)` **封顶 23 点** ⇒ 23:30 加一小时还是 23:30;
② 只返回时间、不带日期 ⇒ 表达不了「次日 00:30」。
跨天/跨月/跨年全部交给 `Date` 运算,不自己算天数
(自己 `if (hh>=24) dd+=1` 在"11 月 30 日 + 1 天"上就会错成 11 月 31 日)。
## 验证
**纯函数真值表 13 项**(从真实 `.ets` 抽函数、只擦类型标注后 node 直接跑,
不手抄替身;擦除后断言行数不变、无类型残留、没引入新字符):
普通 / 跨天整点 / 跨天半点 / 跨月 / 跨年 / 非闰年 2 月末 / **闰年 2 月末 ⇒ 2/29** / 午夜 / 带分钟
—— 全过。其中 23:30+1h ⇒ **次日 00:30**、12/31 ⇒ 次年 01/01、2028-02-28 ⇒ 2028-02-29。
**反向验证 3 项**(证明判据不是恒真):
坏A(封顶 23 点 / 不带日期)被抓到、坏B(丢分钟)被抓到、坏C(固定 28 天)被抓到。
**接线断言 12 项 + 反向验证 5 项**(静态,因为"函数对 ≠ 接进去了",
上一轮 #34 主体 bug 就是参数名对不上、编译运行都不报错):
- 开始分支调用 `fbPlusHours(iso, hm, 1)`、结果**同时**写 `fEndDate` 与 `fEndTime`
- 结束分支**没有任何** `fStart*` 赋值
- 全天日程有 `!this.fAllDay` 判断
- `pickIsEnd = !isStart`(#34 主体防回归)
- 不再残留 `this.fEndDate < iso` 那种条件顺延
- 反向:改回老写法 / 只写日期不写时间 / 改结束顺手改开始 / `pickIsEnd` 再反过来
→ 逐条转红;**对照组**(只改一句注释)仍绿 —— 证明断言不会"见到改动就红"
> ⚠️ 接线判据自己第一版有 bug,是反向验证抓出来的:坏1 用正则
> `if \(!this\.fAllDay\) \{[\s\S]*?\n \}` 找替换目标,但渲染层还有一个
> `if (!this.fAllDay)`(控制「结束」那一行显示),正则先吃到那个 ⇒ 注入落在无关位置
> ⇒ 断言仍绿(假阴性)。改成"先把 applyPicker 的函数体切出来再替换"。
**编译**:BUILD SUCCESSFUL,33 tasks(17 executed)。验签通过。
**⚠️ 已知存量失败(与本次无关)**:`_fb_arkts_guard.js` 跑出 1321 通过 / 3 失败,
三条都在工作区里**别的会话未提交的改动**上(`AGENDA_BACK_DAYS` 被换成 `CAL_FULL_FROM/TO`
导致"列表视图显式传日期范围"判据失配、`canEdit` 相关两条属 #31)。
本次只改 `FbDateTimeField.ets` 与 `FbEventEditSheet.ets`,不碰那些文件;
用 `git show HEAD:` 核实过 HEAD 版本里 `AGENDA_BACK_DAYS` 还在(判据本来通过)。
|
2026-11-01 09:38:14 +08:00 |
|
laoyang
|
d2d0a435a3
|
日程编辑:点「开始」却改了结束时间 laoyang/FamilyBook#34
用户 2026-10-30:「鸿蒙端,日程添加时,选择时间,点上面,
修改的反而是结束时间,这个是 bug。」
根因:openPicker 的参数语义与调用方相反。
· 调用方 dateTimeRow(label, isStart) 传的是 **isStart**
· 被调用方签名却是 openPicker(isEnd),内部直接 pickIsEnd = isEnd
⇒ isStart=true(点开始)→ isEnd=true → 整条链路按"结束"处理。
错得很"自洽"所以一直没被发现:
· 弹层初值读的是结束时间
· 确认后写回的也是结束时间
· 连标题都显示「选择结束时间」
三处一起错,"弹出来的值"和"改完的值"是一致的,看着不像坏。
修法:参数统一成 isStart(与调用方同名同义),内部自己取反。
没在调用处写 openPicker(!isStart) —— 双重否定更容易再错一次。
对照:观影表单 FbMovieNewSheet 用同一个 FbDateTimePicker 组件,
但 pickIsEnd 是显式赋 false/true,没有正反颠倒的空间,不受影响。
验证:
· 编译 BUILD SUCCESSFUL(33 tasks / 17 executed)
· 从真实源码提取三条映射做断言:pickIsEnd=!isStart、
读日期/读时间均在 isStart 时取 fStart* —— 全部通过
· 真值表:点开始→读fStart*→写fStart*→标题「选择开始时间」,
点结束→读fEnd*→写fEnd*→标题「选择结束时间」
· 反向验证:拿修复前的代码跑同一判据,正确转红
(旧版点开始时读写都是 fEnd*),证明判据不是恒真
· 全仓库排查 isStart/isEnd 用法,无同类问题
|
2026-10-30 15:41:38 +08:00 |
|
laoyang
|
7bc26dd7e1
|
地点联想:改用鸿蒙自带 Map Kit,不再走高德 laoyang/FamilyBook#33
用户指示「端侧不用高德,用鸿蒙自带的接口」。
改用 @kit.MapKit 的 site.queryAutoComplete(),顺带解决原方案两个问题:
① 高德 Web 服务 key 是服务端密钥,本不该出现在客户端;
② 线上那个 key 实际是 JS API 类型、调 Web 服务接口一直失败(见 #33 排查记录)。
现在端上不需要任何外部 key,也不需要我们自己的服务端接口与配额。
改动:
- FbGeoRepo:site.queryAutoComplete({query}) -> sites[]
取 name + formatAddress + location。
formatAddress 的 SDK 注释原文是 "Formatted detailed address of a place",
正是用户要的「作为参考的详细地址」。
formatAddress 缺失时用 locality + streetName + streetNumber 兜底。
- FbAddrInput:去掉 token 参数(MapKit 鉴权走 AGC 应用认证,与 API 令牌无关)。
- FbEventEditSheet / FbTripNodeSheet:两处调用同步去掉 token。
错误码全部降级为空结果、不打扰用户(声明文件列明的):
- 1002600003 App authentication failed
- 1002600004 The Map permission is not enabled
- 1002603001 Zero result(查不到,属正常业务结果,不刷错误日志)
- 1002600002 Failed to connect to the Map Kit server
联想挂掉 => 退化成普通文本框,手敲照常保存。
字段名一律以声明文件 @hms.core.map.site.d.ts 为准:
StreetNumber 的字段是 streetName / streetNumber,
第一版凭印象写成 street / number,编译直接报
"Property 'street' does not exist on type 'StreetNumber'",已修正。
编译通过(33 tasks,17 executed)。
|
2026-10-30 08:12:15 +08:00 |
|
laoyang
|
f4f27cea55
|
地点输入:补地址联想,下拉带详细地址好区分同名地点 laoyang/FamilyBook#36
用户 2026-10-30:「在所有调用高德显示详细地址的地方…不能只把地点告诉我,
一定要把详细地址也放在后面。因为同一个地址可能有好几个,
我根本不知道应该选哪一个。」
网页端(addr_suggest.js)已经是这个行为,端上原本**连联想都没有**(纯文本框)。
本次把能力补到端上:
- 新增 FbGeoRepo.ets:调服务端 /api/v1/geo/tips,最少 2 字才查
- 新增 FbAddrInput.ets:候选每行两行字(地名 14px 深色 + 详细地址 12px 灰),
同名地点靠第二行区分;防抖 260ms(与网页端同节奏);用 seq 丢弃过期响应
- 日程编辑、行程节点两处地点接入
🔴 走服务端代理而不是端上直连高德:高德 Web 服务 key 是服务端密钥,
打进安装包等于公开(反编译/抓包即得,配额会被跑光、key 可能被封)。
网页端用的 JS API key + 安全密钥是域名白名单那套,原生端没有等价机制。
⚠️ 必须是 @ComponentV2 组件而不是 @Builder:@Builder 的值类型参数
不参与状态观察(SDK r/quick-rules/05-state.md),候选列表/展开态写在
@Builder 里会数据变了界面不重建。本项目在 FbEventChip/FbTagChip/
FbCalOptionRow 上各踩过一次。
⚠️ 联想失败一律返回空候选 ⇒ 退化成普通文本框,手敲照常保存
(接口挂/没网/没配 key 都不能拖垮主流程)。
编译通过(33 tasks,17 executed)。
|
2026-10-30 08:03:13 +08:00 |
|
laoyang
|
f90cae0dcc
|
日程详情:只读日历不再给「编辑日程」入口 laoyang/FamilyBook#31
真机(DEL-AL20 / HarmonyOS 7.0.0.109)实测发现:只读共享本(如「工作学习」)
里的日程,首页详情卡仍显示「编辑日程」,用户改完点保存才被服务端拒:
「保存失败:这本日历你没有写权限。」
根因是 canEdit 写死 true,只判了 isEditableEvent(kind/id/calId),
没判这本日历能不能写。
- Types.ets 新增 isEventWritable(e, books):复用 FbCalBook.canWrite 口径
(由 FbCalRepo.fetchBooks 依 /calendar/books 的 kind+perm 算出),
不与写权限推导逻辑重复;books 缺失时判为不可编辑(宁可少给入口)
- FbHomePage:canEdit 由写死 true 改为按写权限判定;
openEvent 里顺手预加载 calBooks(原本懒加载,进详情时还是空数组,
会把本来能编辑的日程也误判成只读)
- FbCalendarPage:同步改用 isEventWritable,两处口径一致
真机复验:只读日程详情只剩「导航」;有权限的日程「编辑日程」正常,
改标题保存后杀进程重启仍在(确认真落库)。
|
2026-10-29 20:39:52 +08:00 |
|
laoyang
|
fd3ea53086
|
资源:点列表进只读详情,附件可预览/下载,编辑走底部按钮分离 laoyang/FamilyBook#29
用户原话(2026-10-28):「资源模块,点击资源后是编辑,那怎么下载资源
里面的文件呢?应该和名册一样,点击后是详情,属于谁、共享给谁、附件,
可以打开预览然后下载。下面有按钮可以编辑,点编辑之后才是编辑功能。」
原来 FbResourceSheet 是「查看=编辑」合体:点列表直接进可编辑框,附件区
点不动、没有预览/下载。这次拆成两级:
1) 新增 FbResourceDetailSheet(只读详情):标题/正文纯文本、归属人、
共享列表、附件列表(图片点开全屏预览、非图片点开交给系统「打开方式」、
每条附件可「下载」)。底部「编辑」按钮(仅 owner/write)→ 切编辑浮层。
2) FbResourcesPage 编排:点列表 → 详情;详情「编辑」→ 原 FbResourceSheet;
编辑保存/删除回列表。 + 新建仍直接进编辑浮层。
3) 新增 common/FbAttachOpen.ets:附件「下载明文 / 打开发 / 存相册 / 另存为」
的端上工具。走服务端 media.php 的移动端出口(能力早已就绪,纯端上改动)。
· 存相册:photoAccessHelper.showAssetsCreationDialog(系统弹窗,无需 WRITE 权限)
· 另存为:picker.DocumentViewPicker.save
· 系统打开:隐式 Want viewData + 读授权 flag
编译 BUILD SUCCESSFUL;守卫 _fb_arkts_guard.js 1324/0(浮层计数清单已同步
resources 1→3 模板、books 3→4 补 #28 存量、cardN 42→44)。
|
2026-10-28 23:53:53 +08:00 |
|
laoyang
|
f5a979f5c8
|
读书上传+在线阅读+笔记导入:端上补齐三个入口 laoyang/FamilyBook#28
用户原话(2026-10-28):「鸿蒙端对齐网页端」。读书端上原来只有书架。
1) FbBookUploadSheet:上传电子书(选文件→服务端解析建书)+ 粘贴导入读书笔记
2) FbBookReadSheet:在线阅读(章节列表 + 单章正文,一次一章)
3) FbBookSheet 详情态加「在线阅读」入口(有章节时才显示);
FbBooksPage 加「+上传/导入」入口 + 设置菜单「导入笔记」接上
编译 BUILD SUCCESSFUL;服务端冒烟 _i28_book_api.py 11/0 + 反证命中。
|
2026-10-28 22:47:38 +08:00 |
|
laoyang
|
f1f279f973
|
电影影评+评论:详情浮层接「评价与评论」真功能 laoyang/FamilyBook#27
用户原话(2026-10-28):「鸿蒙端对齐网页端」。观影详情原来只能看平均分。
现在:
1) FbMovieRepo 加影评/评论类型 + reviews/saveReview/deleteReview/
addReviewComment/deleteReviewComment 五个 API + 解析(含感受目录、评论树、mine 判断)
2) 新组件 FbMovieReviewSheet:我的影评(打分 1-10 星 + 观后感受多选 + 正文 +
改/删)、全部影评列表(含评论树、回复、逐条删除)
3) FbMovieDetailSheet 加「评价与评论」入口 + 内嵌影评浮层
⚠️ 影评数/均分仍以列表项为准(详情接口不返回,与既有注释一致)。
编译 BUILD SUCCESSFUL;服务端冒烟 _i27_movie_review_api.py 22/0 + 反证命中。
|
2026-10-28 22:30:09 +08:00 |
|
laoyang
|
59a9d3df39
|
任务共享:面板补「共享给谁」区块 laoyang/FamilyBook#26
用户原话(2026-10-28):「鸿蒙端对齐网页端」。任务面板原来没有共享入口,现在:
1) FbTaskShare 类型 + parseTaskDetail 解析 Task::find 已带的 shares
2) FbTaskRepo 补 fetchTaskShares/shareTask/unshareTask(删除走 query)
3) FbTaskPanel 加「共享给谁」区块:列表(可改/只看)+ 逐条取消 +
「+ 共享」复用选人组件(与资源/财务共享同一套)
编译 BUILD SUCCESSFUL;服务端冒烟 _i26_task_share_api.py 13/0 + 反证命中。
|
2026-10-28 22:10:15 +08:00 |
|
laoyang
|
f93dd92cdb
|
资源附件+共享:浮层补「附件」「共享」两个真功能 laoyang/FamilyBook#25
用户原话(2026-10-28):「鸿蒙端对齐网页端」。资源浮层原来「附件与共享
还在网页端,App 暂未开放」,现在服务端补齐 API 后:
1) FbResourceRepo 补 attach/share 写操作(上传走 fbUploadOne 字段 file;
删除走 query 传 attachment_id / person_id —— DELETE 带 JSON body 服务端读不到)
2) FbResourceSheet:附件区块(列表 + 缩略图/图标 + 「+传附件」+ 逐条删)+
共享区块(列表 + 「共享给…」复用选人组件 + 逐条取消)
· 只读共享来的不摆入口(与 canWrite 对齐)
编译 BUILD SUCCESSFUL;服务端冒烟 _i25_resource_api.py 21/0 + 反证命中。
|
2026-10-28 22:00:15 +08:00 |
|
laoyang
|
6f360fd6a1
|
财务折线:概览卡画净资产趋势(配服务端 /timeline)laoyang/FamilyBook#24
用户原话(2026-10-28):「鸿蒙端对齐网页端」。财务概览卡原来「折线图占位
(第二轮接图表能力后填)」,现在:
1) FbLedgerPoint 类型 + parseLedgerTimeline(读 /timeline 的 items)
2) loadEntries 里顺带拉 timeline(单独缓存键 ledger_timeline_<id>)
3) timelinePath():时序点 → 绝对坐标折线 path(Path 组件画,Y 轴按
min..max 归一,不是从 0 起 —— 金额平稳时不贴底);<2 点时给占位文案。
编译 BUILD SUCCESSFUL;守卫 _fb_arkts_guard.js 1324/0;服务端冒烟
_i24_timeline_api.py 8/0 + 反证命中。
|
2026-10-28 21:47:28 +08:00 |
|
laoyang
|
97846029c7
|
笔记图片块:展示真图 + 插图 + blocks 保存(图文混排后半程)laoyang/FamilyBook#23
用户原话(2026-10-28):「鸿蒙端对齐网页端」,笔记端上只支持纯文本。
这半程改鸿蒙端,配合服务端 cd56a9d 补的 /notes/upload:
1) 展示:FbNoteItem 新增 blocks(FbNoteBlock[]),parseNotes 把原始块
带进来;FbNoteSheet 里 image 块真画图(fbImageSrc),不再显示「[图片]」。
2) 插图:正文区下加「+ 插图」,选图 → fbUploadKey 上传拿 key → 加入
待保存列表;每张图带「×」可删。
3) 保存(P0 修复):带图时改走 saveNoteWithBlocks —— 正文 text 块 + 图片
image 块整组提交。原来只传 body,服务端折成单个 text 块整组替换,
**编辑带图笔记会把图片块静默删光**。
4) fbUploadKey 是 fbUpload 抽出的第二出口:复用同一 multipart 核心拿 key,
不复制第二份实现(本项目"两份实现漂移"栽过多次)。
编译 BUILD SUCCESSFUL;守卫 _fb_arkts_guard.js 1324/0;服务端冒烟
_i23_note_image_api.py 11/0(含 PATCH 后图片块不被删)+ 反证命中 2/2。
|
2026-10-28 21:35:11 +08:00 |
|
laoyang
|
3e910f1ca0
|
docs(card): 删掉「格子数与图数量永远相等」这句错误断言 #3
上一版(工单 #2)在这里写「这样"格子数"和"图数量"在结构上永远相等」。
这句话是错的,也正是工单 #3「21 格」的思想源头:
keys 按 poster **去重**收集、还卡 20 张上限
list 按 **行** 过滤、无上限,还会再裁偶数
两个集合基数不可能恒等,正确的说法只是「≤,不是 ==」。
把错误的断言留在注释里,下一个人会照着它推理,再踩一次同样的坑。
本次只改注释,无逻辑变更(守卫 1324/0、v97 反证 13/0 均通过)。
|
2026-10-28 10:49:20 +08:00 |
|
laoyang
|
acb2eadcb7
|
fix(card): 观影海报墙格数改偶数并按海报去重 #3
用户原话:「怎么是单数的?我这里看,显示的是21张图片。观影卡片。」
上一版(#2)修掉了「只有 6 张图」,但留下了新的结构问题:
· keys(配图)按 poster 去重,上限 20
· list(格子)按行过滤,无上限
⇒ 一部电影看了两场(两天各一场 / 重映),两行 poster 相同、拿到的 img
也相同,于是「有图的行数」会**多于**「图片张数」,可能是 21 这种单数。
两列栅格下奇数格必然让最后一行右侧留空 —— 就是用户看到的样子。
修法(`list` 的语义是「一部电影一格」,不是「一场观影一格」):
· 按 poster 去重(键用 poster 而非 title:同名重映 / 译名相同的不同片不算同一部)
· 顺带保证偶数:len - (len % 2),不写死 20/18(图少时减法会变负索引)
· poster === '' 的行显式跳过(没海报键的行不该进墙)
验证:静态守卫 1324/0(新增 groupV97 六条)· 反向验证 13/0(6 条注入各自命中)
编译 BUILD SUCCESSFUL,产物 6.2M。真机待验(hdc 设备掉线,见工单)。
顺带修掉两处「跑不起来」的环境问题(与本次 bug 无关,但会挡住验证):
· 编译脚本补 JAVA_HOME / PATH:PackageHap 阶段要 spawn java,
缺了只报 `Error Code: 00308018 Unknown Error`,真因
`spawn java ENOENT` 藏在 build-logs 深处。
· PATH 必须写 POSIX 风格 /d/... 而不是 D:/...:
MSYS2 的 PATH 是冒号分隔,`D:/xxx` 里的冒号会把路径劈成两段。
|
2026-10-28 10:10:33 +08:00 |
|
laoyang
|
f0d0ab9a05
|
fix(card): 观影 4x4/6x4 海报墙「只有 6 张图」修复 #2
用户原话:「观影4x4和4x6,只有六张图,划到第七张,就没图片了」
病根:两个上限各写各的
· CARD_IMG_MAX = 6 (配图数)
· rows.length < 30 (列表长度)
⇒ 前 6 格有海报,第 7 格起 img === '',posterCell 走 else 画淡紫占位块。
渲染没错、数据也没缺(线上 movie_details 221 条全有 poster_key,去重 205 张),
纯粹是「配图数 < 格子数」的结构性问题。
修法(不是把 6 改成 20 就完事,而是让格子数由图数决定):
· CARD_IMG_MAX 6 → 20,依据华为 Form Kit FAQ:API 20+ 上限 20 张 / 10MB,
本机 const.ohos.apiversion = 26 走这一档;
内存按解码后算 240×360×4×20 = 6.59MB < 10MB,留 3.4MB 余量。
· 拆出 CARD_ROW_MAX = 30(命名常量),专给不画图的 2x2/2x4 纯文本行。
· 新增 list:只保留 img !== '' 的行,长度天然 ≤ CARD_IMG_MAX
⇒ 格子数与图数在结构上永远相等,某张 404 也不会冒空格子。
· fbAttachPosters 签名 (recent, list) → (rows),两个数组各写一遍循环太容易只改一处。
· 新增 fbCardImagePaths 并发取图(MAX_PARALLEL = 4):20 张串行实测 10~17s,
卡片刷新窗口撑不住。MAX_FILES 24 必须 ≥ CARD_IMG_MAX,否则后下的挤掉先下的。
验证:静态守卫 1317/0;反向验证 15/0(7 条注入各自恰好命中目标断言)。
其中注入 A 抓出原先一条假绿断言:写的是「CARD_IMG_MAX >= 4」,
而 bug 原值正好是 6,6 >= 4 恒真 ⇒ 等于什么都没守。已改成「> 6」。
|
2026-10-27 23:06:24 +08:00 |
|
laoyang
|
b84ea06b73
|
v95 服务卡片四项:日程卡「今」按钮放大、观影/任务 2x4 列表可滑动、观影 4x4/6x4 补列间距且 6x4 改两列
#1
用户提四项(2026-10-26):
「日程的右上角那个今天的今,特别不好点,一不小心就到日程里面去了……
是不是可以把按钮弄的大一点。」
「观影的卡片,2x4,右侧观影的列表,不能上下滑动,第三个被截断,很难看,
如果显示多个,就要能滑动,如果不能滑动,就显示两个。」
「任务的 2x4 卡片,也是一样的。」
「观影的 4x4 卡片,和 4x6 卡片,两列图片挤在一起,中间没有空隙,应该缩小一点,
这个大小,我感觉应该根据屏幕的大小来。4x6,宽度都是一样的,为啥要弄成三列?」
① 日程卡「今」按钮 22x22 → 32x32
病根:22 的圆比最小建议点击区小一半,手指偏一点就落到卡片本体的
`.onClick(openApp)` 上 ⇒ 「想回今天」变成「进了日程详情」。
面积 484 → 1024(2.1 倍);同一份 sideBtn() 里的「+」一并放大,
翻页键 ‹ › 本来 32,现在四个按钮手感一致。
为什么是 32 不是 40:4x4 卡高度紧,顶栏与内容区竖向堆叠
(内容区 layoutWeight(1)),顶栏长高多少内容区就少多少。
必须改 width/height 本身 —— 卡片里这是 Button,可点区就是自己的宽高。
②③ 观影/任务 2x4 右半 Column → List(可滚动)
病根不在条数而在容器:Column 根本不滚动 + 硬截 3 条,
3x(38+10=48) + 2x6 = 156vp 而可用仅 ≈130vp ⇒ 第三条被压扁/裁掉。
条数上限 3 → MR_2X4_MAX=12 / TK_2X4_MAX=30;滚动条 BarState.Auto
(条目少时不露空滚动条)。数据侧 FbCardMediaData 两处 `rows.length < 4`
同步放到 30,否则卡上拿到的还是 4 条,改了容器也滑不出东西。
④ 观影 4x4 / 6x4 补列间距 + 6x4 三列改两列
病根:`List({ space: 8 })` 的 space 在 lanes 多列模式下只管行间距,
列与列之间不会自动留缝;海报格 .width('100%') + .aspectRatio(0.68)
又贴着 lane 边排 ⇒ 两列严丝合缝贴死。
改法:.lanes(2) → .lanes(2, 8),第二个位置参数才是列间距 gutter。
⚠️ gutter 是位置参数(SDK list.d.ts: lanes(value, gutter?: Dimension),
Dimension = PX|VP|FP|LPX|Percentage|Resource)⇒ 传数字,
写成 { gutter: 8 } 是类型错误(中途踩到,编译期才炸)。
6x4 同时从 .lanes(3) 改成两列,与 4x4 一致;文件头那句
「这块卡更宽、一排放三张」已过时,已注明别再照着它改回去。
同批带上 v92 未提交的观影海报墙实现(此前只在工作树里,从未提交过):
- 新增 data/FbCardImages.ets(下载 + desiredSize 缩图 + fd 管理)
- FbCardMediaData / FbFormAbility / FbCardForms 里的 formImages 管道
- string.json 卡片名带尺寸(「家书 · 日程 4×4」/「家书 · 观影 4×4」)
⚠️ FbCardImages.ets 已被 FbCardMediaData import,不一起提交就编译不过。
验证:
- 静态守卫 _fb_arkts_guard.js:1303 通过 / 0 失败
(新增 groupV95() 共 28 条,钉住按钮尺寸、List 容器、条数上限、
两列 + gutter>0、且不许写成 { gutter: N } 对象)
- 反向验证 _fb_v59d_falsify.py:289 通过 / 0 失败
(新增 9 条注入,逐条证明上述断言真的会红)
- 真编译 hvigorw assembleHap:BUILD SUCCESSFUL,HAP 产物已生成
⚠️ 真机验收未做:hdc list targets 为空(设备未连/未解锁)。
这四项全是观感与手感,静态断言证明不了「点得着、滑得动、看着舒服」,
待设备连上后补真机探针(重点:真的点「今」、真的滑列表、量两列实际间距)。
|
2026-10-26 07:28:06 +08:00 |
|
laoyang
|
7ae34e6e23
|
v91 观影/任务卡加 4x4/6x4(滚动列表+新建+卡上完成任务);修任务卡无数据(解析器用错:看板嵌套需 parseTasks)
|
2026-10-25 09:29:41 +08:00 |
|
laoyang
|
6711197a94
|
v90 新增观影卡与任务卡(2x2/2x4):卡片按类型分流推数据,key 带 version 前缀
|
2026-10-24 23:44:46 +08:00 |
|
laoyang
|
7ebe18b2d1
|
v89 修复服务卡片翻页后时间轴不重绘:ForEach key 加 version 前缀(key 撞车复用旧组件)
|
2026-10-24 21:53:13 +08:00 |
|
laoyang
|
d69beb629f
|
v88 旅程查看器全屏化:视频内联全屏播放、播放中直接滑动切换、只留底部计数
|
2026-10-24 21:53:05 +08:00 |
|
laoyang
|
c77370f521
|
v87 旅程查看器 Swiper 化:图片+视频混排翻页,滑动带动画
用户 2026-10-24:「图片和视频是不是可以都支持滑动啊?……滑动到视频
的时候,点击就直接播放。另外滑动的时候有没有个动画呀?现在就滑动,
整个一下就变化,特别生硬。」
实现:
- photoViewer 从「单张 Image + PanGesture(松手瞬跳 index)」改成
Swiper:跟手滑动 + 换页缓动动画(duration 350ms),loop 循环翻页
- 媒体列表改 mediaOf() = 图片在前视频在后(与缩略图墙同序),
viewerKeys:string[] → viewerPhotos:FbTripNodePhoto[](要带 mime)
- 视频也是翻页项:滑到视频页显示 ▶ + 文件名 +「点一下播放」,
点一下走 openVideo() 弹原有全屏播放器(系统控件不变)
- 底部 ‹ › 按钮走 viewerCtl.showPrevious()/showNext()(与手势同一条
动画通道;直接改 index 是瞬跳);计数由 onChange 统一更新
- 打开查看器用 changeIndex(at, false) 跳到所点那张,开局不播动画
- viewerStep()/imageKeysOf() 随 PanGesture 方案一并退场
真机实测(Mate X7,"2026国庆回老家"段附件 3 个媒体):
开查看器 1/3 → 左滑 2/3 → 3/3 视频页(点一下播放)→ 点击后视频
真实播放(5.mp4,00:05/00:29)→ 关播放器回查看器原位 → 按钮翻页
2/3→1/3 → 循环回绕 1/3→3/3 全部通过。
验证:守卫 1177/0(v87 组新增 10 条)· 反向验证全量 249/0
(v87 组 7 条全部命中)· 装机成功
|
2026-10-24 20:52:51 +08:00 |
|
laoyang
|
051d3974ba
|
v86 首页补齐五项入口(就地编辑 + 4 张卡新建 + 新增观影/联系人卡)
用户 2026-10-24「端上也全部都实现」,即 v84 验收时留下的三条:
名册新增成员 / 首页日程弹框后的编辑 / 首页其他卡片的新增。
实现:
- 日程详情卡「编辑」改成就地叠编辑表单,不再 closeEvent()+switchModule
- 近期任务 / 最近纪念日 / 最近观影 / 联系人 四张卡加「+ 新建」
- 观影卡与联系人卡端上原来没有,本次新建(数据走本地仓储,/home 不返回)
- backOnce 按层加 6 个分支;@Monitor 覆盖 8 个标志位
- FbSectionTitle 扩 addText/onAdd(带默认值,老调用点不改)
真机验收抓出三个「断言全绿但用不了」的 bug,一并修掉:
1. 编辑表单所有按钮点不动 —— Stack 层叠顺序写反,详情卡的整屏遮罩
盖在表单之上。dumpLayout 坐标全对、节点全在,只有真点才会发现。
2. 「+ 新建」点了没反应 —— syncNote 在本页只有赋值没有渲染点,
失败分支静默 return。统一改成 note() = 赋值 + 当场 Toast。
3. 改选「不重复」存完还是「每天」—— recognize 的保护逻辑(防清掉自定义
重复规则)误伤了「用户主动清空」:原规则非空 + 选 none ⇒ rrule 整项
不发。加 fRepeatTouched 区分「归入 none」与「主动选 none」。
验证:守卫 1167/0 · 反向验证全量 242/0 · 装机成功
端到端落库 建→改→删 全走通,测试数据已清理
|
2026-10-24 20:22:35 +08:00 |
|
laoyang
|
cdbf0a9593
|
v84: 首页「+ 新建」日程 + 红线去端点 + 新建表单两处可见性修复
用户 2026-10-23 原话:「日程,没有新建日程按钮,名册,也没有新增成员这个按钮。」
「首页上的日程,红色线不对,变短了左侧缺了一块。在日程模块中,那个红线左侧
是不是还有一个红点?如果有,去掉。」
① 首页日程区块加「+ 新建」(FbHomePage / Widgets.FbSectionTitle)
- FbSectionTitle 扩两个可选参数 addText / onAdd,带默认值 ⇒ 老调用点一行不改
- 按需懒拉 /calendar/books,缓存进 calBooks,同一会话只拉一次
- todayIso() 用本地年月日拼,**不用 toISOString**(UTC 会让早 8 点前算成昨天)
② 时间红线两端统一成「一根满宽线、无端点装饰、无行首文字」(FbDayTimeline)
- 老写法 `Row { Text(时间) width(34); 线; 圆点 }` ⇒ 行首 34vp 把线顶掉一块
(与网页端 .ag-now「双重缩进」同一类病),行尾 6x6 圆点就是用户问的红点
- 改成满高 Column + Blank 撑高 + 满宽 2px 线,与卡片端同一写法
③ 🔴 真机实测发现的两处可见性问题(FbEventEditSheet)
- 「加入哪本日历」原来排在「提醒」之后 ⇒ 表单高于卡片(maxHeight 86%),
它被推到滚动区下方,首屏只看到被底边切掉半行的标题(实测 bounds 高 7px)。
它是必选项(没选就「请选一本日历」存不上)⇒ 挪到「全天」之后、日期时间之前。
- 错误提示原来在滚动区**内部最底部** ⇒ 用户在顶部点「创建」时提示在几百 px
之下看不见;就算滚到底也被 Scroll 底边切半行。现象是「点了创建什么都没发生」。
⇒ 挪到滚动区外面、按钮区上方(实测:Scroll 底 1953,提示 1984~2024,按钮 2074)。
真机验收(设备 5NC0225B27004718,线上 family.yangyq.net):
- 静态守卫 1112/0;BUILD SUCCESSFUL;install bundle successfully
- 「+ 新建」bounds [868,931][1018,1045],点击真的弹出「新建日程」
- 诊断确认 books=15 canWrite=6(数据层完全正常,之前的「选不了日历本」是可见性问题)
- 日历本挪位后首屏可见:标题高 40px(原 7px),10 本 chip 从 838 排到 1358
- 错误提示挪位后不滚动即可见:命中「日程得有个标题」
- **端到端建卡成功**:线上库确认 id=2411 cal=5 20:00~21:00,首页 1 条→2 条;
测试数据已按 id 精确删除(remaining_test_rows=0),重启后恢复 1 条
|
2026-10-24 19:14:18 +08:00 |
|
laoyang
|
0bab0cdcc6
|
v83: 后台定期同步(四层调度,策略照 SyncCalendar)
用户原话:「另外,要有定期同步的功能,就是家书app在后台,也能自动同步
数据,这样打开app,基本上数据就是最新的。同步的策略,去synccalendar找,
里面有办法。」
四层调度(缺一层就会在某种场景下"永远不同步"):
1. 前台:onForeground 时若距上次同步超过 5 分钟,补一次
2. 退后台:requestSuspendDelay 短时任务(单次≤3分钟、单日10分钟配额)
3. 延迟任务:workScheduler(周期 2 小时 —— 系统按活跃分组压制,
请求更短不报错但不生效)
4. 桌面卡片:updateDuration:1(=30 分钟,唯一不受压制的通道,
每天上限 50 次);先推卡片再触发同步
关键约束(写错了都不报错,只是静默失效):
- WorkSchedulerExtensionAbility 单次回调上限 2 分钟,必须在 finally 里 stopWork
- 后台扩展跑在独立进程,EntryAbility.onCreate 的初始化一步都没跑过
⇒ prepare() 必须补齐 token store / module token / FbDb.open
- 回前台必须 cancelSuspendDelay 归还配额,否则两三天后用光
- workInfo 要带 isPersisted,否则重启后任务永久消失
- abilityName 必须与 module.json5 声明一致,对不上时 startWork 不报错但不回调
- ApplicationInfo 没有 bundleName 字段,包名在 .name
其他:
- 卡片驱动的同步有节流(CARD_MIN_GAP_MS 25 分钟 < 卡片刷新 30 分钟,
反了就是每次刷新都被跳过、一次都不跑)
- 设置页新增「同步」分组:开关 + 上次同步时间 + 说明
同时修:首页日程红线左侧缺一块(nowLayer 从 Row{圆点;线} 改成单个
Column 满宽 —— Row 里圆点占行首,线只能从第 5vp 起画)
守卫 1106/0、v83 反向验证 10/10 全中、已装机。
|
2026-10-24 04:25:15 +08:00 |
|
laoyang
|
1c6af8ac56
|
v79b 任务面板:补「看板」一行 + boardOf 反查兜底
真机验收时发现 boardOf() 定义了却从没被渲染,面板上看不出这条任务
属于哪个看板 —— 而「挪看板」正是 v79 新做的动作,做完看不见结果等于没做。
- infoRows() 增加 kvRow('看板', boardOf())
- boardOf() 在 base.board 为空时按 boardId 反查 boards,最后回落到「默认看板」
验证:静态守卫 1068/0(新增 ⑰ 三条)· 反向验证 222/0(新增 2 条注入)
真机探针 _fb_v79_verify.py 57/0
|
2026-10-22 18:46:04 +08:00 |
|
laoyang
|
559d79b2e2
|
v79b 端上:修 ForEach 键——改完状态卡片还显示旧状态
自查发现的隐患,**编译通过、静态断言全绿、节点也都在**,只是内容陈旧:
任务行是 `@Builder taskRow(t: FbTaskItem, …)` / `taskCard(t)` —— 入参按值传递、
不参与状态观察(本仓库文件头第 A 条反模式)。而 `ForEach` 的生成键只有
`'htk_' + t.id` ⇒ 改了状态 → 重拉列表 → `this.tasks` 换成新对象,但**键没变**
⇒ ArkUI 按 key 复用旧节点、不重跑生成器 ⇒ 卡片仍显示旧状态。
用户会看到:「面板里改成已完成了,关掉面板那张卡还是待办。」
修法:新增 `model/Types.taskKey(t)`,键里带**所有会被画到行上的字段**
(status / boardId / dueAt / overdue / childDone+childTotal / title),
首页与任务页两处 ForEach 都改用它;面板里子任务行的键也补上 `k.status`。
⚠️ 代价是状态一变这一行会重建(丢的是这一行的局部动画,不是滚动位置)。
这是刻意的取舍:**宁可重画,也不要不刷新**。
新增守卫 ⑯ 组 10 条(计数/关系型:
「键生成器必须调 taskKey」「taskKey 必须含这 6 个字段」「子任务键要带 status」),
并补 5 条反向验证注入(退回只拼 id / 漏 status / 漏 boardId / 子任务键缺 status)。
守卫 1064/0 · 反向 220/0 · 编译 BUILD SUCCESSFUL。
|
2026-10-22 17:33:32 +08:00 |
|
laoyang
|
25a0797a74
|
v79 端上:任务面板(首页/任务页共用)+ 任务模块功能补齐
用户原话:「鸿蒙端的功能,也需要同样适配,在首页上可以直接修改编辑任务,
另外任务模块的功能需要完善。」
端上原来只有"看列表 / 勾完成 / 新建改标题",网页 v78 那套「就地处理」
(改状态、挪分组、子任务、附件、留言、删除)一件都没有;首页点任务
弹的还是 v73 的只读卡。
一、新增 FbTaskPanel(首页与任务页共用同一组件)
· 改状态三段(待办/进行中/已完成)+ 标题左侧状态圈
· 挪看板 chips、勾/加子任务、加图片附件并删、发留言
· 编辑 → 交给宿主开 FbTaskEditSheet;删除要**点两次**(端上没有 undo)
· 每个动作成功后再 getTask() 重拉一次:一次动作会牵动子任务计数、
附件张数、看板色,逐处同步 DOM 必然漏一处
二、退役 FbTaskDetailSheet(v73 只读卡,387 行)
⚠️ 它已无人挂载,而守卫还在逐条"通过" —— 等于给死代码盖章。
三、任务模块补齐
· 卡片点击 → 面板(不再直接进编辑表单:误触一下就开始改标题,
且子任务/附件/留言没地方放)
· 「只看已完成」改真打 ?view=done:看板视图服务端就写死
status <> 'done',在客户端筛永远是空
· 看板列表改走 ?view=boards:原来从任务反推 ⇒ 空看板永远选不到
· 编辑表单补分类/循环两排
四、顺带修掉一个自查发现的真 bug
任务页里 sheetCount 有**两个** @Monitor 都监听 boardSheetOpen、都写同一个值
⇒ 关掉设置浮层时谁最后执行不确定,会把还开着的面板"顺便让位结束",
底部悬浮栏浮上来盖住面板按钮。已并成一个取并集的 monitor。
服务端(另一仓):新增 GET /tasks?view=boards、POST/DELETE /tasks/<id>/attach,
详情补 board_name/board_color_calc,越权删别条任务的附件 → 404。
验证:静态守卫 1055/0(新增 v79 一组,含"全页只许一个 sheetCount 赋值点")、
反向验证 215/0(新增 15 条注入,逐条证明新断言会红)、
服务端 e2e 1558/0、_fb_v79_api.py 26/0、编译通过并已装机。
|
2026-10-22 16:40:44 +08:00 |
|
laoyang
|
c7bd26dd1b
|
v77 旅程:列表只留整卡入口 + 动作区改成 2×2 + 地址不截断 + 题图
用户 2026-10-22 的五条:
① 列表卡去掉「看行程」「编辑」——「点进去之后会有编辑,直接点进去
看行程就可以」。卡尾整行删除,整卡可点变唯一入口(标题行尾留一个 ›
作提示);openEdit() 一并删掉,不留死代码。
② 详情页动作区重排——「排列得不好看,乱七八糟的」。旧版是四颗彩色实心
胶囊分两行、右端对不齐。现在 ☰ 挪到标题行右侧,四颗动作做成 2×2
等宽(layoutWeight(1));主操作保持实心,编辑/删除改浅底同色字。
配色与顺序仍是 v41 硬要求,一个 hex 都没改。
③ 出行方式:十种方式**不能增删**(网页版也只是只读 + "常用信息",
而端上加行程表单里根本没有车次/车牌,那条备忘在端上无从使用)
⇒ 方向反过来,给加行程表单补上「车次/航班号」(火车/飞机/轮船/
公交/地铁)和「车牌」(自驾,从车辆库选一台,服务端按 vehicle_id
join 出车牌)。没有这两项,"出行方式"在端上就只剩一个图标。
④ 行程详情里的地址显示不全——「从哪到哪,如果地址特别长就显示不全」。
原来出发地与到达地挤在一条 Row 里各 maxLines(1) + 省略号;
改成「从」「到」上下两行、整段铺开不截断。
⑤ 旅程题图:端上原来根本没有上传链路(服务端只有观影的 poster 槽位)。
服务端已加 POST /trips/<id>/cover;端上新建/编辑浮层加 16:9 题图选区,
流程「先建 → 拿 id → 再传图」,传图失败记 id 再点只补传(不会建出
两趟一样的旅程)。详情页空题图那块也能直接点开去加。
顺带把 multipart 上传收敛成一份(data/FbUpload.ets):原来头像 / 海报 /
观影照片各抄了一遍,旅程题图会是第四份。
|
2026-10-22 10:15:03 +08:00 |
|
laoyang
|
79e942d0e4
|
v76 旅程:信息铺得开 + 每段行程各自成卡 + 照片可点开 / 视频可播
用户 2026-10-22(四条毛病,同一个根因:信息往一行里挤):
「那个城市……如果一行显不下的话,应该显示在下边一行,把所有的城市全列出来。
就跟那个人员一样,你人员特别多的时候,一行显示不下,就直接往下放就行了。」
「点进详情之后……现在人员显示不下的话,你直接都放在右边,都溢出到这个块外面去了……
应该直接顺着往下铺就行了,所以它长一点无所谓。」
「实际行程它应该也是一段一段的,不要把它整个实际行程放在一块,
就是每一个行程都是一个一个块。然后里面的照片要可以点击查看,视频要能够播放。」
根因不是"忘了加滚动",而是 **`Row` 在 ArkUI 里不换行**:
塞不下的子节点会被压缩、或直接横向溢出父容器。四处都改成
`Flex({ wrap: FlexWrap.Wrap })`。
- `Types.ets`:`FbTripItem` 新增 `cities: string[]`(整串只能截断);
`FbTripNodePhoto` 新增 `mime` / `size`
- `FbParse.parseTrips` 新增 `cityListOf()`:优先用服务端 `cities` 数组,
只给整串时按 `·` 拆回来("显示不全"不再从别的入口漏进来)
- 列表卡:城市从「📍 一行长串 + 省略号」改成一颗颗 chip,日期单独占一行
- 详情页:城市 / 参与的人 / 每段的参与人 全部改 `Flex wrap`
(实测「黑龙江」那趟 5 个人自动排成 2 行,不再溢出卡片)
- **每段行程各自一张卡**:组头退成章节标题(不带卡片底),
`nodeCard` 自己带白底 + 圆角 + 左侧阶段色条(取 `n.stage`)
- 照片:点缩略图开全屏查看器(`PanGesture` 左右滑、上一张/下一张、关闭)
- 视频:按 `mime` 前缀认出视频(`is_image` 只有两态),缩略块 + ▶ 角标,
点开用系统 `Video` 播放(`media.php` 支持 Range,可拖进度条)
🔴 真机抓到的布局 bug:`Stack` 子节点上的 `.align(Alignment.Bottom/TopEnd)`
**完全无效** —— 关闭按钮和翻页条双双掉到屏幕正中。改成铺满的 Column +
`layoutWeight(1)` 撑开,并给控制层 `hitTestBehavior(Transparent)`
保证"点背景关闭"仍穿透。
验证:真机 33/0(含"城市 chip 数 == 统计里个城市"、"相邻行程卡有实际间隙"、
"点视频块起播放器且无放不出来");守卫 953/0;反向验证 181/0
(其中一条注入暴露了我新写断言的假绿,已改成结构化顺序判据)。
|
2026-10-22 09:02:16 +08:00 |
|
laoyang
|
8c92195558
|
v75b 详情页卡片溢出父容器(题图贴到屏幕左右边缘)
真机实测抓出来的:详情页题图 x=0..1080(满屏),而列表卡 x=50..1030。
图比下面的信息区宽 100px,左右各突 50px 贴到屏幕边缘。
根因:详情页每张卡写的是 `.width('100%')` + `.margin({left/right: pagePad})`。
ArkUI 里 `width('100%')` 量的是**父容器宽度**,margin 再往外挤 ⇒ 溢出父容器。
修法照列表页一直以来的写法:**父容器给 padding,卡片只写 width('100%')、
不写左右 margin**。改了三处:heroCard、nodeGroups 空态、stageGroup。
实测:详情题图 x=50..1030 (w=980),与所属卡片 50..1030 完全对齐。
探针 24/0,守卫 932/0,反向验证 165/0。
|
2026-10-22 08:07:05 +08:00 |
|
laoyang
|
3e2904cc3d
|
v75 旅程重构:列表页 + 详情整页,卡片改「图在上、信息在下」
用户 2026-10-21:
「每一个旅程里面的行程才是重头戏……点击一个旅程,应该进入到一个新的界面,
在里面列出所有的行程,就跟网页版的一样。
这个旅程的图片是比较重要的……图片在正上方,就是充满整个的这个列表的宽度。
然后呢把这个标题还有其他的一些信息放在下面。如果是图片放左边,信息放右边的话,
它总是被挤占,显示不全。……想看其他的这个旅程的话,直接往下滑就可以了。」
- 新建 `pages/trips/FbTripDetailPage.ets`(照 `trips/show.php`):题图 16:9 占满整宽、
五项统计、行程按 计划/实际/未成行 三组(空组不显示)、页头两行动作区
(+计划=蓝 / +实际=绿 / 编辑=黄 / 删除=红 / 设置)
- `FbTripsPage` 846→573 行:删掉就地展开全套,`tripCard` 改「题图在上、信息全在下面」
卡尾「看行程」自己带 onClick,整卡也可点
- `Types.ets` `FbTripNode` 8→18 字段 + 四个新类型;`FbTripRepo` 新增
`fetchTripDetail` / `fetchTripSummary` 与四个解析辅助
- 修真 bug:`parseNodes` 读 `expense_cent`,服务端写的是 `spent_cents`
⇒ 每段「💰 这一段花了」从来没显示过
- `Store.ets` 新增 `@Trace tripDetailId` 与 `leaveTo(parentKey)`:
删完整趟回列表要走它(内部 `applyModule` 会 `resetScroll`),
直接赋 `activeModule` 会让回列表后轻轻一滑就收起悬浮栏
- 接线:`Index` 分发 / `TopBar` 标题「旅程」/ `Modules.fbModuleColor` 归到 trips 色
- `FbTripNodeSheet` 新增 `@Param startStage` 预选阶段(选择器保留,点错还能改)
守卫 931/0,反向验证 164/0,编译 BUILD SUCCESSFUL,真机待设备连上后跑 _fb_v75_verify.py
|
2026-10-22 00:07:16 +08:00 |
|
laoyang
|
6e7cdaf5fc
|
v74 端上删掉家谱 + 名册页头改「醒目搜索 + 添加」
用户 2026-10-21:「算了,你画不好。这个功能直接从鸿蒙端去掉吧,不要了。
这样名册这个功能,进来以后,上面就是搜索和添加按钮,搜索,做的醒目一点,
现在看不清。家谱和名册的标签,都不要了。家谱的相关功能,都删除。」
家谱链路整条删除(不是隐藏):
- 删 common/KinLayout.ets、components/FbKinGraph.ets 两个源文件
- 删 Types 的 FbKinPerson / FbKinGraph / FbKinRelation、FbParse 的 parseKin
- 删 FbModuleLoad 路由、FbModuleRepo 模块名、FbSyncAll 预同步清单里的 kin
- 删 DemoData 的 FB_DEMO_KIN_RELATIONS、Theme/Settings 的家谱图标映射
- 删死资源 fb_ic_kin.png
- Index 的 kin 分支去掉(不再有「名册/家谱」两个模块共用一个页面)
- FbPeoplePage:删 subView 分段切换、kinHeader/kinView、loadKin、segBtn;
openDetail 不再借家谱字段兜底,改成纯 id 占位 + 异步补全
(保留"本地没缓存也要立刻开浮层",那是 v73 修过的"点了没反应")
名册页头:
- 第一行就是搜索 + 添加,上面不再有任何东西
- 搜索框从「看不清」改成醒目:白底 #FFFFFF(原来 inputBg 与页面米色几乎同色
⇒ 没有边界)、1.5 主题色描边、高度 36→44、图标 15→18 并染主题色、
字号 fontSmall→fontBody、提示词收短成「搜索姓名 / 首字母 / 手机」
验证:
- ArkTS 静态守卫 917/0(新增 6 条:家谱五条链路全清 + 搜索框三个具体数值)
- 反向验证 154/0(新增 7 条注入全部有效;另修好两条因代码演进失效的旧锚点)
- 编译 BUILD SUCCESSFUL + 装机 install bundle successfully
- 真机 v74 探针 22/0(高度实测 44.2vp、白底、占屏 66%、同排对齐、
家谱在页面与抽屉里都不存在、搜索输入与清空真的生效)
顺带修掉探针三处假红(都不是应用问题,是量错了节点):
- 搜索框在界面树里是两层,TextInput(75px) 只是内部输入区,
白底容器 Row(138px) 才是盒子;只按"有文字/可点"收集会把它漏掉
- uitest uiInput inputText 是 (x,y,text) 三参数,只给文本会静默不输入
- 空态文案是「换个关键词试试…」,按"没有/找到"判永远为假
|
2026-10-21 23:28:19 +08:00 |
|
laoyang
|
8cabc35400
|
v73b:家谱连线改成「每对父母一条母线」,去掉重合的横段
旧画法每个子女各画一条独立折线,在真实数据上会画出两条横段完全
重合的线(岳父母→我户 216→72 与 我父母→姐户 72→216,拐点同为
132.9),视觉上是一个「口」字框,看着像父母家和岳父母家连在一起。
新画法:父母单元中点 ──竖──→ 母线高度 ──横(只覆盖自己子女)──→
各子女 ──竖──→ 子女卡片上沿。一条线只服务一对父母,不再交叉重叠。
关键修正:子女挂点必须是**子女本人那张卡**,不是「子女所在户的中点」。
我这一户同时是两对父母的子女户(我父母→我、岳父母→妻子),
用户中点时两条竖线都落在 x=72、完全重合;改用本人卡的 x 后
妻子那条落在 105,两条线才分开。
⚠️ 这类病端点断言完全抓不到(端点都好好贴在卡片上),所以测试侧
新增「没有任何两条线段完全重合」,并在视图侧说明 bus 段是同一折线
公式的退化情形、不必单独写分支。
验证:离线 30/0、反向 13/0、真实数据+屏幕对照 11/0、
像素级 9/0、真机几何 15/0、ArkTS 守卫 905/0。
|
2026-10-21 22:57:56 +08:00 |
|
laoyang
|
13f716c936
|
v73:家谱自绘重做(Canvas 画线 + 原生卡片),去掉列表只留图谱
用户原话:「手机端这个家谱实在是很难看,能有什么库之类的,让它好看点吗」
改法:不再全 Canvas 手绘(只有彩色圆点 + 首字,中文又平又硬、做不出圆角阴影),
改成「Canvas 只画线 + 原生 Column/Text/FbAvatar 绝对定位」。
不能改用 Path 组件:Path.commands 单位是 px,而 .position() 是 vp,混用会缩 1/3;
Canvas 绘制坐标系本身是 vp,与 .position() 自洽。
布局算法抽成纯函数 common/KinLayout.ets(可单独验证,不再和"画"揉在一起):
- 横向单位是「夫妻单元」而不是「人」,夫妻并排紧邻
- 子女挂在夫妻单元中点下方(family-chart 语义)
- 迭代松弛 24 轮容纳冲突约束(家谱不是树:姻亲的"挂父母下方"与"夫妻并排"互相打架)
- 全程确定性(排序带 minId 兜底),避免每次重画卡片抖位置
真机抓到并修掉两个真 bug:
1. 户号 0 被当成"没分户":服务端 unit_of 从 0 编号,端上判 > 0
⇒ 我与妻子被拆两户(真机 Δx=680px)。修:布局层 >= 0,解析层缺失给 -1,
不把任何数值当哨兵。
2. 线没连对(用户原话「主要是线没连对」):buildBloodEdges 用 gen 数值当行号,
minGen=-1 ⇒ 长辈线从 y=-148 起(屏幕外),整组线串到上一代卡片。
修:新增 rowIndex(gens, gen),用走标换算而不是数值。
验证:
- 离线布局 29/0(含户号 0、脏数据一户三人、镜像常量与端上源码一致)
- 反向验证 11/0(9 处注入,含"户号 0 当没分户"与"用 gen 数值当行号"两条真 bug 复现)
- 真机几何 15/0、真实数据+屏幕对照 9/0(反解密度 3.125x,残差 0.23/0.32px;
12 个血缘线端点全部贴在卡片上下沿)
- ArkTS 静态守卫 905/0
|
2026-10-21 22:18:43 +08:00 |
|
laoyang
|
67ce443915
|
v73b:给卡片刷新加一条可观测的日志(排障用,不改变行为)
真机排障时发现:修复前 pushAll 在注册表为空时是**静默 return**,
hilog 里一个字符都抓不到 ⇒ 出现"卡片不刷新"时只能一路读代码反推
(v73 的跨进程 preferences 根因就死在那行 return 上)。
现在留两条:
· 为空 → warn,明确说"注册表为空(没卡片 或 跨进程没读到)"
· 推完 → info,报"已推 N 张卡(M 种偏移)"
真机实测:勾一次任务后日志出现
pushAll:已推 4 张卡(1 种偏移)
⇒ 应用进程确实读到了卡片进程写下的 4 个 formId。
|
2026-10-21 20:13:28 +08:00 |
|
laoyang
|
48a0507455
|
v73:桌面卡片刷新修复 + 首页日程/任务就地弹详情卡 + 一键导航
用户 2026-10-21 三条:
「卡片里面的数据并不刷新……应用里面的日程已经有了,但卡片上的日程却并不刷新」
「首页上的那个日程和任务,点击之后都应该像日程和任务里面的卡片一样弹出来,
不要进入到日程里面……有地址的还可以直接一键导航」
「任务也是一样,点击任务之后弹出来详情,可以标记它是不是完成了」
① 卡片不刷新(根因)
卡片进程(FormExtensionAbility)与应用进程靠 preferences 传 formIds / 翻页偏移。
SDK 明文禁止跨进程用 preferences,且 getPreferences() 在**进程内**缓存实例、
同名再取不读盘 ⇒ 应用进程可能永久持有空注册表 ⇒ pushAll() 首行
`if (list.length === 0) return` 直接返回 ⇒ 卡片只靠系统 30 分钟自刷。
修:store() 每次先 removePreferencesFromCacheSync 再取;并写死单写者纪律
(register/unregister/setOffset/clearOffset 只由卡片进程调,应用进程只读)。
② 首页点日程 → 弹 FbEventSheet(canEdit: false,首页不给编辑入口)
有地址的行整行可点 + 右侧「➤ 导航」胶囊;「编辑日程」才跳日历模块
(编辑是日历页的职责,不在首页复制第二份表单)。
③ 首页点任务 → 新的 FbTaskDetailSheet
状态圆可点(勾完成)、标题带删除线、底部「标记为已完成/未完成」+「改一改」。
状态**必须走 POST /tasks/<id>/status**(PATCH 会忽略 status)。
④ 一键导航 FbNav.ets:startAbility 隐式 Want(不是 openLink,那是 App Linking);
canOpenLink 需 module.json5 声明 querySchemes(未声明恒 false 且不抛错);
高德/百度/花瓣/腾讯按序探测,一个地图都没装则复制地点到剪贴板 + Toast。
⑤ 首页登记 FB_BACK(与其余 10 个模块一致),根容器 Stack(浮层是兄弟节点,
不能当 Column 子项排,否则卡片被挤出屏幕)。
静态守卫 905/0、v73 反向验证 17/0、assembleHap 通过、已装机启动。
|
2026-10-21 20:01:37 +08:00 |
|
laoyang
|
15bc3c8599
|
v69b:大卡抬头「星期 + 农历」合成一行(真机上第二行被 Divider 切掉半截)
真机截图看到 4×4 卡的抬头是「10月20日」下面压着半截字(看着像"一十三"):
原来是 12sp 日期 + 9sp 农历**两行**,4×4 卡高度紧,
第二行被下面的 Divider 压掉了一半。
⇒ 四处统一走 `subLine()` 拼成一行(`星期二 十一`):
2×2 / 2×4 本来就是单行、真机上是正常的,大卡跟它们对齐。
守卫加 v66 ⑭(四块卡都必须走 `subLine()`,且不许退回"农历有值就吞掉星期"的写法),
反向验证加一条注入(把 4×4 改回 `Text(this.lunarText)` ⇒ 守卫变红)。
|
2026-10-20 22:09:51 +08:00 |
|
laoyang
|
719c68202b
|
v69:日程桌面卡片完全照 SyncCalendar 重做(四种尺寸 + 翻页 + 时间轴)
用户 2026-10-20:「跟日程有关的桌面服务卡片,你就完全按照 synccalendar 来做就行。」
上一版卡片是"首页概览"(今日日程 + 在做/待办/逾期 + 纪念日),
是照着首页数据自己设计的版式。这一批按用户要求换成 **SyncCalendar 那套日程卡**:
## 四块尺寸(与 SyncCalendar 一一对应)
- 2×2 日期 / 星期+农历 / 当天条数大数字 + +
- 2×4 左半同 2×2,右半「接下来两条」
- 4×4 `‹ 10月20日 / 九月初一 › [今|+]` + 当天日程(时间轴 / 列表)
- 6×4 同 4×4,更宽(小时 40vp)
## 翻页(这是"照 SyncCalendar"的核心)
- 卡片按钮走 `postCardAction({action:'message', params:{pageAction}})`,
`FbFormAbility.onFormEvent` 改偏移 → 重新取数 → 推回卡片;
- **每张卡一份偏移量**,落 `preferences`(`data/FbCardForms.ets`):
SyncCalendar 只放内存 Map,进程被回收就丢 ⇒ 系统每 30 分钟刷新一次,
会把用户翻到的"下周三"悄悄拽回今天。家书这边连 `updateDuration` 的定时刷新
也按各自偏移重建(`onUpdateForm` 先 `getOffset` 再 `push`)。
- 偏移夹取 ±366 天:message 是外部输入,算到离谱年份会 Invalid Date(白卡)。
## 点卡片要落到"卡片显示的那一天"
- 卡片 router 带 `openDate`(**毫秒字符串**,数字参数是 int32,13 位会溢出)
与 `widgetAction=add`(点的是+);
- `EntryAbility.applyWantModule` 解析后写 `FbAppState.calJumpIso/Create/Seq`;
- 日程页两条入口都接上:冷启动 `aboutToAppear`、热启动 `@Monitor('app.calJumpSeq')`
(应用开着时点卡片不会重建页面,只靠 aboutToAppear 会"点了没反应")。
## 数据
- 换接口:`/api/v1/calendar?from=<那天>&to=<那天>`(原来打 `/home`)。
`authProbe: true` + 显式带 token 的硬要求不变(后台 401 不能把用户踢下线)。
- 农历行(`kind=lunar`)抽成抬头那一行小字,其余衍生条目(节气/节假日)照常进列表。
- 时间轴复用 `common/FbTimeline`(与日程页同一套算法),
卡片侧只做"比例 → vp"的换算(`fbCardTlLines`,纯函数、可断言)。
- 显示方式(时间轴/列表)跟「日程设置」联动;今天才画当前时间红线。
- 应用内改完日程 → `FB_CARD_FORMS.pushAll()` 立刻刷新桌面卡片
(不必等 30 分钟;推失败自动注销该 formId)。
## 验证
- `assembleHap` BUILD SUCCESSFUL;已装机(5NC0225B27004718)。
- `_fb_arkts_guard.js` **856 / 0**(v66 组按新契约重写:四尺寸登记、
字段名与数据类配对、数组必须 JSON 字符串、翻页三动作、
`onUpdateForm` 按偏移重建、冷/热启动两条入口)。
- `_fb_v59d_falsify.py` **146 / 0**(新增 6 条注入:定时刷新丢偏移、
偏移不落盘、4×4 少「下一天」、「热启动不响应」、不读 openDate、
字段名拼错、去 authProbe)。
⚠️ 其中"热启动"那条第一次注入**打偏了**:它先命中了文档注释里那半句
`@Monitor('app.calJumpSeq')` ⇒ 真正的装饰器没被改,守卫照样绿。
已把字面量从注释里去掉(本项目"注释里别抄字面标签"的老坑)。
- 真机跳转 `_fb_v69_card_jump.py`:
· `openDate=今天+3天` + `widgetAction=add` ⇒ 日程页落在 **10月23日**,
且「新建日程」浮层打开、日期就是 10月23日(dump 里 26 个浮层节点);
· 只带 `openDate` ⇒ 同样落在 10月23日,**不**弹新建浮层。
|
2026-10-20 21:59:23 +08:00 |
|
laoyang
|
030a9c7fbb
|
v68 真机验收:修两处真机才暴露的问题(账本权限标签 / 查看行程点不动)
设备接上后第一次真机验收(5NC0225B27004718),25 条断言里抓到两个**真 bug**:
## ① 主人账本也挂一颗「可写」
账本切换条的判据是 `if (b.myPerm !== 'owner')`,而服务端 `Ledger::mine/find`
**从来不给 `owner`**(主人也是 `write`)⇒ 这个 if 恒成立,自己建的账本
也被贴上「可写」,看着像"只是别人共享给我的"。
v68 上一批已经把共享浮层改成 `isOwner`,但这处列表标签漏了 ——
同一批里 `myPerm` 的注释还写着 `owner/read/write`,属于照着错误注释抄。
⇒ 改 `if (!b.isOwner)`,并把那段过期注释纠正。
## ② 卡尾「查看行程」是一颗点不动的字
屏幕上明明写着「查看行程」,点它**什么都不发生** —— 因为展开逻辑只挂在
**卡片主体**的 onClick 上,卡尾这颗 Text 是纯文本,没有 onClick。
用户看不到"要点头像/标题",只会去点这三个字。
⇒ 展开逻辑抽成 `toggleExpand(trip)`,卡片主体与卡尾文字共用;
卡尾那颗补 onClick 并加内边距(fontTiny 的纯文字热区太小,真机不好点)。
## 验证
- 真机验收 `_fb_v68_verify.py`(v66~v68 三批):**25 通过 / 0 失败**
(改前 19/6 → 修完 25/0;A2、C2/C3/C4 由红转绿)
- `_fb_arkts_guard.js` → **832 / 0**(新增 v68 ③ 两条、v66 ⑫ 三条)
- `_fb_v59d_falsify.py` → **141 / 0**(新增 2 条注入,都能让守卫变红)
⚠️ 「查看行程」那条注入第一次写的是"往后 500 字符内找 .onClick",删掉 onClick
守卫**照样绿**(500 字符内还有「编辑」那颗)⇒ 改成按段切(Text → 下一个 Column())。
|
2026-10-20 21:35:38 +08:00 |
|
laoyang
|
2ff90519fa
|
v68:财务补齐(改一笔/删一笔/账本改名/共享给谁)
用户 2026-10-20:「还有这个财务的显示也有问题」——v65 修的是**显示口径**
(端上按正负号重加 vs 服务端负债取绝对值);这一批补的是**动作**:
设置里「共享给谁」「账本名字」一直是灰条,账目也改不了删不掉。
## 根因:不是端上没写,是服务端没有路由
`Ledger::rename / setShare / unshare / shares / updateEntry / removeEntry`
**一直都有**,`ApiHandler::ledger()` 却只开了「建账本 / 记一笔 / 删账本」
⇒ 端上只能把这两条画成"暂未开放"。
## 端上做了什么
- 点一行账目 → 同一个浮层进**编辑态**(类别 / 金额 / 名称 / 备注 +
删除二次确认)。`aboutToAppear` 里把 @Param 拷进 @Local,
点第二行才不会还是上一笔的内容。
- 设置「账本名字」→ 改名浮层;「共享给谁」→ 共享浮层(列表 + 选人 +
逐个人取消)。列表解析走 `{items:[…]}`(`FbApiResult.data` 是原始 JSON)。
- 三个浮层共用 `recountSheets()` 让悬浮栏让位(原来只有"记一笔"有)。
## 顺手修的两处「对着服务端抄错」
1. `FbLedgerBook.myPerm` 的注释写 `owner / read / write`,
而服务端**从来不给 `owner`**(主人也是 `write`)⇒ 端上"是不是我建的"永远 false。
现在用服务端新补的 `isOwner` 布尔。
2. `FbLedgerEntry` 没有 `note` 字段 ⇒ 编辑时备注框永远是空的。补上类型与解析。
## 顺带
- 撤掉名册家谱那颗「补关系」按钮:从来没有 `onTap`,服务端 `relations`
只有读接口、网页版也没这个功能 ⇒ 留个永远点不动的按钮只会被当成"坏了"。
## 验证
- `hvigorw assembleHap` → BUILD SUCCESSFUL
- `_fb_arkts_guard.js` → 827 / 0(新增 groupV68 29 条)
- `_fb_v59d_falsify.py` → 139 / 0(v68 新增 9 条注入全部变红)
- ⚠️ 设备仍断连(`hdc list targets` → `[Empty]`),真机未验收
|
2026-10-20 20:18:38 +08:00 |
|
laoyang
|
ec2cb14c4c
|
v67:读书模块补齐(书能点进去 / 加一本 / 读书笔记 / 统计)
用户 2026-10-20:「其他的功能也逐步完成……读书点不进去,也没法加书,
设置也没有任何的东西。」
## 先修三处「对着服务端抄错的口径」(都不报错,只是显示是错的)
1. 状态值:服务端 `Book::STATUS` 只有 wish/reading/done/paused,**没有 want**;
`Book::status()` 遇到不认识的值会静默改成 `wish`,而端上分组键写的 `want`
⇒ 书架里「想读」那一组**整组不显示**(页头还数着它,看着像书丢了)。
`paused`(搁置)同样没列 ⇒ 搁置的书也人间蒸发。
2. 评分:服务端 `rating` 是 0–10,端上当 0–5 用 ⇒ 8 分显示成 `8.0/5`。
现在解析时折半、写回时 ×2。
3. 进度:服务端 `progress` 是「读到第几章」,端上当百分比 ⇒ 读到第 30 章 = 30%。
现在按 `chapter_count` 换算,没解析过章节的书不画假进度。
## 补齐三个死掉的入口
- 书行整行可点 → `FbBookSheet`(状态 / 评分 / 章节进度 / 读书笔记 / 删除二次确认)
- 页头「+ 加一本」→ 同一浮层的新建态(书名 / 作者 / 状态)
- 设置「读书统计」→ 端上现算(藏书/在读/读完/想读/搁置/笔记条数);
另两条(导入笔记 / 微信读书)要文件选择与授权,仍标「网页端」,不摆假入口
## 服务端能力边界(照实做)
- `PATCH /books/<id>` 只认 status / rating ⇒ 详情里不给改书名/作者的输入框
- 章节进度只读(`progress` 由阅读器翻页写,接口没有回写入口)
- 读书笔记走真实接口 `GET/POST /books/<id>/notes`
## 验证
- `hvigorw assembleHap` → BUILD SUCCESSFUL
- `_fb_arkts_guard.js` → 797 / 0(新增 groupV67 28 条,含「端上分组键 ==
服务端枚举」的跨语言对照)
- `_fb_v59d_falsify.py` → 130 / 0(v67 新增 13 条注入全部变红)
- ⚠️ 设备仍断连(`hdc list targets` → `[Empty]`),真机未验收
|
2026-10-20 17:14:40 +08:00 |
|
laoyang
|
58f5509c1c
|
v66 续:旅程三项设置(车辆管理 / 出行方式 / 节点类型)
用户 2026-10-20:「旅程的……车辆管理、出行方式、节点设置,这些东西都还没完成。」
这三项的 `action` 一直是**空串**(点了没反应),是本次批量需求里最后一块。
三项的真实能力并不一样,按真实情况做,不摆假入口:
· **车辆管理**:`vehicles` 表 + `Vehicle::save/destroy` 早就有,缺的只是 API
⇒ 新增 `GET/POST/PATCH/DELETE /api/v1/vehicles`;端上列表 + 内嵌表单
(车型 / 车牌 / 自家·租的·借的 / 车主或租车公司 / 订单号 / 默认车 / 备注)
· **节点类型**:`node_types` 表 + `NodeType::save/destroy` 同理
⇒ 新增 `GET/POST/PATCH/DELETE /api/v1/nodetypes`;改名会**级联**到已有行程
(`trip_nodes.node_type` 存的是名字,服务端 `NodeType::save` 里做)
· 内置类型**不画删除按钮**(服务端会拒,画了就是"点了没反应")
· **出行方式**:**枚举常量**(`Trip::TRAVEL_MODES`),没有"管理"这回事
⇒ 只做一份只读对照表 + "加行程时选",**不做可编辑表单**
(反向验证里有一条专门锁"这个浮层里不许出现保存/删除")
几个实现上的要点:
· 两条新路由是**平级资源**(`/vehicles`、`/nodetypes`),不是 `trips/xxx` 子路由 ——
`Api::dispatch()` 只解析三段,写成四段会落到「trips 的第 0 条」= 列表
· 删不掉(还有 N 段行程在用 / 内置类型)回 **422 + 服务端原话**,不是 500:
那是"现在不能删",不是"服务器出错"
· 表单输入框**不按值传 value**:`@Builder` 的值参数不参与状态观察,
而这个浮层是"列表 + 内嵌表单"(点另一行的「编辑」时表单已经渲染着)
⇒ 会显示上一辆车的内容。改成传 key、builder 内部直接读 `this.fXxx`
· 三个浮层都遵守浮层铁律(根 `Stack` 叠放 + `hitTestBehavior(Transparent)`),
各挂一个 `@Monitor` 让底部悬浮栏让位;`backOnce()` 按层级顺序关
服务端(`app/ApiHandler.php`)已随 `familybook_push.sh` 部署,线上核对:
`/api/v1/ping` 的 features 里 `trips_vehicles` / `trips_nodetypes` 均为 1,
两个端点无令牌时回 **401 unauthorized**(说明路由存在,而不是 404 not_found)。
验证:`hvigorw assembleHap` BUILD SUCCESSFUL;静态守卫 769 条全绿;
反向验证 116 条注入全部能让守卫变红(含"字段名拼错""按值传 value"等假绿陷阱)。
⚠️ 设备仍断连,真机未验收。
|
2026-10-20 16:36:30 +08:00 |
|
laoyang
|
b3e1330244
|
v65/v66:六个空壳模块接线 + 桌面服务卡片
用户 2026-10-20:
「做几个和 syncCalendar 差不多的卡片。另外其他的功能也逐步完成……旅程的
新建旅程啊,车辆管理、出行方式、节点设置……资源也点不进去……任务也点不
进去,也没法完成……纪念日、新增纪念日……财务的显示也有问题……笔记现在
也点不进去,记笔记也记不了。」
v65 —— 六个模块(任务 / 资源 / 纪念日 / 笔记 / 账本 / 旅程)原本是**同一套
空壳模板**复制出来的:`FbPrimaryButton` 没有 `onTap`、`ListItem` 没有
`onClick`、设置菜单的 `action` 全是空串。这一版把它们全部接上真实接口:
· 任务:新建 / 编辑(`FbTaskEditSheet` + `FbTaskRepo`)、列表可点、勾完成
(走 `/tasks/<id>/status` —— 服务端 `PATCH` **显式忽略** status,走 Patch
会得到"看起来成功的假成功")、按看板筛选
· 资源:新增 / 查看 / 改 / 删(`FbResourceSheet` + `FbResourceRepo`);
过滤维度从**并不存在的**「证件 / 资料」改成按权限与归属
(`resources` 表没有 category 列,那个筛选一直是筛空的)
· 纪念日:新增 / 编辑(`FbDayEditSheet` + `FbDayRepo`);派生生日
(id=0、来自名册)只给提示不给编辑 —— 点开 `/days/0` 必然 404
· 笔记:记一条 / 打开 / 改(`FbNoteSheet` + `FbNoteRepo`),正文按 blocks 存
· 账本:记一笔(`FbLedgerEntrySheet` + `FbLedgerRepo`);修掉财务显示自相
矛盾 —— 资产/负债改回**服务端 summary**(原来端上按金额正负号重算,与
服务端"负债取绝对值"的口径打架,会算出 净资产 ≠ 资产 − 负债)
· 旅程:题图卡片(封面 + 标题 + 城市)+ 行程 + 新建旅程 + 新建节点
服务端同时修掉两处**静默数据丢失**(网页端因提交格式凑巧没暴露,只有走
API 的客户端会中招):
· 新建笔记传的是 `body`,而 `Note::create()` 只读 `blocks` ⇒ 新笔记只有标题
· 改笔记时 `blocks` 恒为空,而 `Note::update()` 是整组替换 ⇒ 只改标题就把
正文全删光;另修 `annivPeopleOf()`(`find()` 的 SQL 不含 people,原来那个
兜底恒为空 ⇒ 只改纪念日标题会清空关联人)
v66 —— 桌面服务卡片(用户选了「桌面服务卡片」这一项):
· `FbFormAbility`(FormExtensionAbility)+ `form_config.json` 三块尺寸:
2×2 今日概览 / 2×4 左右分栏 / 4×4 今日全景
· `FbCardData` 只打 `/home` 一个接口(与网页首页同源),数据**扁平化**后
由 `formBindingData` 推给卡片;断网时用上次成功的缓存并注明"离线"
· 卡片是后台进程 ⇒ 请求带 `authProbe: true`:401 **不能**触发全局"踢回
登录页"(那会顺手把正在用应用的人踢下线,v62 那次事故同一个坑)
· 点卡片 → `postCardAction(router, fbModule)` → `EntryAbility` 读 Want 参数
直接落到对应模块;补了 `onNewWant`(没有它,第二次点卡片"什么也没发生")
· 4×4 右上角 ↻ 走 `postAction(message)` → `onFormEvent` 重取数再推回
验证:`hvigorw assembleHap` BUILD SUCCESSFUL;打包后的 hap 里确认
`FbFormAbility`(type=form)与 `$profile:form_config` 都在,卡片代码进了
`ets/widgets.abc`。静态守卫 730 条全绿,反向验证 110 条注入全部能让守卫变红。
⚠️ 设备仍断连(`hdc list targets` 为空),真机尚未验收。
|
2026-10-20 15:27:32 +08:00 |
|
laoyang
|
3b7238a418
|
v64b:修真机弹层"点了没反应"(根容器 Column → Stack)+ 日期行热区
四个日期/选择类浮层在真机上**完全打不开**:编译无告警、`aboutToAppear` 照常调用、
`dumpLayout` 里连弹层一个节点都看不到、点它会"穿透"到底下的列表。
根因(逐层二分定位):根容器写成 `Column` 且里面**先排一个整高遮罩**
(`Column().width('100%').height('100%').backgroundColor(FB_MASK)`)再排卡片。
`Column` 是**线性**布局 ⇒ 遮罩占满整高后,卡片被排到屏幕**外面**。
⇒ 全屏遮罩与卡片要"叠"(`Stack`),不能"排"(`Column`)。
改动:
- FbDateTimeField / FbCinemaPickSheet / FbPersonPickSheet:根容器改
`Stack({ alignContent: Alignment.Center })`,遮罩与卡片作并列子项叠放;
去掉原先用于"居中卡片"的 `justifyContent(FlexAlign.Center)`(Stack 已对齐)。
- FbDateTimeField:「日期行」的 `.onClick` 由内层 `layoutWeight(1)` 的 Row
挪到**根 Row** —— 挂内层时那一行会被表单所在的**两列容器**盖住,
点击穿透到底下的观影列表(表现为"点日期行,列表反而响应了")。
- FbSheetClose:`onClose` 由 `@Param` 改 `@Event`(语义归位;实测 `@Param`
声明回调**并不会失效**,✕ 一直是能点的 —— 这不是本轮 bug 的根因,别混为一谈)。
验证:
- 构建 BUILD SUCCESSFUL;
- 静态守卫 644/0(新增 8 条:三个组件的 Stack 叠放 + 整高遮罩非空转 +
全项目无"根 Column 先排整高遮罩"坏形态 + 日期行热区在根 Row);
- 守卫反向验证 92/0(新增 6 条注入,含把根 Stack 改回 Column、删遮罩、
热区挪回内层,逐条证明断言真会红)。
|
2026-10-20 08:55:27 +08:00 |
|