windowsphone7推送服务工作过程
2011-09-13 16:38
176 查看
WindowsPhone7–PushNotification基本概念详述Push Notificiation的诉求为了是让WP7在没有办法背景执行第叁方程式的状况下,仍然可以将远端资料传送 到WP7中,这是一个重点;另一个重点在于与Cloud Service(云端服务)串联起来。云端效应其实被期待的除 了Cloud种类与硬体的整合之外,Mobile(泛指行动设备:智慧型手机或Pad系列产品等)也将是下一个云端效 应下将会进展快速的一环。因此,WP7也希望藉此将Cloud Service加以整合进来。 WP7是以Silverlight为基础为开发,因此,与后端资料库或服务的操作往往都会透过WCF或RIA Service来完成。 Push Notification的概念,则是如下图:
从上图可以清楚看出叁个角色: ‧Notifier (Web Service Provider) 可以称之为通知者或是Notification服务提供者,身为该角色如果需要提供Notification的服务,便需要向 Microsoft Push Notification Service (MPNS)的伺服器註册需要的Channel,配合Protocol与MPNS进行沟通。 ‧Microsoft Push Notification Service (MPNS) 主要扮演中介者的角色,负责将Notifier欲发送的资料内容转接给subscribers(如:WP App/Device)。 它接受由Notifier所申请的Service Name进行註册,让Push Client可以在建立Channel时指定需要的Service。 它也接受Push Client申请需要的Channel来进行沟通。 [註] Notifier送出的资讯会被MPNS存着,等MPNS与Push Client建立此Channel之后才会被送达Client端。 ‧Push Client (Windows Phone Device/App) Push Client要取得资料的话,则需要向MPNS建立起独有的Channel,因此,Push Client会向MPNS送出询问 是否存在指定的Service Name与专用的Channel名称。例如: 1: //The name the application uses to identify the notification channel instance. 2: //該channelname參數是專屬該應用程式使用的。 3: httpChannel=new HttpNotificationChannel(string channelname); 4: 5: //The service name that the web service uses to associate itself with the Push Notification Service. 6: //該service name來用代表web service註冊於NPS裡的name。 7: httpChannel=new HttpNotificaitonChannel(string channelname, string servicename); Notificatoin Type主要有:Tile、Toast、Raw叁种。 ‧Tile Nofitication 使用固定的XML格式做为传输资料的规範。通常是比较多视觉、动态的内容,支援修改WP Start画面 中的Quick Launch area(例如:
),包括:背景图示、Tile或Title文字、计数器等。可参考此篇。 传输的範例内容如下 1: <?xml version="1.0" encoding="utf-8"?> 2: <wp:Notification xmlns:wp="WPNotification"> 3: <wp:Tile> 4: <wp:BackgroundImage><background image path></wp:BackgroundImage> 5: <wp:Count><count></wp:Count> 6: <wp:Title><title></wp:Title> 7: </wp:Tile> 8: </wp:Notification> 如果<background image path>是参考远端档案的话,该档案最大Size 80KB。最长的下载时间是一分鐘, 如果档案过大或是超过1分鐘下载时间,则直接使用预设的Tile内容。 ‧Toast Notification 使用固定的XML格式做为传输资料的规範。该类别比较像是即时通知,它会自动显示于目前画面中的最上方, 如果用户点取那段讯息,将会直接启动所属讯息的应用程式,进一步完成接收完讯息之后的动作。 其传输的格式如下: 1: <?xml version="1.0" encoding="utf-8"?> 2: <wp:Notification xmlns:wp="WPNotification"> 3: <wp:Toast> 4: <wp:Text1><string></wp:Text1> 5: <wp:Text2><string></wp:Text2> 6: </wp:Toast> 7: </wp:Notification> ‧Raw Notification 使用自订的XML格式,因此在Push Client端需要针对Raw Notification进行自订的处理。该类型的使用只限于 当Application执行在前端时才能正常的传递。如果该程式变成了暂存模式(tombstoned),Notifier所送出的讯 息会被暂留在NPS中,等到Application回到启动模式时,留在NPS中的内容会被在送达Client。 叁种不同的Notification类型支援需要的种类,例如:像股票讯息或比较即时的通知讯息,可以使用Toast Notification的类型,即时出现于用户的Device上并且支援工作的处理;Tile Notication就比较适合做为广告 的讯息或是有更新通知的讯息。但不管使用何种讯息,均需要Device有网际网路的能力。 [Notification传送常见的情形] (1). 传送Tile Notification时,Push Client不正在Start画面: 正常的传送至Push Client端,Quick lauch中的图示自动更换。(代表Connection未断线)。 *如果该Application没有建立在Start页中的Quick Lanuch时,Notifier所收到的Notification Status是暂停的。 =>如果重新把Application加到Quick Lanuch,被暂停的讯息仍然不会送到Push Client端。 (2). 传送Toast Notification时,Push Client不在正Start画面: 正常的传送至Push Client端,画面正上方出现(包括application icon、讯息1与讯息2),存留时间约10秒。 (代表Connection未断线)。 (3). 传送Raw Notification时,Push Client不在Application画面时: 讯息无法送达,Notifier会出现连线状态正常,订阅状态正常,而Notification Status是被暂停的。因为Push Client端目前正与Channel连线。 =>启动Appliation:讯息送达,该讯息是上一封Notifier送出,但Notification Status是暂停的那一个讯息。 *推论:(以下是个人的推论,仍然要确认) 从上述叁个案例说明:当建立一个Application具有可以接受Tile或Toast的Notification时,要特别注意: Tile Notification:只有在Applicatoin被加入到Quick Lanuch时,才真正被Push Client端收到。(也表示有连线) Toast Notification:只要你安装了该Application就会被启动Channel,代表连线是一直存在的。 Raw Notification:只有在Application正被执行时才能正确收到讯息,代表连线状态只有在那个时候。 *此处提到的连线所指的是WP Device与MNPS建立起Channel连线的时候。 ------------------------- 了解上述所介绍的Notification种类与运作的机制之后,另外接下来就是要了解到底整个準备使用Push Notification时, 各种角色之间需要準备与处理的工作内容。由于介绍WP7结合Nofitication Service的範例太多了,详细的请参考百度。
参考地址:http://www.61ic.com/Mobile/iPhone/201103/30038.html
从上图可以清楚看出叁个角色: ‧Notifier (Web Service Provider) 可以称之为通知者或是Notification服务提供者,身为该角色如果需要提供Notification的服务,便需要向 Microsoft Push Notification Service (MPNS)的伺服器註册需要的Channel,配合Protocol与MPNS进行沟通。 ‧Microsoft Push Notification Service (MPNS) 主要扮演中介者的角色,负责将Notifier欲发送的资料内容转接给subscribers(如:WP App/Device)。 它接受由Notifier所申请的Service Name进行註册,让Push Client可以在建立Channel时指定需要的Service。 它也接受Push Client申请需要的Channel来进行沟通。 [註] Notifier送出的资讯会被MPNS存着,等MPNS与Push Client建立此Channel之后才会被送达Client端。 ‧Push Client (Windows Phone Device/App) Push Client要取得资料的话,则需要向MPNS建立起独有的Channel,因此,Push Client会向MPNS送出询问 是否存在指定的Service Name与专用的Channel名称。例如: 1: //The name the application uses to identify the notification channel instance. 2: //該channelname參數是專屬該應用程式使用的。 3: httpChannel=new HttpNotificationChannel(string channelname); 4: 5: //The service name that the web service uses to associate itself with the Push Notification Service. 6: //該service name來用代表web service註冊於NPS裡的name。 7: httpChannel=new HttpNotificaitonChannel(string channelname, string servicename); Notificatoin Type主要有:Tile、Toast、Raw叁种。 ‧Tile Nofitication 使用固定的XML格式做为传输资料的规範。通常是比较多视觉、动态的内容,支援修改WP Start画面 中的Quick Launch area(例如:
),包括:背景图示、Tile或Title文字、计数器等。可参考此篇。 传输的範例内容如下 1: <?xml version="1.0" encoding="utf-8"?> 2: <wp:Notification xmlns:wp="WPNotification"> 3: <wp:Tile> 4: <wp:BackgroundImage><background image path></wp:BackgroundImage> 5: <wp:Count><count></wp:Count> 6: <wp:Title><title></wp:Title> 7: </wp:Tile> 8: </wp:Notification> 如果<background image path>是参考远端档案的话,该档案最大Size 80KB。最长的下载时间是一分鐘, 如果档案过大或是超过1分鐘下载时间,则直接使用预设的Tile内容。 ‧Toast Notification 使用固定的XML格式做为传输资料的规範。该类别比较像是即时通知,它会自动显示于目前画面中的最上方, 如果用户点取那段讯息,将会直接启动所属讯息的应用程式,进一步完成接收完讯息之后的动作。 其传输的格式如下: 1: <?xml version="1.0" encoding="utf-8"?> 2: <wp:Notification xmlns:wp="WPNotification"> 3: <wp:Toast> 4: <wp:Text1><string></wp:Text1> 5: <wp:Text2><string></wp:Text2> 6: </wp:Toast> 7: </wp:Notification> ‧Raw Notification 使用自订的XML格式,因此在Push Client端需要针对Raw Notification进行自订的处理。该类型的使用只限于 当Application执行在前端时才能正常的传递。如果该程式变成了暂存模式(tombstoned),Notifier所送出的讯 息会被暂留在NPS中,等到Application回到启动模式时,留在NPS中的内容会被在送达Client。 叁种不同的Notification类型支援需要的种类,例如:像股票讯息或比较即时的通知讯息,可以使用Toast Notification的类型,即时出现于用户的Device上并且支援工作的处理;Tile Notication就比较适合做为广告 的讯息或是有更新通知的讯息。但不管使用何种讯息,均需要Device有网际网路的能力。 [Notification传送常见的情形] (1). 传送Tile Notification时,Push Client不正在Start画面: 正常的传送至Push Client端,Quick lauch中的图示自动更换。(代表Connection未断线)。 *如果该Application没有建立在Start页中的Quick Lanuch时,Notifier所收到的Notification Status是暂停的。 =>如果重新把Application加到Quick Lanuch,被暂停的讯息仍然不会送到Push Client端。 (2). 传送Toast Notification时,Push Client不在正Start画面: 正常的传送至Push Client端,画面正上方出现(包括application icon、讯息1与讯息2),存留时间约10秒。 (代表Connection未断线)。 (3). 传送Raw Notification时,Push Client不在Application画面时: 讯息无法送达,Notifier会出现连线状态正常,订阅状态正常,而Notification Status是被暂停的。因为Push Client端目前正与Channel连线。 =>启动Appliation:讯息送达,该讯息是上一封Notifier送出,但Notification Status是暂停的那一个讯息。 *推论:(以下是个人的推论,仍然要确认) 从上述叁个案例说明:当建立一个Application具有可以接受Tile或Toast的Notification时,要特别注意: Tile Notification:只有在Applicatoin被加入到Quick Lanuch时,才真正被Push Client端收到。(也表示有连线) Toast Notification:只要你安装了该Application就会被启动Channel,代表连线是一直存在的。 Raw Notification:只有在Application正被执行时才能正确收到讯息,代表连线状态只有在那个时候。 *此处提到的连线所指的是WP Device与MNPS建立起Channel连线的时候。 ------------------------- 了解上述所介绍的Notification种类与运作的机制之后,另外接下来就是要了解到底整个準备使用Push Notification时, 各种角色之间需要準备与处理的工作内容。由于介绍WP7结合Nofitication Service的範例太多了,详细的请参考百度。
参考地址:http://www.61ic.com/Mobile/iPhone/201103/30038.html
相关文章推荐
- Hyperledger Fabric 排序服务核心原理和工作过程
- IOS平台的几个推送服务的对比
- 8-3 简要说明RFID系统的时隙ALOHA算法的工作过程
- Android应用程序与SurfaceFlinger服务的连接过程分析
- 服务器配置ASP.NET服务过程
- 使用GCM服务(Google Cloud Messaging)实现Android消息推送
- 友盟推送的详细过程
- MapReduce中wordCount程序工作过程分析
- Kubernetes下web服务的性能测试三部曲之一:准备工作
- 笔记,介绍编译器工作过程
- 基于位置服务的信息推送系统设计
- [转][改]DataAdapter工作过程详解
- Android推送服务——百度云推送
- 微服务≠高逼格!一文解构微服务拆分全过程 - 架构
- linux的引导过程和服务控制
- Android窗口管理服务WindowManagerService计算窗口Z轴位置的过程分析
- 【原创】Altera系列工具(QuartusII、SOPC Builder、NiosII IDE)工作过程分析
- Esper企业版介绍(三)Esper推送服务--从CEP层到WEB层的数据推送
- 在职场工作的进化过程 推荐
- 编译器的工作过程