使用第三方推送功能变相实现一些即时通讯操作

有个需求:
当用户端点击一个按钮申请时,界面上按钮变为 “审核中”

此时,管理端的工作人员点击同意审核后, 用户端的按钮从“审核中”变成”已通过”

这个操作肯定是不能让用户自己去刷新的,否则体验不好

几种常见的解决方案实现原理
1）轮询(Pull)方式：客户端定时向服务器发送询问消息，一旦服务器有变化则立即同步消息。
2）SMS(Push)方式：通过拦截SMS消息并且解析消息内容来了解服务器的命令，但这种方式一般用户在经济上很难承受。
3）持久连接(Push)方式：客户端和服务器之间建立长久连接，这样就可以实现消息的及时行和实时性。

第一种太浪费流量和性能,除非没办法,尽量不要使用

第二种基本可以不考虑

使用第三方的长连接服务

介绍：这是最简单的方式，我们可以通过接入极光推送，百度推送，友盟等第三方服务实现长连接，通过接入第三方的API我们可以很方便的接入第三方的长连接，推送服务，但是这种方式定制化程度不太好，如果对长连接服务不是要求特别高，对定制化要求不是很高的话基本可以考虑这种方式（目前主流的App都是使用第三方的长连接服务）
优势：简单，方便
劣势：定制化程度不高

使用NIO等方案实现长连接服务

介绍：通过NIO的方式实现长连接，这种方式对技术要求程度比较高，基本都是通过Java API实现长连接，实现心跳包，实现异常情况的容错等操作，可以说通过NIO实现长连接对技术要求很高，一般如果没有成行的技术方案比建议这么做，就算实现了长连接，后期连接的维护，对电量，流量的损耗等都需要持续的优化。
优势：定制化比较高
劣势：技术要求高，需要持续的维护

使用MINA等第三方框架实现长连接

介绍：MINA是一个第三方的NIO框架，该框架实现了一整套的长连接机制，包括长连接的建立，心跳包的实现，异常机制的容错等。使用MINA实现长连接可以定制化的实现一些特有的功能，并且比NIO方案较为简单，因为其已经封装了一些长连接的特有机制，比如心跳包，容错等。
优势：可定制，较NIO方法简单
劣势：也需要一定的技术储备

我这边的APP已经集成了第三方推送,所以使用了长连接的第一种方法.

思路如下: 服务器向APP发送一个透传消息(可以理解成隐形消息),APP解析这个消息中的字符串, 当flag==1001时,发送一个广播.
另一方面,当用户在 界面上按钮变为 “审核中” 的页面时,在这个页面的activity注册一个BroadcastReceiver ,这是一个动态注册的接受者,然后在这个接受者中处理UI变更的事件

发起广播: