Mobile backed app idealista

Charla en Madrid, Ironhack 10 julio 2014

Pequeña introducción para ironhack del proceso de notificaciones push creado adhoc para la app de idealista

1. chema rodríguez @durbon mobile backed app idealista 10 julio 2014
2. • api first! • notificaciones push • herramientas • proceso de envío de notificaciones de idealista • ¿cómo trabajamos juntos? /índice
4. “las APIs son el pegamento de las apps e internet”
5. Mobile Backend = API + Notificaciones Push
6. API REST • JSON (formato de facto) • Stack en Java: Spring framework, Solr, Oracle, MongoDB, Redis, ActiveMQ
7. API: Acciones y consultas • Búsqueda geográfica y por zona • Información completa de cada anuncio • Usuario: favoritear, descartar, comentar, contactar, guardar alertas • Subir fotos
8. ¿API pública? • Ahora, no. Próximamente abierta para todos • API V3 sólo para las apps de iOS y Android • Disponible la V1 (sólo búsqueda geográfica)
9. alertas de nuevos inmuebles 1. email 2. notificaciones push
10. Push Notifications ¿Cuántas notificaciones recibimos al día?
11. Tipo de notificaciones 1. Notificaciones masivas (todos) 2. Suscripción a un topic concreto 3. Notificaciones individuales al usuario
12. Planteamiento inicial y riesgos • Registro en APNS del dispositivo • Sincronización entre usuarios: relacionar usuario idealista con su dispositivo • Badge del número de notificaciones • Límites de envío
13. Herramientas disponibles: soluciones de terceros
14. Herramientas disponibles: soluciones de terceros Ventajas • No necesitas tener un backend propio • Barato si no requieres muchos envíos • SDKs y clientes específicos para iOS o Android. Fácil integración • Paneles de desarrolladores: gestión tipos de push • Integración con plataformas en la nube (Amazon o Google) Inconvenientes: • Sincronización usuarios BBDD propias fuera de la del servicio • Costes en altos volúmenes de envío
15. Solución adhoc Librería JAVAPNS https://code.google.com/p/javapns/ • Encapsula la comunicación con Apple Push Notification Service(APNS) • gestión del certificado de nuestra app (sandbox y production) • Gestión de errores • Envío multihilo de mensajes
16. • API para el registro de usuarios y activación de alertas • Construcción de una librería propia (dependencia Maven) de composición de notificaciones (Apple y Android). ◦ Combinamos JAVAPNS y GCM (también tenemos Android) ◦ Creamos el mismo mensaje independiente de la plataforma ◦ Unificamos la gestión de errores de cada plataforma • Proceso de envío de notificaciones ◦ Consume alertas que notificar a queue de JMS ◦ Consultar usuario-token device para el envío ◦ Construcción de mensaje (BBDD y librería) ◦ Feedback de errores (canonical deviceID)
17. PushMessage String localizedAlert; List<String> localizedArgs; Map<String, String> customParameters; int badge; { action = newAds; adId = 25403184; adsNumber = 1; alertId = 513466; aps = { alert = { "loc-args" = ( 1, "pisos, centro hasta 150.000" ); "loc-key" = "%@ anuncios: %@"; }; badge = 0; sound = default; }; typology = homes; } "loc-key" debe de estar en los ficheros localizables de la app. el valor "loc-args" son los posibles argumentos que puede tener el texto: Payload
18. Componentes • Tablas de base de datos para la gestión de dispositivos y registro de notificaciones enviadas: dispositivos activos, log de notificaciones enviadas/falladas/reintentadas, Contador del badge (usado para el envío del badge a iOS). • Cola JMS a los que estamos suscritos para enviar las alertas • proceso app de envío de notificaciones escalable • proceso de reenvío de notificaciones fallidas • proceso de feedback para el de-registro de dispositivos (cada madrugada)
19. ¿cómo trabajamos juntos? • documentación API • entornos de testing (pre producción) • sandbox para APIs aún en desarrollo • test de integración con CORE de idealista • y sobre todo ser ágiles + mucha comunicación
20. ¿preguntas? desarrollo.imasd@idealista.com ¿quieres trabajar con nosotros? mándanos tu CV!