HarmonyOS推送通知实战:用声明式 UI 串起数据、操作和结果
HarmonyOS 推送通知页面设计:从未读数量到操作反馈的完整交互
一、先看页面:这是一个可以立即理解的通知中心
打开页面后,最先看到的是“推送通知”标题。标题右侧有一个浅红色的小标签,显示当前未读数量。初始状态下,标签显示“2 未读”,这比单纯放一个数字更容易理解:数字代表数量,文字代表它们属于尚未处理的通知。
标题下面是一个蓝色按钮,按钮文字是“发送测试推送”。它是页面中最直接的操作入口。用户点击一次,页面会把发送数量增加一条,同时把未读数量也增加一条,底部反馈区域则显示这一次测试推送已经送达设备的文字。这个动作很适合用来演示通知页面中的状态联动,因为一次点击同时影响顶部数量、发送结果和反馈文案。
页面中间放着两条通知卡片。第一条是“版本更新提醒”,时间显示为“刚刚”,下面的说明是“发现新版本 6.0,点击查看更新内容”。第二条是“订阅内容上新”,时间显示为“10:30”,说明文字是“你关注的 ArkTS 专栏更新了 3 篇文章”。两条卡片的内容固定,但它们提供了通知中心最重要的阅读语境:通知不只是一个数字,还应该有标题、时间和摘要。
两条通知下面是绿色的“全部标为已读”按钮。点击它以后,顶部未读标签会变成“0 未读”,底部反馈文字也会切换为“全部通知已标为已读”。这两个变化同时出现,说明页面把“标记已读”处理成一个明确的状态动作,而不是只改变某一处文字。
底部的浅蓝色反馈框会显示当前最近一次操作的结果。刚打开页面时,它显示“Push service connected”;发送测试推送后,它变成类似“测试推送 #1 已送达设备”的文字;点击全部标为已读后,它变成“全部通知已标为已读”。因此,整个页面可以理解为一个小型的通知中心演示:顶部显示数量,中间展示通知内容,按钮触发操作,底部说明结果。

