通过apns将消息推送到客户端。现在一般点开信息,会直接跳转到app。 现在有一个需求,app更新,需要推送通知,办法可以做到点击消息,可以直达app store进行软件更新。
补充:在不改动软件的前提下。 补充2:一次推送10w+的信息,有没有提升消息到达率的方法,求方法。
学习是最好的投资!
在改动软件的情况下,想到一个方法。推送消息时增加个一个消息类型,然后在应用内进行判断,在软件内跳转到appstore。
在不改变已发布App的情况下,没办法。这个实现原理是,一个Push Notification出来,App接收到以后,可以解析Notification的信息,一般这个信息包括:声音,badge,和userinfo。 每次App接收到一个Notification都会进入AppDelegate 里的这个方法
- (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo {}
在这里,拿到userInfo的字典就是apns的服务端传过来的。通过判断userInfo的数据和当时应用所处的状态(正在浏览某个页面、是否处在运行状态,等等),决定如何对改Notification做出反应。 一般来说,如果应用正在运行状态,一个Notification进来了,就不做任何处理(应用Become active的时候需要你记录一个状态,Enter background和Terminate的时候也要记录,还有异常退出等情况要考虑);如果应用处在后台或关闭状态,则可以选择跳转到某个页面,或其他App(如AppStore)。
题外话:为了方便跳转操作,一般我建议应用中的每一个界面都对应一个URL,并且允许传递参数(形似TT的那个URL管理),自己做,可以非常简洁。这样有几个好处:
在改动软件的情况下,想到一个方法。推送消息时增加个一个消息类型,然后在应用内进行判断,在软件内跳转到appstore。
在不改变已发布App的情况下,没办法。这个实现原理是,一个Push Notification出来,App接收到以后,可以解析Notification的信息,一般这个信息包括:声音,badge,和userinfo。
每次App接收到一个Notification都会进入AppDelegate 里的这个方法
在这里,拿到userInfo的字典就是apns的服务端传过来的。通过判断userInfo的数据和当时应用所处的状态(正在浏览某个页面、是否处在运行状态,等等),决定如何对改Notification做出反应。
一般来说,如果应用正在运行状态,一个Notification进来了,就不做任何处理(应用Become active的时候需要你记录一个状态,Enter background和Terminate的时候也要记录,还有异常退出等情况要考虑);如果应用处在后台或关闭状态,则可以选择跳转到某个页面,或其他App(如AppStore)。
题外话:为了方便跳转操作,一般我建议应用中的每一个界面都对应一个URL,并且允许传递参数(形似TT的那个URL管理),自己做,可以非常简洁。这样有几个好处: