Electron 专门提供了 Notification 可以用来实现系统通知
,但是如果想实现自定义(如自定义UI样式等)通知,Notification 则不能实现。
下面摘录了我在系统通知
和如何实现自定义通知
的思路,另外也阐述了多并发下接收消息
方案实现。
背景
Electron 中提供的原生系统通知(Notification),直观的感受是样式单一,没有自定义的样式多样化。而且系统通知
本身受系统设置控制,若是电脑系统设置禁止弹出通知,那么用户将无法收到通知信息(见下图中右上角)。
相反,自定义通知
则能摆脱以上这两个问题。
我们先说下系统通知 Notification,可以借此了解通知是做什么的。
Notification是什么?
对于渲染进程,Electron 允许开发者使用通知中 API,来运行系统的原生通知
进行显示。
系统通知
可以在电脑桌面弹出新消息通知,一般展示在电脑桌面的右上角,如最上面的图,其右上角的灰色长条。
如何实现系统 Notification?
const {
Notification } = require('electron');
const isAllowed = Notification.isSupported();
if (isAllowed) {
const options = {
title: '标题',
body: '正文文本,显示在标题下方',
silent: true, // 系统默认的通知声音
icon: '', // 通知图标
}
const notification = new Notification(argConig);
notification.on('click', () => {
});
notification.on('show', () => {
});
notification.on('close', () => {
});
notification.show();
}
系统通知的困扰
1)受限于当前系统是否支持
系统通知,在mac或windows电脑的设置中,需特别注意是否允许通知。
2)样式单一,只能是系统自带的样式,对于不同业务场景无法满足;
3)mac与window各自对于一些功能不支持。比如:
timeoutType(通知的超时持续时间),只有window与linux支持。
closeButtonText(自定义关闭按钮提示内容),只有mac支持。
那么如何避免系统通知的困扰,从而实现我们既定的需求呢?
我在网上也查了很多资料,但并没有得到很理想的结果,所以我想到了借助Electron提供的能力来实现 自定义通知。
自定义通知
优势在于不受限于系统,样式可以按照自己的想法设计。
实现自定义通知
通知窗体实现
通过使用 BrowserWindow() 窗口来实现,设置好需要的自定义通知的尺寸与位置。
const {
BrowserWindow, screen } = require('electron')
const win = new BrowserWindow({
width: 800,
height: 600,
show: false,
y: 0,
x: 0,
frame: false, // 无边框
skipTaskbar: true, // 使窗口不显示在任务栏中
movable: false, // 禁止窗口被用户移动
resizable: false, // 禁止窗口手动调整窗口大小
fullscreenable: false, // 禁止窗口可以进入全屏状态
alwaysOnTop: true, // 窗口是否永远在别的窗口的上面
})
win.loadFile('./html/customNotification.html')
// 定位到桌面右上角
const sizeObj = screen.getPrimaryDisplay().workAreaSize;
const {
width, height } = sizeObj;
const [cwidth, cheight] = win.getContentSize();
const left = parseInt(width - (cwidth || 0) - 5);
const top = 10;
win.setPosition(left, top);
win.showInactive(); // 显示但不聚焦于窗口(建议做延时处理)
这种方式的实现相当于是类通知
。
因为类通知的实现是通过Electron创建窗口实现的。故需要关闭窗口的一些默认特性,也需要开启某些特性(详见上侧代码)。
通知UI样式
win.loadFile('./html/customNotification.html')
loadFile可以将React或者Vue等开发编译后的代码加载展现出来。
实现展示窗体和UI样式只是万里长征的第一步,真正的难点是 如何解决并发下的消息接收 与 消息处理展示。
并发消息接收处理
即自定义通知 并发接收消息 与 消息处理展示。
业务场景:
桌面应用接收发送的通知消息,在电脑桌面右上角进行展示;
接收到通知消息,按照设计的UI样式展示;
接收到新消息,隐藏当前消息,展示新消息;
关闭当前通知才可以展示上一条未预览确认的通知消息。
分析:
通知可能不只有一条消息,可能会是多条,也有可能会是同时多条(并发)。
如何管理以上这种情况呢?
我做了两个概念(有序消息池
、消息队列
)的思路,供大家参考(也可用于其他业务下的并发处理,已实践)。
这里主要是重思路,就不写代码了......
有序消息池
用于存储消息数据。
由于数据不同,有时需要对数据进行处理,这个过程是耗时的,而这期间如果多条或者并发的数据出现,容易导致数据出现混乱、无序。
同时如果出现重复、整合的数据,就没必要再执行一次了。
1、重复:多条数据以最后一条为准,其他舍弃。
2、整合:多条数据同属于同一个数据,该数据需要将其他的数据整合起来。
或者有些情况下是可以直接异步展示所有数据的。
消息队列
用于推送消息。
队列里面有消息就推送,不需要推送,就静默。
可以同时异步推送多条消息,也可以只推一条。
思路
1、消息整合
对于接收到的数据不做任何处理。
生成消息的唯一Key(服务端不生成的情况下),push进有序消息池
。
2、有序消息池
对于数据复杂、数据量大的情况下,做有序消息池映射处理(建议使用Map)。
3、switch
开关,是否执行生成消息队列 && 是否有序数据池有数据。
false,否,停止流程。
true,是,进入生成消息队列操作
4、生成消息队列
关闭switch开关。
读取有序消息池数据。
遵循业务规则对数据做重复、整合处理。
将唯一Key按序添加到消息队列中。
5、消息队列
判断通知是否存在,如果已存在,再次进入2有序数据池
节点执行。
反之通知未存在,创建通知,进入有序数据池节点执行。
6、关闭通知
关闭通知后,再次进入5消息队列
节点执行。
扩展
并发消息接收处理方案思路,同时也是可以用于为解决多条、并发情况下的场景提供思路。
从逻辑图中的 5、消息队列
往后,是为了通知
业务需求而做的(同步展示)。
如果有的业务允许多条消息同时更新,那么5、消息队列
这里可以执行异步更新,就没必要按照通知这种同步执行了。
这篇文章在实际项目中已用,真实可用,重点在于并发消息接收处理这一块。文章中可能和你的场景有不合适的地方,欢迎大家积极指正沟通,共同学习,共同进步~~
结语
感谢您的阅读!希望本文带给您有价值的信息。
如果对您有帮助,请「点赞」支持,并「关注」我的主页获取更多后续相关文章。同时,也欢迎「收藏」本文,方便以后查阅。
写作不易,我会继续努力,提供有意义的内容。感谢您的支持和关注!