这类页面的价值不在于模拟出一个复杂的推送平台,而在于把通知产品中最容易被忽略的几件事放在同一个可操作界面里:未读数量如何表达,发送操作如何反馈,通知卡片如何组织,批量处理以后页面如何保持一致。对于刚开始学习 ArkUI 的开发者来说,这种页面比只有一个按钮的示例更适合观察状态变化。
二、页面的四个视觉区域
从上到下看,页面可以拆成四个区域:标题与未读标记、发送操作、通知内容、批量处理与反馈。这样的划分不依赖复杂导航,也不需要用户记住额外规则,进入页面后按照视觉顺序就可以完成一次完整体验。
2.1 标题与未读标记
“推送通知”使用较大的深色粗体文字,承担页面名称的作用。标题右侧的“2 未读”采用浅红背景、深红文字和圆角效果。红色在这里不是错误提示,而是提醒用户存在尚未处理的内容。标签的尺寸比较紧凑,不会抢过标题的注意力,但又足够明显,用户扫一眼就能看到数量。
标题和标签处在同一行。标题靠左,标签靠右,中间留下弹性空间,因此不同宽度的屏幕也能保持两端对齐。这里的关键不是把文字写得多复杂,而是让页面名称和重要数量形成稳定的视觉关系。用户切换状态后,只需要观察标签里的数字,就能知道当前还有多少通知没有标记为已读。
2.2 发送操作
蓝色按钮占据整行宽度,高度约为五十,按钮文字为“发送测试推送”。整行按钮比一个窄小的文字按钮更容易点击,也更适合演示页面。蓝色承担主要操作色,和顶部红色未读标签形成区分:红色表示需要注意的数量,蓝色表示可以执行的动作。
点击按钮以后,用户不需要离开当前页面,也不会看到弹窗遮挡内容。数量和反馈会直接刷新。这样的设计让操作前后的差异非常清楚:发送前顶部是“2 未读”,发送一次后变成“3 未读”;发送次数从零开始增加,反馈文字中的编号也会跟着变化。连续点击几次,用户可以观察数字是否按预期递增。
2.3 通知卡片
两条通知采用白色卡片和圆角处理,放在浅灰蓝色页面背景上。卡片标题使用较深的粗体文字,时间使用小号灰色文字,标题和时间处在同一行。标题下方再放摘要,摘要文字颜色更浅,与标题形成层级。
第一条通知突出“版本更新提醒”,对应的摘要明确提到新版本 6.0。第二条通知突出“订阅内容上新”,摘要说明关注的专栏更新了 3 篇文章。两条内容虽然是静态展示,但它们分别代表系统提醒和订阅提醒,能够让页面看起来像一个具有不同通知来源的中心。
卡片之间没有增加额外操作按钮,也没有在点击卡片后跳转到详情页。这个边界很重要:当前页面展示的是通知列表的视觉结构和数量联动,并不是完整的通知详情系统。阅读文章或查看更新内容的后续页面没有在这个界面中实现,因此不能把卡片里的文字理解为已经完成了可点击的业务流程。
2.4 批量处理与反馈
绿色按钮“全部标为已读”位于通知内容之后。它与蓝色发送按钮区分明显,代表另一种处理方向:蓝色增加测试通知,绿色清除未读状态。点击绿色按钮以后,未读数量直接归零,反馈框同步显示处理结果。
反馈框使用浅蓝背景和灰色文字,不像红色标签那样强调提醒,也不像蓝色按钮那样要求操作。它更像页面底部的状态栏,告诉用户最近一次动作已经产生了什么结果。反馈文字的变化让页面具备可观察性,用户可以通过文字判断点击是否生效,而不必只依赖数字变化。
三、三个状态如何配合
页面的交互不多,但三个状态之间存在清晰关系。未读数量负责顶部提醒,发送数量负责记录测试推送的序号,反馈文字负责解释最近动作。它们各自承担不同职责,又在同一次操作中共同变化。
3.1 未读数量
未读数量初始为 2,正好对应页面中已经摆出的两条通知。这个初始值让页面一打开就有内容可处理,而不是显示一个空的通知中心。点击发送测试推送时,未读数量加一,因为新发送的测试通知被视为一条新的未读内容。点击全部标为已读时,未读数量变为 0。
这里的数量变化可以用三个步骤观察。第一步是初始状态:标签显示“2 未读”。第二步是点击发送:如果发送一次,标签显示“3 未读”;如果再发送一次,就显示“4 未读”。第三步是点击全部标为已读:无论此前发送过多少次,标签都会回到“0 未读”。这种变化体现了“累加”和“归零”两类典型状态操作。
需要注意的是,页面没有在标为已读后删除两张卡片,卡片仍然留在界面中。归零改变的是顶部未读数量和反馈文字,不是把通知内容从页面移除。这说明数量状态和展示数据是两个不同层面的概念,不能把“已读”简单理解成“列表为空”。
3.2 发送数量
发送数量初始为 0,页面初始状态不会把它单独显示出来。它主要体现在发送后的反馈文字中,例如第一次发送后出现“测试推送 #1 已送达设备”,下一次发送则出现“测试推送 #2 已送达设备”。因此,发送数量既是计数器,也是反馈文案的一部分。
发送数量每点击一次蓝色按钮只增加 1。它不会因为点击全部标为已读而归零,因为标记已读处理的是通知状态,而不是发送次数。这个区别让页面的行为更容易推断:发送按钮负责产生新的编号,绿色按钮负责改变未读状态,两条操作线互不覆盖。
连续快速点击发送按钮时,编号应该依次递增。发送数量本身没有复杂校验,也没有网络等待或失败分支,所以每一次点击都会立即完成。页面借此展示了同步状态更新的最小实现:事件发生,数字增加,反馈文本重建,界面随状态刷新。
3.3 反馈文字
反馈文字的初始内容是“Push service connected”。这句话在页面语境里表达一个连接状态,但它只是初始显示的状态文案,不能据此推断已经接入了真实的推送服务器。点击发送后,反馈文本会替换为当前测试推送的送达提示;点击全部标为已读后,它会替换为批量处理提示。
反馈文字采用替换关系,而不是追加日志。用户每次操作后看到的是最近一次结果,之前的反馈不会以列表形式保留。这样做适合小型演示页面,界面干净,状态变化明显;如果产品需要完整操作历史,则需要另行设计日志列表,但这不属于当前页面的功能范围。
四、发送测试推送的完整变化
为了理解页面,可以从一个具体流程开始。打开页面时,顶部显示“2 未读”,中间显示版本更新和订阅上新两条内容,底部提示“Push service connected”。此时发送数量为 0,页面没有显示过测试推送编号。
第一次点击“发送测试推送”后,页面发生三处变化。第一处是未读标签从 2 变成 3;第二处是发送编号从 0 进入 1;第三处是反馈框变成“测试推送 #1 已送达设备”。这三处变化具有因果关系:一次发送动作产生一条新的未读提示,同时把操作编号写入结果文字。
第二次点击以后,未读数量从 3 变成 4,反馈编号从 #1 变成 #2。中间两张静态通知卡片不发生变化,它们仍然显示原来的标题、时间和摘要。这个细节说明页面的“发送测试推送”并不会在列表中追加一张新的通知卡片,而是通过顶部数字和底部文本表现测试操作结果。
如果连续发送三次,未读数量会从 2 变成 5,发送反馈编号会依次经过 #1、#2、#3。此时再点击“全部标为已读”,顶部数量变为 0,反馈文本改成全部标记完成。发送编号不会显示在页面中,但它仍然影响下一次发送后的反馈文字。再次点击发送,未读数量从 0 变成 1,反馈文字会显示新的编号。
这一流程适合检查两个问题:一是按钮是否每次只触发一次状态更新,二是多个状态是否能够保持各自独立。若发送一次后数字没有增加,说明发送和未读状态之间的联动有问题;若标记已读后下一次发送编号重新从 1 开始,则说明发送计数被错误地和未读数量绑定了。当前页面的设计把这两个计数分开,行为更容易维护。
五、全部标为已读的行为边界
“全部标为已读”是页面中唯一会把一个数量直接归零的操作。点击它以后,顶部标签显示“0 未读”,底部显示“全部通知已标为已读”。无论点击前未读数量是 2、3 还是更大的数字,归零结果都相同。
归零以后,两条通知卡片仍然保留。版本更新提醒仍显示“刚刚”,订阅内容上新仍显示“10:30”,摘要也不会被修改。换句话说,按钮只处理未读计数,不会删除、隐藏或修改通知内容。这是当前页面非常明确的边界,也是阅读页面时需要注意的地方。
如果在未读数量已经是 0 时再次点击按钮,页面仍会把数量设置为 0,并把反馈文字写成“全部通知已标为已读”。用户看到的结果没有错误提示,也不会出现负数。这种处理让按钮具备幂等特征:重复执行不会把状态推向不可理解的方向。
如果先点击全部标为已读,再点击发送测试推送,顶部标签会从 0 增加到 1,反馈文字改为当前发送编号。这个顺序说明“已读”不是锁定状态,页面仍然允许产生新的测试通知。新的发送动作重新产生一个未读数量,但不会恢复之前的两条通知内容,也不会清除发送计数。
六、通知内容为什么要保留标题、时间和摘要
通知页面的主体不是按钮,而是用户需要阅读的内容。当前两条卡片虽然固定,但它们展示了通知信息的三个基本维度。
第一是标题。标题直接说明通知主题,“版本更新提醒”让用户知道它与版本变化有关,“订阅内容上新”让用户知道它与关注内容有关。标题采用粗体,用户快速滚动时也能先看到核心信息。
第二是时间。第一条显示“刚刚”,第二条显示“10:30”。时间没有采用同一种文案,体现了通知列表中常见的相对时间和具体时间两种表达。时间文字较小、颜色较浅,说明它是辅助信息,不能抢过标题。
第三是摘要。版本通知的摘要提到新版本 6.0,订阅通知的摘要提到更新了 3 篇文章。摘要为用户提供下一步判断所需的线索,即使不进入详情,也能大致知道通知内容。
标题、时间和摘要组合起来,形成一张可以独立阅读的通知卡片。如果只显示标题,用户很难判断新旧;如果只显示数字,用户不知道数字背后的内容;如果只显示摘要,页面层级又不够清晰。当前页面用两条卡片把这些信息放在一起,足以表现通知中心的基本结构。
七、声明式界面中的状态驱动思路
页面采用状态驱动的方式组织交互。用户点击按钮以后,页面并不是逐个寻找标签、手动修改颜色或直接操作某一段文本,而是更新对应的数据状态,然后由界面根据最新状态重新展示内容。
在发送动作中,变化的数据包括未读数量、发送次数和反馈文字。顶部标签读取未读数量,反馈区域读取反馈文字,发送次数通过组合文本体现。只要这三个状态得到更新,界面就能自然呈现发送后的结果。
在标记已读动作中,变化的数据只有未读数量和反馈文字。通知卡片没有读取这两个变化,因此它们继续显示原来的内容。这个例子很好地说明了状态依赖关系:只有使用某个状态的界面部分才需要随着它变化,静态内容不必因为其他状态变化而改变语义。
声明式写法的另一个好处是操作结果容易描述。发送按钮做三件事:增加发送数、增加未读数、更新反馈;标记按钮做两件事:未读数归零、更新反馈。每个事件的职责都很清晰,页面行为可以通过这些状态转换直接理解。
这类页面不需要引入复杂的状态管理库,也不需要把每个文字都拆成独立对象。三个状态已经足够支撑当前的交互。状态数量少并不意味着页面简单到没有学习价值,恰恰相反,开发者可以在小范围内看清事件、数据和界面之间的完整链路。
八、布局与间距带来的阅读节奏
整个页面使用纵向排列。标题、发送按钮、通知卡片、批量按钮和反馈框按阅读顺序依次出现。垂直布局适合通知中心,因为用户通常会从顶部的数量和操作入口开始,再向下阅读内容和结果。
页面四周有统一内边距,使文字和卡片不会贴住屏幕边缘。各区域之间保持相同的纵向间距,避免标题和按钮挤在一起,也让反馈框与批量操作之间有清楚的分隔。对于手机界面来说,这种留白能够减少误触,并改善信息密度。
标题行使用横向排列,把名称和数量分到两端。中间的弹性空间让右侧标签不会紧贴标题。通知标题行也使用横向排列,左侧标题占据主要空间,右侧时间保持靠右。这样的结构可以应对标题长度变化,时间仍然有稳定位置。
通知摘要单独放在标题行下面,并略微靠近卡片标题。标题和摘要之间的距离较小,用户能够把它们视为同一条通知的信息层级;卡片和下一张卡片之间的距离较大,用户则能清楚区分两条内容。
背景色使用浅灰蓝色,卡片使用白色,按钮使用高饱和色,反馈框使用浅蓝色。不同颜色承担不同层次,页面不需要额外的分割线也能看出区域边界。圆角让卡片和标签显得柔和,符合通知中心这种偏信息展示的界面气质。
九、颜色和文字的语义分工
颜色不是装饰,而是在页面中承担信息分类。顶部未读标签采用浅红底色和红色文字,表达提醒;发送按钮采用蓝色,表达主要动作;全部标为已读按钮采用绿色,表达处理完成或状态确认;底部反馈框采用浅蓝底色,表达信息提示。
颜色之间没有混用。比如“全部标为已读”没有使用红色,因为它不是危险操作;“Push service connected”也没有使用红色,因为当前页面没有实现失败状态。保持这种语义一致,可以避免用户误判按钮作用。
文字颜色也有层次。页面标题和通知标题较深,说明它们是主要阅读内容;时间和摘要使用灰色,说明它们是辅助信息;反馈文字颜色适中,使其既能读清,又不会压过按钮。颜色与字号共同建立阅读顺序,用户不必逐项阅读所有元素也能迅速找到重点。
按钮文字直接描述动作。“发送测试推送”比“执行”更具体,用户点击前就知道会发生什么;“全部标为已读”比“清理”更准确,用户可以判断它会影响未读数量。清楚的动作文字是交互设计的重要部分,尤其适合教学和演示页面。
十、当前页面实现了什么,没有实现什么
页面实现的是本地的通知中心交互演示。它有初始未读数量,有两条固定通知,有发送测试推送按钮,有全部标为已读按钮,也有随着操作变化的反馈文字。用户可以通过点击按钮观察数字递增、数字归零和反馈替换。
页面没有展示真实的服务器地址、账号信息、设备注册令牌或消息队列。发送按钮不会把数据发送到远端推送平台,也没有网络请求等待、失败重试、权限申请或后台回调。底部的“已送达设备”是当前页面用于表现操作结果的演示文案,不能理解成真实设备已经收到远程消息。
页面也没有真正创建新的通知卡片。点击发送以后,顶部未读数量增加,底部编号变化,但中间的版本更新和订阅上新两条卡片保持不变。这样做是为了把重点放在状态联动,而不是构建一个动态列表。
页面没有实现通知详情、点击卡片跳转、删除单条通知、按类型筛选、按时间排序或单条标记已读。当前只有批量标记已读入口。文章中对这些能力只能作为界面边界来说明,不能把它们写成已经存在的功能。
如果要继续扩展真实产品,需要增加消息数据模型、远端接口、权限处理、设备令牌管理、失败状态和生命周期处理,但这些内容不属于当前页面。理解边界很重要,因为一个有“推送通知”标题的页面,并不等于已经完成推送服务。
十一、适合观察的几个状态组合
11.1 初始状态
初始状态的组合是:未读数量为 2,发送次数为 0,反馈文字是连接提示,两条通知卡片正常显示。这个状态展示了页面的默认内容,也说明用户打开页面时已经有两条通知等待处理。
11.2 发送一次
发送一次以后,未读数量为 3,发送次数为 1,反馈框显示第一条测试推送结果。卡片内容不变。这个状态适合观察一次按钮事件如何同时影响两个数字语义和一条结果文本。
11.3 连续发送
连续发送几次以后,未读数量按照次数增加,反馈文字中的编号依次变化。这里最容易看出页面没有把按钮点击当成一次性开关,而是把它作为可以重复执行的计数动作。只要用户继续点击,页面就会继续给出新的编号。
11.4 发送后标记已读
先发送,再点击全部标为已读,未读数量最终回到 0,反馈文字改为批量处理提示,发送次数仍然保留在下一次发送编号中。这个组合证明了“发送记录”和“阅读状态”是两个独立概念。
11.5 标记已读后再次发送
先把未读数量清零,再发送测试推送,数量会从 0 变成 1。这个状态符合通知中心的直觉:清空旧的未读状态并不禁止新的通知产生。页面因此具有连续使用的感觉,而不是只能执行一次操作。
十二、运行时可以观察到的现象
打开页面后,先看顶部右侧的红色数量标签,再观察两张卡片和底部反馈。首次点击发送按钮时,不需要等待动画或网络响应,数字和文字会立即更新。再次点击时,编号继续增加,页面不会跳转,也不会改变卡片顺序。
点击绿色按钮后,红色标签中的数量立即变成 0。反馈框的背景保持浅蓝色,但文字变成全部通知已标记的提示。卡片仍然存在,说明批量处理只针对未读数字。
当用户在不同顺序下操作,页面仍然遵循同一套规则。先发送后标记,结果是归零;先标记后发送,结果是从零增加;反复标记不会出现负数;反复发送不会让编号回退。可预测的结果让页面更容易学习,也便于发现实际实现中的异常。

