El documento aborda la teoría y programación de notificaciones en iOS, diferenciando entre notificaciones locales y remotas (push). Detalla métodos para manejar estas notificaciones, incluyendo ejemplos prácticos de programación y seguridad, así como la interacción con Apple Push Notification Service (APNS). Se concluye con recomendaciones sobre la gestión de notificaciones y mejoras en el diseño de aplicaciones relacionadas.

1. iOS Notifications
Teoría, programación, registro, envío, recepción, manejo,
etc...

2. Antes de empezar...
• Nombre
• ¿A qué te dedicas?
• ¿Por qué MIMO?
• ¿Qué experiencia tienes como programador?
• ¿Y de apps móviles?
• ¿Qué sabes de las notificaciones de iOS?

3. Metodología

4. Metodología

5. Sobre las dudas...

6. Índice de contenidos
• Introducción
• Notificaciones locales
• Notificaciones remotas
• Proveedor de notificaciones
• Un caso práctico

7. Introducción
Conociendo las notificaciones

8. ¿Qué es una notificación?

9. • Comunicación oficial y con las
formalidades preceptivas de
una resolución.
• Noticia veraz de algo.
RAE, 2005
¿Qué es una notificación?

10. ¿Qué es una notificación?
Mecanismo que tienen las
aplicaciones móviles que no
se están ejecutando en primer
plano para indicar al usuario
que tiene alguna información
para él.

11. ¿Cómo se muestran?

12. ¿Y luego?

13. ¡Empezamos!

14. Notificaciones
Notificaciones locales y remotas en profundidad

15. Propósito
Permitir a una aplicación informar
al usuario que tiene algo para él.

16. Casos prácticos

17. Notificaciones locales
• Almacenadas y entregadas por el propio
sistema operativo.
• Útiles para aplicaciones tipo calendarios,
recordatorios, temporizadores, etc...
• Límite de 64 notificaciones programadas
por aplicación.

18. Notificaciones Locales
App iOS
App iOS
Programación
Entrega

19. Notificaciones remotas
• Conocidas como notificaciones Push.
• Almacenadas por un servidor propio.
• Enviadas por internet (Wi-Fi, 3G, ...).
• Entregadas por APNs al dispositivo.
• Útil para aplicaciones y/o juegos con
interacción entre usuarios.

20. Push vs. Pull design
Client Server
...
Client Server
Pull
Push

21. Notificaciones Push
App
iOS
Server
APNs

22. Notificaciones Locales
Programación, recepción y manejo

23. Calentamiento
• Crear una nueva aplicación iOS.
• Cuando arranque debe mostrar una
pantalla con un sólo botón.
• Cada vez que se pulse el botón, se debe
mostrar un mensaje por consola.
• La aplicación debe funcionar en el
dispositivo real, no solo en el simulador.

24. Programación

25. Recepción

26. Manejo
Con la aplicación abierta (foreground o background)

27. Manejo
Con la aplicación cerrada...

28. Finalizando...
• Completar la aplicación para que cuando se
reciba una notificación se vaya directamente a
una pantalla que muestre los detalles de esa
notificación.
• La gestión de pantallas debe realizarse
mediante un UINavigationController.
• Debe funcionar tanto si la aplicación esta en
background, foreground o cerrada.

29. ... y esto?

30. Badge
Asignación
Manejo
¡¡Asigna directamente el valor al badge!!

31. Badge
• Finalizar la aplicación de ejemplo añadiendo
funcionalidad para poner a cero el badge
cuando la notificación sea ‘leída’.

32. Puesta en común
• ¿Cómo diseñaríais una aplicación de
recordatorios basados en fechas?
• El badge debe indicar exactamente el número de
tareas pendientes

33. Conclusiones
• No se puede controlar el badge 100%,
habrá que actualizarlo desde la app siempre
que sea posible.
• La funcionalidad de nuestra aplicación no
puede depender de la notificación, ya que
ésta puede no recibirse o ser ignorada.

34. Notificaciones Push
Registro, envío, recepción y manejo

35. Notificaciones Push
App
iOS
Server
APNs

36. APNs
• Siglas de Apple Push Notificacion service.
• ‘Piedra Angular’ del sistema de
Notificaciones Apple.
• Recibe y distribuye las notificaciones a sus
destinatarios.
• Esa distribución es un servicio PUSH.

37. ¿Servicio Push?
• ¿Qué es?
• ¿Cómo se consigue?
• ¿Qué ocurrirá con la
notificación si el
teléfono está apagado?
• ¿Y si no tiene internet?

38. APNs: Seguridad
Mecanismo 1: Seguridad basada en certificados digitales para todas las
comunicaciones.
Aseguramiento de la conexión dispositivo - APNs Aseguramiento de la conexión server - APNs

39. APNs: Seguridad
Mecanismo 2: Seguridad basada en un token único que identifica a cada
dispositivo.
Generación y distribución del token Notificación

40. APNs: Seguridad
• Servidor
• Certificado proporcionado por Apple.
• Token de los dispositivos.
• Aplicación Cliente
• Certificado proporciondo por Apple
(code sign).
• Haber enviado su token al servidor.

