HarmonyOS应用实战-启示散页-19-空态不是一句暂无数据给题库、收藏和历史分别设计可恢复入口这一组文章继续围绕The_Book_of_Answers展开。它不是一次性页面 Demo而是一个小型 HarmonyOS 离线应用默认题库从 rawfile 播种题库、收藏、历史写进 Preferences抽取流程经过 DrawingPage发布前还要说明隐私、备份、包体和日志口径。轻量应用最容易被误判为“页面写完就结束”。实际交付时真正拖慢排障的通常不是某个 ArkUI 组件而是状态从哪里来、数据由谁写、页面靠什么刷新、异常能不能恢复。下面每篇只拆一个问题并尽量把它落到答案之书已有的页面、Service、Repository、AppStorage、资源或发布配置边界上。这篇文章解决四件事复盘空态不是一句暂无数据在答案之书项目里怎么出现。把给题库、收藏和历史分别设计可恢复入口落到页面、Service、Repository 和 AppStorage 的具体边界。给出能迁移到 HarmonyOS/ArkTS 项目的代码形态并指出反例。用验证清单和排障表收尾避免只看源码不看实际入口。1. 从故障链路看空态不是一句暂无数据答案之书有多种空首次没有自建题库、没有收藏、没有提问历史、当前题库损坏。它们都显示“暂无数据”会让用户不知道是正常状态还是出错。 这个问题如果只在当前页面补一个判断短期可能能跑但下一次从历史、收藏、分享或恢复入口进入时同样的问题还会出现。先把故障链路写出来才能知道该修页面、服务还是持久层。触发点空态不是一句暂无数据 错误写法页面直接判断或直接读写持久化数据 放大后果返回重进、前后台切换、删除/恢复、发布排查都会看到旧状态 收口位置EmptyStateFactory 处理业务规则FavoritePage 只消费结果态 刷新方式业务动作成功后写 AppStorageKey.LastEmptyActionAt2. 先把边界表写清楚空态应该由业务层生成模型页面只渲染标题、说明和主操作。不同空态的下一步不同题库空态去导入或新建收藏空态回抽取页历史空态回首页输入问题。 这张表的作用是防止后面写代码时顺手越界。尤其是答案之书这种本地应用很多问题看起来都能在页面里临时解决但页面一旦知道太多存储细节发布后的排障成本会明显升高。层级在这篇里的职责不应该做的事FavoritePage展示、点击、跳转、订阅刷新信号直接拼 Preferences key 或修复脏数据EmptyStateFactory校验输入、组装EmptyStateModel、决定空态和恢复路径持有 ArkUI 组件状态DeckRepository稳定读写本地实体和索引判断页面怎么展示AppStorage传递AppStorageKey.LastEmptyActionAt这类轻量刷新信号保存完整业务对象3.EmptyStateModel只表达页面结果不照搬存储实体EmptyStateModel是给FavoritePage消费的结果模型不是 Preferences 里的原始结构。这样做的好处是Repository 可以继续按本地存储优化字段页面仍然拿到稳定、可渲染、可判断动作的结果。interfaceEmptyStateModel{kind:deck|favorite|history|broken;title:string;description:string;primaryAction:EmptyAction;}4.EmptyStateFactory才是规则 ownerEmptyStateFactory负责把DeckRepository读出的数据转成页面能用的结果。空值、损坏、回退和默认值都应该在这一层处理页面不需要知道底层为什么缺字段。classEmptyStateFactory{asyncload(deckId:string):PromiseEmptyStateModel{if(kindfavorite){return{kind,title:还没有收藏答案,description:抽到值得留下的答案后可以在结果页点收藏。,primaryAction:{label:去抽一个答案,route:RouteName.Drawing}};}return{kind,title:还没有题库,description:可以导入一段文本也可以先使用默认题库。,primaryAction:{label:导入题库,route:RouteName.ImportPreview}};}}5.FavoritePage不直接碰持久化FavoritePage的职责应该保持轻进入时加载收到信号时重载用户点击时发起明确动作。这样页面不会同时背上 Preferences、业务规则、错误恢复和发布排查四种职责。Componentstruct FavoritePage{StateprivateemptyStateModel:EmptyStateModel|nullnull;StorageLink(lastEmptyActionAt)Watch(reload)privatechangedAt:number0;privatecurrentDeckId:string;asyncaboutToAppear():Promisevoid{awaitthis.reload();}privateasyncreload():Promisevoid{constdeckId:stringBookRouteGuard.requireDeckParam({deckId:this.currentDeckId});this.emptyStateModelawaitnewEmptyStateFactory().load(deckId);}}6. 反例把所有逻辑塞回页面会怎样这个反例在第一版开发时很常见因为写起来快但它把题库读取、空态判断、展示模型转换和刷新信号都揉在组件里。后续一旦增加 Sheet、深链、恢复页或平板布局就会出现多个入口行为不一致。// 反例页面同时知道数据结构、业务规则和刷新方式constdeckawaitDeckRepository.loadDeck(this.currentDeckId);if(decknull){promptAction.showToast({message:暂无数据});return;}this.emptyStateModeldeckasunknownasEmptyStateModel;AppStorage.setOrCreate(AppStorageKey.LastEmptyActionAt,Date.now());7. 刷新信号只写AppStorageKey.LastEmptyActionAt不要广播完整对象AppStorageKey.LastEmptyActionAt是运行期联动不是数据仓库。业务动作成功后只写一个时间戳页面收到后再按自己的 owner 重拉数据可以避免跨页面共享可变对象。classBookRefreshCenter{staticnotifyEmptyStateModelChanged():void{AppStorage.setOrCreate(AppStorageKey.LastEmptyActionAt,Date.now());}staticasyncafterBusinessAction(action:()Promisevoid):Promisevoid{awaitaction();this.notifyEmptyStateModelChanged();}}8. 入口参数要先校验再进入业务答案之书的入口不只首页一个历史再次提问、收藏再次提问、分享导入、恢复页都可能进入RouteName.ImportPreview。目标页先校验参数错误进入可恢复路径不要让空 deckId 流到 Service 深处才爆出难懂异常。classBookRouteGuard{staticrequireDeckParam(param:object|undefined):string{constdeckId(paramasRecordstring,string|undefined)?.deckId??;if(!deckId){thrownewError(缺少题库 id不能进入 RouteName.ImportPreview);}returndeckId;}}9. 排查命令围绕 owner 搜不围绕页面猜排查时不要只盯着出问题的 UI。先搜 Service、模型、刷新信号再看页面是否绕过了 owner。这样可以分清是数据没写、结果没组装还是页面没订阅刷新。rg-nEmptyStateFactory|EmptyStateModel|AppStorageKey.LastEmptyActionAtD:\ProgramData\huawei\lesson\The_Book_of_Answers rg-nRouteName.ImportPreview|FavoritePageD:\ProgramData\huawei\lesson\The_Book_of_Answers rg-nDeckRepository|AppStorage.setOrCreateD:\ProgramData\huawei\lesson\The_Book_of_Answers10. 验证要覆盖正常路径和损坏路径分别清空收藏、历史、自建题库并手工制造当前题库损坏确认每一种空态文案、按钮和跳转路径都不同。建议至少按这四组走清应用数据后的首次进入。有自建题库、收藏和历史后的返回重进。手工制造空值、重复值或损坏数据后的恢复路径。发布态检查日志和截图确认没有把用户问题、答案全文或题库全文暴露出去。验收口径 1. 正常入口可用。 2. 异常入口有提示或恢复页。 3. 返回重进不显示旧数据。 4. AppStorageKey.LastEmptyActionAt 变化后只刷新对应 owner。 5. 发布态不输出敏感明文。11. 落地时的取舍这里没有把给题库、收藏和历史分别设计可恢复入口做成很重的框架能力是因为答案之书的核心仍然是离线、轻量、可维护。过度抽象会让一个小功能穿过太多层完全写在页面里又会让数据修复、备份恢复、发布排障没有稳定入口。比较合适的取舍是用户内容、持久化结构、跨页面刷新和发布自查进入 Service 或 Repository只影响当前视觉节奏的内容留在页面。适合抽出去 - EmptyStateModel - EmptyStateFactory - AppStorageKey.LastEmptyActionAt 不急着抽出去 - 当前页面的一次性动画状态 - 只影响局部样式的临时 UI 变量 - 不跨页面复用的按钮交互12. 常见问题与处理现象先看哪里处理所有空态都一样页面是否写死文案改为 EmptyStateModel空态按钮跳错页EmptyAction 是否集中映射由 NavigationService 执行动作错误态当成空态kind 是否区分 broken损坏数据进入恢复入口复查顺序 1. DeckRepository 是否返回可信数据。 2. EmptyStateFactory 是否统一处理空值和异常。 3. FavoritePage 是否绕过 Service。 4. AppStorageKey.LastEmptyActionAt 是否在业务动作成功后写入。 5. 发布态日志是否隐藏用户输入和答案全文。验证清单清应用数据后进入FavoritePage确认默认题库、页面状态和刷新信号都能闭环。从首页、Sheet、历史、收藏、分享或恢复入口触发一次确认RouteName.ImportPreview的参数校验稳定。手工制造空值、重复数据或损坏数据确认错误停在EmptyStateFactory或恢复页而不是让页面崩掉。触发业务动作后观察AppStorageKey.LastEmptyActionAt确认只有相关页面重拉数据没有全局乱刷新。如果涉及主题、资源、布局、隐私或发布态必须用真机截图、构建产物或发布清单补充确认。小结空态不是一句暂无数据给题库、收藏和历史分别设计可恢复入口不是一个孤立 API 问题而是答案之书这种离线应用在长期维护里一定会遇到的边界问题。把EmptyStateModel、EmptyStateFactory、DeckRepository、FavoritePage和AppStorageKey.LastEmptyActionAt分清以后项目继续扩展题库、收藏、历史、分享、恢复和发布诊断时才不会把每个入口都写成一次性的临时逻辑。别设计可恢复入口不是一个孤立 API 问题而是答案之书这种离线应用在长期维护里一定会遇到的边界问题。把EmptyStateModel、EmptyStateFactory、DeckRepository、FavoritePage和AppStorageKey.LastEmptyActionAt 分清以后项目继续扩展题库、收藏、历史、分享、恢复和发布诊断时才不会把每个入口都写成一次性的临时逻辑。
HarmonyOS应用实战-启示散页-19-空态不是一句暂无数据给题库、收藏和历史分别设计可恢复入口这一组文章继续围绕The_Book_of_Answers展开。它不是一次性页面 Demo而是一个小型 HarmonyOS 离线应用默认题库从 rawfile 播种题库、收藏、历史写进 Preferences抽取流程经过 DrawingPage发布前还要说明隐私、备份、包体和日志口径。轻量应用最容易被误判为“页面写完就结束”。实际交付时真正拖慢排障的通常不是某个 ArkUI 组件而是状态从哪里来、数据由谁写、页面靠什么刷新、异常能不能恢复。下面每篇只拆一个问题并尽量把它落到答案之书已有的页面、Service、Repository、AppStorage、资源或发布配置边界上。这篇文章解决四件事复盘空态不是一句暂无数据在答案之书项目里怎么出现。把给题库、收藏和历史分别设计可恢复入口落到页面、Service、Repository 和 AppStorage 的具体边界。给出能迁移到 HarmonyOS/ArkTS 项目的代码形态并指出反例。用验证清单和排障表收尾避免只看源码不看实际入口。1. 从故障链路看空态不是一句暂无数据答案之书有多种空首次没有自建题库、没有收藏、没有提问历史、当前题库损坏。它们都显示“暂无数据”会让用户不知道是正常状态还是出错。 这个问题如果只在当前页面补一个判断短期可能能跑但下一次从历史、收藏、分享或恢复入口进入时同样的问题还会出现。先把故障链路写出来才能知道该修页面、服务还是持久层。触发点空态不是一句暂无数据 错误写法页面直接判断或直接读写持久化数据 放大后果返回重进、前后台切换、删除/恢复、发布排查都会看到旧状态 收口位置EmptyStateFactory 处理业务规则FavoritePage 只消费结果态 刷新方式业务动作成功后写 AppStorageKey.LastEmptyActionAt2. 先把边界表写清楚空态应该由业务层生成模型页面只渲染标题、说明和主操作。不同空态的下一步不同题库空态去导入或新建收藏空态回抽取页历史空态回首页输入问题。 这张表的作用是防止后面写代码时顺手越界。尤其是答案之书这种本地应用很多问题看起来都能在页面里临时解决但页面一旦知道太多存储细节发布后的排障成本会明显升高。层级在这篇里的职责不应该做的事FavoritePage展示、点击、跳转、订阅刷新信号直接拼 Preferences key 或修复脏数据EmptyStateFactory校验输入、组装EmptyStateModel、决定空态和恢复路径持有 ArkUI 组件状态DeckRepository稳定读写本地实体和索引判断页面怎么展示AppStorage传递AppStorageKey.LastEmptyActionAt这类轻量刷新信号保存完整业务对象3.EmptyStateModel只表达页面结果不照搬存储实体EmptyStateModel是给FavoritePage消费的结果模型不是 Preferences 里的原始结构。这样做的好处是Repository 可以继续按本地存储优化字段页面仍然拿到稳定、可渲染、可判断动作的结果。interfaceEmptyStateModel{kind:deck|favorite|history|broken;title:string;description:string;primaryAction:EmptyAction;}4.EmptyStateFactory才是规则 ownerEmptyStateFactory负责把DeckRepository读出的数据转成页面能用的结果。空值、损坏、回退和默认值都应该在这一层处理页面不需要知道底层为什么缺字段。classEmptyStateFactory{asyncload(deckId:string):PromiseEmptyStateModel{if(kindfavorite){return{kind,title:还没有收藏答案,description:抽到值得留下的答案后可以在结果页点收藏。,primaryAction:{label:去抽一个答案,route:RouteName.Drawing}};}return{kind,title:还没有题库,description:可以导入一段文本也可以先使用默认题库。,primaryAction:{label:导入题库,route:RouteName.ImportPreview}};}}5.FavoritePage不直接碰持久化FavoritePage的职责应该保持轻进入时加载收到信号时重载用户点击时发起明确动作。这样页面不会同时背上 Preferences、业务规则、错误恢复和发布排查四种职责。Componentstruct FavoritePage{StateprivateemptyStateModel:EmptyStateModel|nullnull;StorageLink(lastEmptyActionAt)Watch(reload)privatechangedAt:number0;privatecurrentDeckId:string;asyncaboutToAppear():Promisevoid{awaitthis.reload();}privateasyncreload():Promisevoid{constdeckId:stringBookRouteGuard.requireDeckParam({deckId:this.currentDeckId});this.emptyStateModelawaitnewEmptyStateFactory().load(deckId);}}6. 反例把所有逻辑塞回页面会怎样这个反例在第一版开发时很常见因为写起来快但它把题库读取、空态判断、展示模型转换和刷新信号都揉在组件里。后续一旦增加 Sheet、深链、恢复页或平板布局就会出现多个入口行为不一致。// 反例页面同时知道数据结构、业务规则和刷新方式constdeckawaitDeckRepository.loadDeck(this.currentDeckId);if(decknull){promptAction.showToast({message:暂无数据});return;}this.emptyStateModeldeckasunknownasEmptyStateModel;AppStorage.setOrCreate(AppStorageKey.LastEmptyActionAt,Date.now());7. 刷新信号只写AppStorageKey.LastEmptyActionAt不要广播完整对象AppStorageKey.LastEmptyActionAt是运行期联动不是数据仓库。业务动作成功后只写一个时间戳页面收到后再按自己的 owner 重拉数据可以避免跨页面共享可变对象。classBookRefreshCenter{staticnotifyEmptyStateModelChanged():void{AppStorage.setOrCreate(AppStorageKey.LastEmptyActionAt,Date.now());}staticasyncafterBusinessAction(action:()Promisevoid):Promisevoid{awaitaction();this.notifyEmptyStateModelChanged();}}8. 入口参数要先校验再进入业务答案之书的入口不只首页一个历史再次提问、收藏再次提问、分享导入、恢复页都可能进入RouteName.ImportPreview。目标页先校验参数错误进入可恢复路径不要让空 deckId 流到 Service 深处才爆出难懂异常。classBookRouteGuard{staticrequireDeckParam(param:object|undefined):string{constdeckId(paramasRecordstring,string|undefined)?.deckId??;if(!deckId){thrownewError(缺少题库 id不能进入 RouteName.ImportPreview);}returndeckId;}}9. 排查命令围绕 owner 搜不围绕页面猜排查时不要只盯着出问题的 UI。先搜 Service、模型、刷新信号再看页面是否绕过了 owner。这样可以分清是数据没写、结果没组装还是页面没订阅刷新。rg-nEmptyStateFactory|EmptyStateModel|AppStorageKey.LastEmptyActionAtD:\ProgramData\huawei\lesson\The_Book_of_Answers rg-nRouteName.ImportPreview|FavoritePageD:\ProgramData\huawei\lesson\The_Book_of_Answers rg-nDeckRepository|AppStorage.setOrCreateD:\ProgramData\huawei\lesson\The_Book_of_Answers10. 验证要覆盖正常路径和损坏路径分别清空收藏、历史、自建题库并手工制造当前题库损坏确认每一种空态文案、按钮和跳转路径都不同。建议至少按这四组走清应用数据后的首次进入。有自建题库、收藏和历史后的返回重进。手工制造空值、重复值或损坏数据后的恢复路径。发布态检查日志和截图确认没有把用户问题、答案全文或题库全文暴露出去。验收口径 1. 正常入口可用。 2. 异常入口有提示或恢复页。 3. 返回重进不显示旧数据。 4. AppStorageKey.LastEmptyActionAt 变化后只刷新对应 owner。 5. 发布态不输出敏感明文。11. 落地时的取舍这里没有把给题库、收藏和历史分别设计可恢复入口做成很重的框架能力是因为答案之书的核心仍然是离线、轻量、可维护。过度抽象会让一个小功能穿过太多层完全写在页面里又会让数据修复、备份恢复、发布排障没有稳定入口。比较合适的取舍是用户内容、持久化结构、跨页面刷新和发布自查进入 Service 或 Repository只影响当前视觉节奏的内容留在页面。适合抽出去 - EmptyStateModel - EmptyStateFactory - AppStorageKey.LastEmptyActionAt 不急着抽出去 - 当前页面的一次性动画状态 - 只影响局部样式的临时 UI 变量 - 不跨页面复用的按钮交互12. 常见问题与处理现象先看哪里处理所有空态都一样页面是否写死文案改为 EmptyStateModel空态按钮跳错页EmptyAction 是否集中映射由 NavigationService 执行动作错误态当成空态kind 是否区分 broken损坏数据进入恢复入口复查顺序 1. DeckRepository 是否返回可信数据。 2. EmptyStateFactory 是否统一处理空值和异常。 3. FavoritePage 是否绕过 Service。 4. AppStorageKey.LastEmptyActionAt 是否在业务动作成功后写入。 5. 发布态日志是否隐藏用户输入和答案全文。验证清单清应用数据后进入FavoritePage确认默认题库、页面状态和刷新信号都能闭环。从首页、Sheet、历史、收藏、分享或恢复入口触发一次确认RouteName.ImportPreview的参数校验稳定。手工制造空值、重复数据或损坏数据确认错误停在EmptyStateFactory或恢复页而不是让页面崩掉。触发业务动作后观察AppStorageKey.LastEmptyActionAt确认只有相关页面重拉数据没有全局乱刷新。如果涉及主题、资源、布局、隐私或发布态必须用真机截图、构建产物或发布清单补充确认。小结空态不是一句暂无数据给题库、收藏和历史分别设计可恢复入口不是一个孤立 API 问题而是答案之书这种离线应用在长期维护里一定会遇到的边界问题。把EmptyStateModel、EmptyStateFactory、DeckRepository、FavoritePage和AppStorageKey.LastEmptyActionAt分清以后项目继续扩展题库、收藏、历史、分享、恢复和发布诊断时才不会把每个入口都写成一次性的临时逻辑。别设计可恢复入口不是一个孤立 API 问题而是答案之书这种离线应用在长期维护里一定会遇到的边界问题。把EmptyStateModel、EmptyStateFactory、DeckRepository、FavoritePage和AppStorageKey.LastEmptyActionAt 分清以后项目继续扩展题库、收藏、历史、分享、恢复和发布诊断时才不会把每个入口都写成一次性的临时逻辑。
