Changes between Version 23 and Version 24 of doc/design/flow

Timestamp:

06/20/2012 09:57:00 AM (14 years ago)

Author:

wangjianqiang

Comment:

--

doc/design/flow

@@ -4 +4 @@
 ||主体||说明||
 ||PNS||推送服务器（Push Notification Server），即本系统||
-||Sender||第三方应用服务器，发起推送的主体||
-||App||客户端应用，接收推送消息的主体||
+||Sender||集成了推送服务的第三方应用服务器，发起推送的主体||
+||Receiver||移动设备推送后台服务，接收发送到该设备的所有消息，并广播给所有App||
+||App||集成了推送服务的客户端应用，接收推送消息的主体||
 
 
 == 设备注册流程如下 ==
-1. App向PNS提交appkey并申请注册该移动设备，参见[wiki:doc/interface/platform 平台接口定义]/设备注册接口
+1. App启动时判断系统中是否已有Receiver在运行，已存在则跳到3，否则继续
+2. App启动一个独立的Receiver后台服务进程，以便实现推送功能
+3. Receiver判断是否该设备已向PNS注册过，已注册则跳到步骤6，否则继续
+4. Receiver向PNS提交appkey（由App提供）并申请注册该移动设备，参见[wiki:doc/interface/platform 平台接口定义]/设备注册接口
 > 这里是为设备进行注册，而非为当前App注册，设备注册后可为设备上的所有App提供推送服务
 >> 如果设备上已经有其它App注册了该设备，则当前App不再进行注册，而是直接使用已注册到的账号
 >>> 问题：如何有效地保存账号信息？即使发起注册的App被删除后，仍旧能保证账号信息可用
-2. PNS验证了appkey的合法性后自动分配一个新的账号及随机密码返回给App
+5. PNS验证了appkey的合法性后自动分配一个新的账号及随机密码返回给Receiver
 > 自动分配账号信息可能导致一个设备被分配多个账号，比如刷ROM等操作导致账号信息的丢失从而进行了重新注册
 >> 如果定期清理僵尸账号，如何保证长久时间未联网的设备再次联网时（账号已被清理）所有App还能正确获取到推送消息？
 >>> 可以考虑在每次进行设备注册之后发一次系统级的通知，让所有使用了推送服务的App重新走一次下面的Token申请流程
-3. App获取到账号信息后登录PNS
-4. App向PNS发送appkey、账号和密码并申请获取推送Token，参见[wiki:doc/interface/platform 平台接口定义]/获取推送Token接口
-5. PNS验证合法性后随机分配一个Token返回给App
+6. Receiver使用PNS分配的账号登录PNS，登录成功后告知App
+7. App检查是否已申请过推送Token，已申请则跳到10，否则继续
+8. App向PNS发送appkey、账号和密码并申请获取推送Token，参见[wiki:doc/interface/platform 平台接口定义]/获取推送Token接口
+9. PNS验证合法性后随机分配一个Token返回给App
 > Token是为App而非设备服务的，设备上的每个使用推送服务的App都会被分配一个不同的Token
 >> PNS需要维护账号、appkey与Token之间的关系，即一个账号对应多个Token，每个Token对应一个appkey
-6. App获取到Token后将Token告知Sender
+10. App将分配的Token告知Sender
 > 该环节由App和Sender自己处理，Sender保存下Token以便日后发送推送用
 
 
 == 推送流程如下 ==
-1. Sender提取出推送Token并连同推送信息一起发送PNS
+1. Sender提取出推送Token并连同推送信息一起发送到PNS，参见[wiki:doc/interface/platform 平台接口定义]/消息推送接口
+2. PNS验证Token的合法性并提取出相对应的设备账号及appkey
+3. PNS通过设备账号将消息连同appkey信息推送到对应的Receiver
+4. Receiver在系统内广播接收到的appkey和消息内容
+5. 所有集成了推送服务的App被唤醒并检查该消息是否发给自己的（对比appkey）。若不是，则执行完检查后退出；若是则处理推送内容