41. DEMO
Generación de certificados, configuración del app, ...

42. APNs: Otros servicios
• Servicio de información (feedback) que
indica los dispositivos que rechazaron
notificaciones.
• Política de almacenamiento y reenvío (store
and forward), si el destinatario no se
encuentra conectado.

43. Calentamiento
• Crear una nueva aplicación iOS que tenga
un sólo botón en pantalla.
• Cuando arranque debe mostrar una vista
oscurecida, tapando el botón y un
UIActivityIndicator en el medio girando
constantemente y un mensaje de espera.
• La aplicación debe funcionar en el
dispositivo real, no solo en el simulador.

44. Registro APNs
• Cuando se complete el registro, la vista de carga debe
desaparecer.
• El botón debe habilitarse/deshabilitarse dependiendo de si
el registro fue correcto o no.

45. Solicitando notificaciones
• El botón de la pantalla servirá para solicitar notificaciones
a un provider.
• API del provider:
• POST http://mimo-apns.herokuapp.com/users/greet
• Body(JSON): {“name”:“<nombre>”,“token”:”<token>”}
• El token debe contener sólo números y letras, no
espacios en blanco ni otros caracteres.
• Pista: Para asegurarnos de que el provider interpreta el
body como JSON se debe especificar la cabecera “Content-
Type” con “application/json”

46. Solicitando notificaciones

47. Proveedor de
notificaciones
Construcción de un servicio proveedor de
notificaciones en Play! Framework

48. Provider
• Crear un nuevo proyecto en Play!
Framework.
• Debe recibir un POST en la url /users/
greet. En el body recibirá un JSON:
• {“name”:”El name”,“token”:”El token”}
• Cuando se reciba la petición, se imprimirán
por consola los dos valores recibidos
(name y token)

49. Provider
/conf/routes
/app/controllers/User.java /app/models/User.java

50. Requisitos
• Componer el payload de la notificación
• Comunicación con API APNs
• Comunicación segura (TLS)
• Envío de datos en binario
• Recepción de la respuesta en binario
• Enviar notificaciones ‘en grupos’
• Obtener feedback periódicamente

51. Provider
• Construir el JSON que se enviará como ‘payload’ a APNs
{
"aps": {
"alert": "Welcome<name>",
"sound": "default",
"badge": 1
}
}
• Pista: Utilizar las clases JsonObject y/o JsonElement para
construir el JSON. No lo hagáis a mano.
• Imprimir el JSON por consola. (toString())

52. Provider

53. Requisitos
• Componer el payload de la notificación
• Comunicación con API APNs
• Comunicación segura (TLS)
• Envío de datos en binario
• Recepción de la respuesta en binario
• Enviar notificaciones ‘en grupos’
• Obtener feedback periódicamente

54. SSL/TLS
• Framework para establecer conexiones
seguras entre dos partes que quieren
comunicarse.
• La comunicación se inicia con una fase de
handshake:
• Deciden algoritmo, longitud de clave,
intercambian certificados y, usando encriptación
asimétrica, comparten la clave simétrica final.

55. Claves y certificados
• Claves de cifrado asimétrico
• Generadas en pares (pública-privada)
• Contenido cifrado con una sólo puede ser descifrado
por la otra
• Contenido firmado con una sólo puede ser verificado
por la otra
• Certificados
• Clave pública + información identificativa + fecha de
expiración

56. Confianza
• ¿Cómo saber si el certificado que nos están
presentando es veraz?
• 1º:¿El certificado es válido?(no ha expirado)
• 2º: ¿El certificado corresponde al host que
lo presenta?
• 3º: ¿Confiamos en la CA que lo generó?

57. SSL/TLS
Unidireccional Bidireccional

58. SSL en JAVA

59. Requisitos
• Componer el payload de la notificación
• Comunicación con API APNs
• Comunicación segura (TLS)
• Envío de datos en binario
• Recepción de la respuesta en binario
• Enviar notificaciones ‘en grupos’
• Obtener feedback periódicamente

60. API APNs
• byte 1
• Identificador único de la notificación
• UNIX Timestamp de expiración (en segundos)
• Longitud del token
• Token del dispositivo en binario
• Longitud del payload
• Payload (máximo 256 bytes y no acabar en null)

61. Antes de empezar...
• ¿Cuántos bits componen un byte?
• a) 4
• b) 8
• c) 16
• d) Todas son correctas :)

62. Antes de empezar...
• ¿Cómo se representa una serie de bits en
código fuente?
• a) 0x101010101
• b) 0xFFFF
• c) 1010101
• d) 0b1010101

63. Antes de empezar...
• ¿Cómo se extraen, por programación, los
bytes de un número?

64. Máscaras
• Se aplican con la operación AND (&).
• Sólo dejan ‘pasar’ cierta información.
• Sirve para detectar qué bits están ‘levantados’
1001001
0011000
0001000
&
Máscara

65. Desplazamiento de bits
• Simplemente desplaza bits
• (número) << posiciones
• 0b1 << 1 = 2 (0b10)
• 0b101<< 2 = 20 (0b10100)
• (número) >> posiciones
• 0b1 >> 0 = 0
• 0b101 >> 2 = 1 (0b1)

66. Trabajando con bits
• Crear un nuevo proyecto iOS llamado
BitsHandler.
• Construir la interfaz necesaria para que el
usuario introduzca un número y se le
muestre su representación binaria.
• Pista:Aplicar una máscara con un sólo bit a 1, sucesivamente
para ir obteniendo si el número introducido tiene o no el bit
correspondiente ‘levantado’.

67. Trabajando con bits

68. Trabajando con bytes
• Un byte son 8 bits
• Un número hexadecimal son 4 bits
• Un un byte son 2 números hexadecimales
• (byte)8 = 0b00001000 = 0x08
• (byte)255 = 0b11111111 = 0xFF

69. Trabajando con bytes
• Añadir al proyecto BitsHandler la capacidad
para mostrar también los bytes por que
está compuesto el número introducido.
• Pista: Recordad que un ‘int’ contiene 32 bits y un
byte 8.

70. Trabajando con bytes
¿Usable?
¿Cómodo?

71. Números hexadecimales
• Facilitan el manejo a nivel de bits.
• Toman valores desde 0 a 15
• Ocupan 4 bits
• 0b00000000111111110000000011111111 =
0x00FF00FF
• ¡¡Mucho más manejable!!

72. Números hexadecimales
• Reescribir la función anterior utilizando
notación hexadecimal en lugar de notación
binaria para la extracción de los bytes.

73. Números hexadecimales
• Reescribir la función anterior utilizando
notación hexadecimal en lugar de notación
binaria para la extracción de los bytes.

74. Números hexadecimales
• El deviceToken se recibe en el AppDelegate
como un array de bytes de números
hexadecimales.
• Escribir el código de la función description
del objeto NSData.
• Pista: Para representar un byte como dos
números hexadecimales usad formateo: %02X

75. Números hexadecimales

76. Provider
• Construir el array de bytes que se transmitirá
a APNs.
• Pista: Poner en práctica todo lo aprendido.
• Pista: Utilizar un ByteArrayOutputStream para
escribir bytes a un array
• Pista: Comprobar el resultado con ByteArrayChecker.

78. Envío
• Enviar los datos binarios a través del
OutputStream del Socket.
• Recibir la notificación!

79. Envío
• Enviar los datos binarios a través del
OutputStream del Socket.
• Recibir la notificación!

80. Requisitos
• Componer el payload de la notificación
• Comunicación con API APNs
• Comunicación segura (TLS)
• Envío de datos en binario
• Recepción de la respuesta en binario
• Enviar notificaciones ‘en grupos’
• Obtener feedback periódicamente

81. Respuesta
• ¡¡APNs SÓLO responde en caso de error!!
• Componentes:
• byte 8
• byte que indica el status
• Identificador único que se envió junto con la notificación.

82. Códigos de error

83. Provider
• Recibir y parsear la respuesta, si la hay.
• Consejo: Siempre utilizar BufferedInputStream para leer
datos de red.
• Pista:APNs no devolverá nada en caso de haber aceptado
la notificación. Utilizar el timeout del socket
sslSock.setSoTimeout.

84. Provider

85. Requisitos
• Componer el payload de la notificación
• Comunicación con API APNs
• Comunicación segura (TLS)
• Envío de datos en binario
• Recepción de la respuesta en binario
• Enviar notificaciones ‘en grupos’
• Obtener feedback periódicamente

86. Puesta en común
¿Qué problemas presenta este provider?

87. Puesta en común
¿Qué problemas presenta este provider?
¿Cómo solucionarlos?

88. Mejorando el provider
• Utilizar Asynchronous Jobs de Play! para procesar el
envío de las notificaciones.
• http://www.playframework.com/documentation/1.2/jobs
• Opción 1: Procesar el envío de notificaciones en
Jobs ‘inmediatos’.
• Opción 2:Almacenar las notificaciones pendientes y
enviarlas en grupos utilizando un Job periódico.
• Tener en cuenta que si APNs rechaza una notificación,
inmediatamente responde y cierra la conexión, por tanto, las
siguientes notificaciones deben reenviarse.

89. • Componer el payload de la notificación
• Comunicación con API APNs
• Comunicación segura (TLS)
• Envío de datos en binario
• Recepción de la respuesta en binario
• Enviar notificaciones ‘en grupos’
• Obtener feedback periódicamente
Requisitos

90. Feedback
• Informa de notificaciones rechazadas por
los dispositivos.
• Interfaz binario:
• Recomendable consultarlo una vez al día.

91. • Componer el payload de la notificación
• Comunicación con API APNs
• Comunicación segura (TLS)
• Envío de datos en binario
• Recepción de la respuesta en binario
• Enviar notificaciones ‘en grupos’
• Obtener feedback periódicamente
Requisitos

92. Caso Práctico

93. Caso Práctico
User
Device
iOS Android
Notification
iOS Android

94. Carlos Alonso Pérez
Developer
Twitter: @calonso
LinkedIn: mrcalonso
Mail: info@mrcalonso.com
¡Gracias!