关于推送通知,iOS推送主要是通过服务端来实现的,相关过程可以参考下面两篇文章:
文章中介绍的jar包列表:
- bcprov-jdk16-145-1.jar
- commons-io-2.0.1.jar
- commons-lang-2.5.jar
- javapns-jdk16-163.jar
- log4j-1.2.16.jar
其中介绍最全面的是这篇blog:http://tanqisen.github.io/blog/2013/02/27/ios-push-apns/
整体流程如下图所示:
其中涉及到的角色有:
- Provider:应用自己的服务器;
- APNS:Apple Push Notification Service的简称,苹果的PUSH服务器;
OS设备连接网络后,会自动与APNS保持类似TCP的长链接,等待APNS推送消息的到来;
应用启动时注册消息推送,并获取设备的在APNS中注册的唯一设备标示deviceToken上传给应用服务器(即Provider);
在需要给应用推送消息时,Provider把push内容、接收push消息的deviceToken按APNS指定的格式打包好,发送给APNS;
APNS收到Provider发送的消息后,查找deviceToken指定的设备,如果该设备已经和APNS建立了连接,则立即将消息推送给该设备,如果设备不在线,则在该设备下次连接到APNS后将消息推送到设备。请注意苹果并不保证推送一定成功;
设备收到push消息后,iOS系统会根据SSL证书判断这个push消息是发给那个应用的,进而启动相应客户端。
上述过程中,有两个关键步骤需要自己处理的是:1.客户端获取deviceToken,并上传到Provider;2.Provider发送push消息到APNS。这两个步骤中都需要苹果的push证书授权,下面就来介绍如何生成push证书,以及Provisioning Profile。
pom.xml中额外依赖一下的jar包:
<!-- Apple Push Notification Related Dependencies -->
<dependency>
<groupId>org.bouncycastle</groupId>
<artifactId>bcprov-jdk16</artifactId>
<version>1.46</version>
</dependency> <dependency>
<groupId>com.github.fernandospr</groupId>
<artifactId>javapns-jdk16</artifactId>
<version>2.3.1</version>
</dependency>
发送消息通知的代码如下所示:
String deviceToken = "xxxxxxx";
//被推送的iphone应用程序标示符
PushNotificationPayload payload = new PushNotificationPayload();
payload.addCustomAlertBody("通知!");
payload.addBadge(1);
payload.addSound("default"); PushNotificationManager pushManager = new PushNotificationManager();
Device device = new BasicDevice(deviceToken);
String certificatePassword = "123456"; InputStream keyStoreFileInputStream = this.getClass().getClassLoader().getResourceAsStream("push.p12"); //注意:最后一个参数表明该请求是否为生产环境,如果配置的证书为测试使用的证书,请将该参数修改为false
pushManager.initializeConnection(
new AppleNotificationServerBasicImpl(keyStoreFileInputStream, certificatePassword,
true));
pushManager.sendNotification(device, payload);
pushManager.stopConnection();
发送消息通知涉及到的有deviceToken(每台设备,针对每个app都是不一样的),证书文件(keystore),验证密码,便可以正常向设置对应的APP发送通知了。
iOS 系统的推送(APNS,即 Apple Push Notification Service)依托一个或几个系统常驻进程运作,是全局的(接管所有应用的消息推送),所以可看作是独立于应用之外,而且是设备和苹果服务器之间的通讯,而非应用的提供商服务器。你的例子里面,腾讯 QQ 的服务器(Provider)会给苹果公司对应的服务器(APNs)发出通知,然后再中转传送到你的设备(Devices)之上。当你接收到通知,打开应用,才开始从腾讯服务器接收数据,跟你之前看到通知里内容一样,但却是经由两个不同的通道而来。
而 Android,就不同,更像是传统桌面电脑系统做法。每个需要后台推送的应用有各自的单独后台进程,才能和各自的服务器通讯,交换数据。另外其实 Android 也有类似 APNS 的 GCM(Google Cloud Message),属于开发者可选,非强制,但是Google的服务,你懂得。
自己开发倒不如直接用第三方的系统,不划算啊~费时费力,效果还不一定好。找个靠谱点的第三方,直接上去下载个文档用,方便啊。不知道你怎么看,我们公司比较了几家以后,使用第三方的极光推送来达到此目的,对应的Java SDK地址:http://docs.jpush.io/server/java_sdk/。
先去注册,登录完成后,即可创建一个新的应用,应用创建成功后,可以在应用信息下查看到具体详情:
应用信息
AppKey | xxxx | |
Master Secret | xxxx | |
创建日期 | 2016-03-17 13:10 | |
最后修改时间 | 2016-03-17 13:10 |
极光推送的文档相对来说还是比较全面的,从常见问题开始:http://docs.jpush.io/guideline/faq/
如果我们并不在服务端进行用户设备等数据的存储,那么就会丧失对所有的注册设备的所有权,只能通过极光推送的相关页面来手动发送通知,鉴于此,还是需要我们在后端设置对应的数据表来对所有注册用户进行处理。
推送服务的整体流程如下,以iOS为示例(android比较简单,不需要APNS服务角色)
整体的流程如下:
- 设备APP移动端向极光推送发送注册设备所需要的信息,包括deviceToken,手机号(用于收费版短信通知)等;
- 注册极光推送相关服务后,再向后端服务提供设备信息,注册的极光id,手机号用于后端存储;
- 后端服务需要将相关数据持久化;
- 如果触发了消息通知机制,一种方法是可以通过极光推送提供的网页端来进行,另外一种就是在后端服务中直接根据用户手机号/注册id/设备别名通过JPush API来进行;
- 极光推送服务收到通知后,需要将消息发送到APNS(Apple Push Notification Service)中;
- APNS根据设备deviceToken发送消息至移动端设备,点击后启动应用程序。
服务端的API主要分为以下几部分:
1. Push
向某一个或一类设备发送推送通知;
如果服务端使用Java作为开发语言,可以参考其中的Java SDK部分:http://docs.jpush.io/server/java_sdk/
需要注册极光推送ID相关的appKey,masterSecret等信息。
JPushClient jpushClient = new JPushClient(masterSecret, appKey, 3); // For push, all you need do is to build PushPayload object.
PushPayload payload = buildPushObject_all_all_alert(); try {
PushResult result = jpushClient.sendPush(payload);
LOG.info("Got result - " + result); } catch (APIConnectionException e) {
// Connection error, should retry later
LOG.error("Connection error, should retry later", e); } catch (APIRequestException e) {
// Should review the error, and fix the request
LOG.error("Should review the error, and fix the request", e);
LOG.info("HTTP Status: " + e.getStatus());
LOG.info("Error Code: " + e.getErrorCode());
LOG.info("Error Message: " + e.getErrorMessage());
}
JPush的相关文档以及API还是比较方便的,大量使用了创建者模式(Builder),可以快捷地创建推送对象,推送平台。
2. Report
Report API用于可以用于各类统计查询相关功能,Received API 以 msg_id 作为参数,去获取该 msg_id 的送达统计数据。如果一次 API 调用推送有很多对象(比如广播推送),则此 API 返回的统计数据会因为持续有客户端送达而持续增加。每条推送消息的送达统计数据最多保留一个月。即发起推送请求后从最后一个推送送达记录时间点开始保留一个月,如果保留期间有新的送达,将在这个新送达的时间点起再往后保留一个月。
如果我们想要对信息进行统计,那么需要在发送消息完成后记录该信息的msg_id。
3. Device
Device API可以用于服务器端查询,更新,删除设备的tags, alias信息,如果不想让APP客户端和服务端的tags,别名等信息互相覆盖,那么考虑只在 客户端或服务端来进行更新操作,http://docs.jpush.io/server/rest_api_v3_device/
但是服务端的Device API只能修改设备tags,alias信息,功能相对来说有局限,因此大部分功能的注册只能在客户端进行。
4. Schedule
在API层面,全面支持定时发送功能,这是一个相对独立的任务执行模块,http://docs.jpush.io/server/rest_api_push_schedule/。
可惜的是,JPush 的 Java SDK中并没有涉及到Device,Schedule相关的客户端可供直接使用,如果想要在服务端使用该功能,需要在参考JPush Java SDK的源码自己实现一部分功能。