Como quiero construir una comunicación confiable en aplicaciones móviles, ¿podría obtener informes fallidos de inserción (tal vez el dispositivo está fuera de línea) de los servicios de terceros (C2DM, APN, aeronave urbana)? O ¿Necesitamos construirlo por nosotros mismos?¿Cómo lograr un servicio confiable de mensajes push?
El objetivo previsto de Android C2DM es ahorrar batería para que su aplicación de servidor indique al dispositivo móvil que desea iniciar comunicaciones fiables.
Puede estructurar su mensaje para que cada nuevo C2DM abarque todo lo que ha ocurrido desde la última interacción bidireccional con el servidor (es decir, "venga y obtenga lo que tenga"). Su informe de entrega fallido está implícito en que el dispositivo móvil no responde rápidamente (puede hacerlo porque sabe que C2DM activa su aplicación con un Intento).
¿Es eso realmente peor que la entrega garantizada de cada mensaje en un medio con pérdida? Está bien, es peor porque también tienes que implementar un método de comunicación primario. Pero tuviste que hacer eso de todos modos porque C2DM es solo de entrada, ¿verdad?
Estoy sugiriendo para la notificación de inserción del protocolo IBM MQTT. Esto lo suficientemente fino para la notificación de inserción. ver la demostración de https://github.com/tokudu/AndroidPushNotificationsDemo
¡Gracias por su respuesta! Pulgar arriba primero para su respuesta. –
Como dice Vinay, MQTT puede ofrecerle la característica que desea. Cuando un cliente se conecta al servidor, puede registrar un mensaje de "última voluntad y testamento" con el servidor. Si el cliente se desconecta inesperadamente, el servidor envía este mensaje al tema que se le indicó que hiciera.
En este esquema, su cliente podría enviar un mensaje "en línea" a algo así como el estado del cliente // y registrar el mensaje "fuera de línea" como un LWT para el mismo tema. A continuación, podría tener un cliente local del servidor que escuchara el tema cliente/+/estado y sabría qué clientes estaban en línea y cuáles fuera de línea.
Sugeriría que la demostración de tokudu no es el mejor lugar para buscar. Esta entrada del blog de Dale Lane da una idea de usar MQTT en Android: http://dalelane.co.uk/blog/?p=1599 y hay una revisión de uso de energía MQTT (de nuevo en Android) en http://stephendnicholas.com/archives/219
Hay implementaciones del cliente para satisfacer tanto a IOS y Android, ver http://mqtt.org/software
¡Gracias por su respuesta! Pulgar arriba primero para su respuesta. –
Y aquí hay otra comparación de uso de energía, esta vez a https: http://stephendnicholas.com/archives/1217 – ralight
Ningún servicio no proporciona informes sobre intentos fallidos.
Error informe de empuje hace poco SENCE con APN/C2DM/helio
Todos los servicios están orientados a entregar el mensaje push-bajo todas las circunstancias. Si el dispositivo está fuera de línea ahora, se enviará push cuando el dispositivo esté en línea.
Además, para iOS push-message es solo una notificación para un usuario, ¡no para una aplicación!
Caso simple lo ilustrará: Supongamos que se recibe una inserción cuando la aplicación está apagada. En ese caso, se producirá una notificación para el usuario. ¡Pero, la aplicación recibirá datos de la inserción, solo si el usuario toca esa notificación! Si el usuario toca el icono de la aplicación, no se recibirán los datos.
De manera tan técnica, push se entrega en el dispositivo iOS y se inicia la aplicación, pero no se entregan los datos.
UrbanAirhip con la APN y el helio
Se puede considerar para implementar su propio medio de transporte para los empujones. MQTT parece ser una buena opción. Pero en este caso, tiene que lidiar con keepalives, dispositivos para dormir y optimizaciones de la batería. Todo ese trabajo duro ya lo hacen ingenieros de Apple, Google y UrbanAirship.
Dependiendo de las necesidades de su negocio, puede ser más fácil adaptar su arquitectura a las soluciones existentes, luego volver a implementar el servicio push.
Eche un vistazo más de cerca a UrbanAiris. De hecho, C2DM tiene algunas limitaciones y, a veces, los tiempos para la entrega del mensaje push son demasiado grandes. Debido a que UA ha implementado su propio transporte, helio, funciona bastante bien. Helium es un servicio pago, pero UA proporciona un buen SLA.
Hice algo similar donde tenía una base de datos para hacer un seguimiento de las colas de espera para suscriptores conocidos y tuve informes cuando fallaron. Era muy simple y fue algo como esto ...
The schema was like so:
pushMessages
messageID , GUID, PK
message , nvarchar (256),
expires , datetime
messageQueues
subscriberID , GUID, PK
messageID , GUID PK
failedPushMessages
subscriberID, GUID, PK
messageID , GUID PK
(subscriber table omitted)
Una vez que un cliente ha recibido el mensaje con éxito, el cliente podría hacer ping al servidor de empuje y notificarlo a través de la queueItems identificador único que se recibió en el pulsador notificación. También habría un proceso de base de datos diario que verificaría los mensajes de inserción vencidos. Cuando se encuentre, se uniría a los mensajes queue que coinciden con el ID de mensaje y luego se eliminarán de la tabla messageQueues y se copiarán a la tabla failedPushMessages.
Esto fue muy fácil de entender y mantener, pero no tengo experiencia haciéndolo de otra manera.
Los servicios de inserción son una manera eficiente y confiable de alertar a los usuarios. Permiten que incluso las aplicaciones en segundo plano informen a los usuarios de nueva información en tiempo real. Los servicios Push se usan ampliamente para una variedad de campos en aplicaciones móviles, como actualizaciones del clima, servicios de mensajería, notificaciones por correo, servicios de cupones, etc. Los Servicios Push ya no son opcionales, pero se han vuelto esenciales.
¡Gracias! Creo que es adecuado para cualquier servicio basado en push que no sea confiable. Evaluaré cada respuesta y otorgaré la mejor para mí. –