页面的反馈区域还承担了一个重要作用:即使用户没有注意到数字变化,也可以通过文字确认操作结果。对于真实产品,这种反馈可以进一步扩展为成功、失败、等待、权限不足等多种状态;当前页面只展示连接提示、测试推送送达提示和全部已读提示三种文案。
十三、从这个页面理解 ArkUI 交互
这个页面适合作为声明式 UI 的入门案例,是因为每个控件都和一个清晰动作对应。按钮接收点击,点击更新状态,状态决定文字,文字决定画面。没有复杂导航,没有异步回调,也没有大量数据源干扰观察。
对于初学者来说,可以先只关注“发送测试推送”这一条链路:点击之前,顶部数字是多少;点击之后,哪个数字增加;反馈文字如何组合编号;通知卡片为什么没有变化。把这条链路看清以后,再观察“全部标为已读”的归零逻辑,就能理解不同事件如何更新不同状态。
页面还展示了一个很实用的设计原则:反馈应该靠近操作结果。发送按钮在页面上方,数量标签在标题行,反馈框在底部。虽然它们不在同一个容器里,但每次操作后都能看到对应变化。数量提供快速反馈,底部文字提供解释性反馈,两者互相补充。
另一个值得注意的原则是不要为了让页面看起来复杂而添加不存在的功能。当前内容已经足够说明通知卡片、数量状态和操作结果。如果加入网络服务、真实设备、后台任务等描述,反而会让读者误以为页面具备远端能力。围绕已实现的控件把行为解释清楚,比堆砌概念更有价值。
十四、如果把它用于真实通知产品,需要补充的能力
当前页面明确是本地演示,因此可以把真实产品所需能力作为边界理解,而不是当作当前功能。第一类能力是消息来源。真实通知需要一个可靠来源,例如服务端事件、系统事件或应用内业务事件,并且要有明确的数据格式。
第二类能力是设备与用户身份。真实推送通常需要设备标识、用户授权状态和消息目标。发送前需要知道消息发给谁,收到后也需要知道如何归属到哪一个通知中心。当前页面没有这些数据,因此“送达设备”只是一条显示文本。
第三类能力是生命周期。应用在前台、后台或被系统挂起时,通知的处理方式可能不同。真实产品需要考虑通知到达、点击、清除和重新打开后的状态恢复。当前页面中的状态只存在于这次页面运行过程中,没有展示持久化行为。
第四类能力是失败反馈。网络不可用、权限被拒绝、服务器超时或目标设备离线时,用户需要看到可理解的失败状态。当前页面没有失败按钮或错误分支,所有点击都直接更新为成功样式,因此不能从页面推断真实可靠性。
第五类能力是通知管理。真实通知中心可能需要按类型筛选、单条删除、批量操作、详情跳转和已读同步。当前页面只保留两张静态卡片和一次性全部标记操作,属于最小可观察模型。
十五、容易产生误解的地方
第一,看到“推送通知”标题,不代表存在真实推送 API。页面中的发送动作只增加本地数字并替换反馈文字,不能证明有网络请求。
第二,看到“已送达设备”文案,不代表另一台设备真的收到消息。它是按钮操作后的结果展示,用来让用户理解发送动作已经完成。
第三,看到“版本更新提醒”和“订阅内容上新”,不代表卡片数据会自动刷新。它们是页面中固定的通知内容,当前没有动态添加和删除行为。
第四,点击“全部标为已读”后卡片仍然存在,这是有意保留的页面行为。已读只改变数量,不是清空内容。
第五,初始反馈中的英文连接提示也不是服务连接诊断结果。它只是页面默认显示的字符串,真实连接状态需要由实际网络和服务回调决定。
十六、一个自然的阅读与操作顺序
进入页面后,先理解标题和红色数量标签,知道当前有两条未读内容。然后阅读第一条版本更新通知,再阅读第二条订阅通知,比较它们的标题、时间和摘要。接着点击蓝色发送按钮,观察数量和底部文字同时变化。
如果想观察计数关系,可以连续点击两到三次,确认未读数量逐次增加、反馈编号逐次变化。完成观察后点击绿色按钮,查看数量归零和批量处理提示。最后再发送一次,确认新通知会让未读数量从零开始增加。
这个顺序从阅读到操作,再从操作到批量处理,覆盖了页面的主要状态。它不要求用户理解页面背后的实现细节,单凭页面上的文字和颜色就能判断操作是否达到预期。对于第一次接触这个界面的人来说,标题、数字、两张卡片、两个按钮和底部提示已经组成了完整的理解路径,不需要额外的解释窗口,也不会因为信息分散而迷失操作方向。
十七、把每一次点击看成一次状态转换
如果把页面操作写成用户能够感知的过程,发送测试推送就是“当前有一些未读内容”到“又产生了一条新的未读提示”,全部标为已读就是“当前还有未读内容”到“当前没有未读内容”。这种过程描述比单纯说按钮调用了某个方法更接近用户真正看到的变化。
发送动作前,用户关注的是红色标签里的数字;点击之后,关注点自然转移到底部的结果文字。数字回答“还有多少未读”,反馈回答“刚才发生了什么”,两者并不重复。标记动作前,用户可能只想快速清理提醒;点击以后,数字归零给出立即确认,文字又补充说明这次操作作用于全部通知。
状态转换还体现在颜色的稳定性上。发送按钮始终保持蓝色,标记按钮始终保持绿色,按钮颜色不会因为某次操作而互换。变化集中在数字和文字上,用户可以把按钮理解为固定入口,把状态区域理解为实时结果。固定入口与动态结果分开,既减少认知负担,也让页面更容易观察。
这种组织方式适合继续添加内容,但添加内容时仍然要保持职责清楚。例如,如果以后增加“清除通知”按钮,它应该明确说明会不会删除卡片;如果增加“仅看未读”开关,它应该改变列表展示还是只改变数量;如果增加失败提示,它应该说明失败发生在发送前还是发送后。当前页面没有这些控件,因此文章只讨论已经能从页面看到的状态转换。
十八、页面作为学习示例的价值
一个好的入门页面不一定要拥有很多功能,它更需要让每个已有功能都能被观察和解释。这个页面把状态数量压缩到三个,把操作压缩到两个,把通知内容压缩到两张卡片。用户可以在很短时间内完成一次发送、一次批量处理,再回头观察每一处变化。
这种规模也方便比较操作前后截图。初始画面中的“2 未读”和连接提示,能够作为阅读起点;发送后的数量和编号,能够作为第一次状态变化;标记完成后的“0 未读”,能够作为第二次状态变化。不同阶段之间差异明确,适合用来说明声明式界面的基本反馈。
从学习角度看,页面还提醒开发者尊重“功能边界”。通知中心看起来可以延伸出很多产品能力,但示例只需要把未读数、发送数和反馈文字讲清楚。越是能够准确说明“这里有什么”和“这里没有什么”,越能避免读者把演示文案误认为真实服务。理解边界本身,就是进行界面分析时很重要的一项能力。
十九、总结前的再次回看
回到页面最上方,可以看到标题告诉用户这是通知中心,红色标签告诉用户有多少未读内容。向下看,蓝色按钮提供一次测试发送,两个白色卡片提供可阅读的通知示例。继续向下,绿色按钮提供批量处理,浅蓝色区域提供最近一次结果。每一块内容都在回答一个问题:这里是什么、我能做什么、现在有什么、操作完成了吗。
当用户点击发送时,页面没有隐藏通知卡片,也没有跳到新的页面,而是把变化集中在数量和反馈两个位置。当用户点击标为已读时,页面没有清空视觉内容,而是只清理未读计数。正是这种有节制的变化,使每个动作的影响范围很容易被看懂。
二十、总结:小页面也能讲清楚状态关系
这个通知中心页面的核心并不是“推送”这个词本身,而是三个状态和两类操作之间的关系。未读数量从 2 开始,在发送时增加,在全部标记时归零;发送数量从 0 开始,用于生成递增的测试推送编号;反馈文字随着最近一次动作替换,让用户知道页面刚刚完成了什么。
中间的两张卡片提供了通知内容的真实阅读结构:标题、时间和摘要分别承担不同职责。顶部标签负责提醒,蓝色按钮负责产生测试动作,绿色按钮负责批量处理,浅蓝反馈框负责解释结果。颜色、布局和文字共同组成一个无需额外说明就能理解的交互路径。
同时,页面边界也很清楚。它没有真实推送服务器、没有远端设备通信、没有消息权限流程、没有动态通知列表、没有详情跳转,也没有持久化的阅读状态。正因为不把不存在的能力写进来,读者才能准确理解这个示例真正展示的内容。
对于 ArkUI 学习者而言,这个例子提供了一条完整而克制的练习路径:用状态保存数量和反馈,用按钮触发状态变化,用布局把信息按阅读顺序组织起来,再用颜色和卡片层级让结果容易被看见。这样的页面规模不大,却足以帮助开发者建立“操作改变状态,状态驱动界面”的基本认识。
更多推荐



所有评论(0)