Android推送通知解决方案（如果已连接到服务器）

我有一些应用程序依赖于服务器端。他们从那里得到了数据。 无论如何，服务器端需要开发。服务器代码托管在我们这边完成。客户端-服务器通信结构已启动。 在此状态下，我们需要实现推送通知： 如果服务器上有新数据，那么用户应该可以看到这些数据

现在推荐的“标准”方法是使用

我对此有几点担心：

• 需要客户端和服务器端编码，并将它们绑定到我们的代码中。这不是最大的：
• 技术在不断变化：不赞成，需要改变我们的代码。这是最大的。在这之前是另一件事，在那之前是另一件事。在4-5年内，3个变化太大了

我正在考虑这样实施：

当用户连接到internet时，我将编写一个广播接收器来收听。 在Internet连接上，它将检查服务器是否有新的内容。 如果是，它将显示一个通知，作业已完成。如果用户单击通知，它将启动应用程序并下载playload。 我将使用报警计划，在1、15分钟或4小时后再次检查服务器，无论什么在后台不会运行任何服务，只有接收器

注册-注销功能应该在应用程序中完成

与plus中服务器的通信：

registerMyDevice（IMEI）-或用户名+密码

取消注册我的设备（IMEI）

isSomethingNewData（）

当客户机到达服务器时，它将以任何方式发送他的IMEI以进行标识，这样服务器将知道谁需要发送推送

---

任何人都可以使用谷歌提出的解决方案，并证明它在这种情况下比我们的内部解决方案更好？

该解决方案的主要问题是，您将添加一个额外的后台进程，从而缩短电池寿命。想象一下，如果许多应用程序开发人员选择实现您的解决方案，将会发生什么。安装多个此类应用程序的用户将很快耗尽电池。使用GCM，一个连接与一台服务器保持，该连接服务于设备上的所有应用程序

---

我相信与GCM集成比自己开发推送解决方案更简单。API的变化总是伴随着改进而来（原来的GCM允许多个发送者，而C2DM不允许；新的GCM为您提供用户通知和设备到云的消息），但即使您不选择使用它们，旧的API仍然可以工作（即使它们被弃用）。

+1，“又一个缩短电池寿命的后台进程”这是错误的，因为报警管理器会让我的接收器死机。好的观点：“想象一下，如果许多应用程序开发人员选择实现您的解决方案，会发生什么情况”好的，警报管理器会工作，线程上下文切换->CPU工作，这一点很好，但还没有足够的动机来改变我的观点：）@matheszabi我在谈论广播接收器正在运行的情况。如果设备多次在WiFi和蜂窝数据连接之间切换，或者设备经常断开和连接，则每次连接都会执行接收器。一旦设备连接到互联网，仅仅联系服务器一次来检查新数据是否可用是不够的。您必须每X秒/分钟轮询一次服务器（取决于您希望通知用户的时间）。有了GCM，设备只有在知道有新数据可用后才会连接到您的服务器。设备从哪里知道GCM服务器上是否有新数据，是否没有定期检查？@matheszabi但GCM在设备上有一个进程对所有使用GCM的应用程序执行此轮询（如果确实是GCM使用的机制）。这就是区别。您将添加一个轮询服务器的进程，而不是使用已经在设备上运行的进程。在新的GCM云连接服务器中，他们甚至建议您使用此连接将消息从设备发送到服务器，而不是打开到服务器的连接，原因同样是为了节省电池。