Notification Design Discuss

[kingsword09]

不开端口，写deno的op，我把消息的发送给你写好，你轮询拿取信息就好，app们的消息会发送到rust的一个变量里面
轮询代码类似这样

  /**
 * 轮询拿取APP消息
 * @param handleFn 
 * @param data 
 * @returns 
 */
  asyncCallDenoFunction(timeout = 3000): Promise<string> {
    return new Promise(async (resolve, reject) => {
      do {
        const data = await loopRustNotification().next();
        if (data.done) {
          continue;
        }
          resolve(data.value)
          break;
      } while (true);
      setTimeout(() => {
        reject("call function timeout") // 超时
      }, timeout);
    })
  }

主要的是这个
const data = await loopRustNotification().next();
，这个就是不断从rust拿取app的消息

/**
 * 消息通知中心的消息在这里拿
 * @returns 
 */
export function loopRustNotification() {
  return {
    async next() {
      let buffer: number[] = [];
      try {
        buffer = await Deno.core.opAsync("op_rust_to_js_app_notification");
        console.log("rust发送消息给deno_js:", buffer);
        const string = new TextDecoder().decode(new Uint8Array(buffer));
        console.log("rust发送消息给deno_js:", string);
        return {
          value: string,
          done: false,
        };
      } catch (_e) {
        return {
          value: "",
          done: true,
        };
      }
    },
    return() {
      /// 这里可以手动控制异步迭代器被 “中止” 释放
    },
    throw() {
      /// 这里可以手动控制异步迭代器被 “中止” 释放
    },
  };
}

[kingsword09]

消息数量默认不要限制，否则遇到聊天功能的通知就拉闸。

“普通消息”不确保“及时性”，比如说代码中写了一个定时器轮询每一秒显示一次通知，但通知中心并不确保这个通知是每一秒都能及时通知到用户。特别是当用户将某一个应用的消息标记成“不重要”，那么通知的滞后特性会更加明显。

要确保“及时性”的通知，需要使用AlarmManager（参考Android）

比如说你静音模式了，或者省电模式了、或者专注模式了，这时候要推给用户消息吗？或者推了没声音用户就错过了？

所以消息推送的时机是灵活的，不是代码说推就推，推确实推了，什么时候通知用户是在系统中里灵活定义的

[kingsword09]

[waterbang]

@jackie-yellow @xing123456789 需要提供获取手机模式的API

[kingsword09]

[kingsword09]

记录一下：

Android shortcuts api 下一阶段可以考虑引入到系统API中。
通知API也是类似。
BFS对于这些接口的处理方式不是单纯的接上就用，而是要管理它们。
比如说：

1. 我们增加了一个系统级的扫一扫的shortcuts。
2. 而BFS内的多个DAPP也定义了同样的扫一扫shortcuts，
3. 那么此时打开的扫一扫界面，应该是一个“聚合扫一扫”的界面。
4. 而聚合扫一扫如何跳转到对应的DAPP中，不可能直接唤醒所有DAPP的代码来一同处理。
5. 建议的解决方案：这里得引入类似 “Android定义Scheme”的模式，我们分发给DAPP的“Barcode Detection API”（扫一扫API），需要开发者定义一个标识符，来让聚合扫一扫的识别内容引导到对应的DAPP中。

同样的思路对于Notification API也是：

1. BFS内部需要又有一个通知中心，
2. 类似邮箱系统，
3. 然后才是将这些DAPP的通知“聚合”后，
4. 再通过 Android/IOS 的系统级通知接口，引导给用户。

总而言之，在设计这些接口的时候，我们需要以一个系统的视角去规划这些接口。
这些BFS特性的东西，是要在js引擎中去实现。也就是说不论是IOS和Android，Swift/Kotlin只需要负责引入 “系统级别的API”，然后JS需要负责的则是“聚合扫一扫”的分发逻辑、“通知中心”的管理逻辑。

[waterbang]

• 安卓状态：静音模式，勿扰模式
• 苹果状态：无法获取状态