[música]
- Hola a todos y bienvenidos. Mi nombre es Ryan.
Soy ingeniero de software del equipo Firebase
y trabajo con los SDK de Apple en la oficina de Waterloo, Canadá.
- Y yo soy Chen.
Soy ingeniera de software del equipo Firebase
y también trabajo con los SDK de Apple en la oficina de Sunnyvale, California.
- Nuestra misión es ayudar al éxito de los desarrolladores
facilitando la creación y el funcionamiento de aplicaciones.
- Firebase es un toolkit multiplataforma para desarrolladores móviles,
compatible con iOS junto con Android, Web, CIMA + y Unity.
Sabemos por qué están aquí.
Si están entusiasmados como yo, verán que el ecosistema de Apple
ha facilitado el desarrollo de aplicaciones multiplataforma
no solo para iOS y iPadOS, también para macOS, WatchOS, tvOS y Catalyst.
Es una larga lista.
En Firebase, estamos analizando algunos casos de uso
y poniéndolos a disposición en plataformas de Apple.
Los SDK de Firebase para plataformas Apple dan flexibilidad para liberar
flujos de desarrollo de iOS
y seguirán haciendo más en el futuro.
- Crear y ejecutar apps para iOS y otras plataformas de Apple
ha cambiado en los últimos años.
Swift es el lenguaje de facto para crear apps.
En esta sesión, veremos características y marcos de Swift.
SwiftUI, por ejemplo, nos permite crear espléndidas interfaces
utilizando una sintaxis simple y concisa.
Incluir SDK de Firebase en los proyectos con Swift Package Manager es muy fácil.
Async/wait y Combine
son nuevas formas de razonar en programación asincrónica.
En Firebase, observamos estos cambios de cerca.
Hoy mostraremos nuestro enfoque para estos cambios en el ecosistema.
Pero antes, Chen, ¿qué ocurre en el repositorio de GitHub?
- Voy a contártelo, Ryan.
Desde que Firebase adoptó código abierto en nuestras bibliotecas cliente en 2017,
la gran mayoría de los SDK de Firebase para plataformas Apple
están disponibles en GitHub.
El código fuente del SDK de rendimiento de Firebase
se abrió a finales de 2020. SI todavía no lo vieron,
échenle un vistazo y dígannos qué les parece.
Seguimos mostrando nuestro compromiso de mayor transparencia
para crear una gran comunidad de desarrolladores.
A la fecha, resolvimos más de 2000 problemas
y superamos las 5000 solicitudes de revisión.
A nuestro equipo de Firebase le gusta interactuar con Uds. en GitHub.
Recomendamos que dejen sus comentarios,
ya sean pedidos de funciones o problemas de errores,
ya que pueden hablar directamente con los ingenieros
que trabajan en los SDK, incluidos Ryan y yo.
Eso facilita mucho las conversaciones técnicas.
Por suerte, contamos con una gran comunidad de colaboradores.
Actualmente, 139 de ustedes
contribuyen con los SDK de Firebase para plataformas Apple.
Vemos colaboraciones activas de código abierto
entre miembros de la comunidad y Firebasers,
trabajando en compatibilidad con Combine.
Queremos darles las gracias a todos por mejorar nuestros SDK.
Ser de código abierto ha hecho posibles muchas cosas.
Poder revisar el código y saber cómo se comportan los SDK
ahorra horas de búsqueda de errores.
También habilitó funciones como el soporte comunitario
para tvOS, macOS, Catalyst y WatchOS.
Agregamos soporte comunitario de WatchOS
para configuración remota y BBDD en tiempo real.
Pueden probar esto en su app de reloj
y usar las discusiones de GitHub para hacer preguntas.
Muchos de ustedes ya comenzaron a usar Swift Package Manager
para gestionar dependencias.
Oficialmente, ahora Firebase admite Swift Package Manager.
Además de CocoaPods, usen Swift Package Manager para agregar
bibliotecas de Firebase a su app.
Se los mostraré rápidamente, hacerlo es muy fácil.
Primero, deben obtener las URL de la página del informe de SDK de Firebase iOS.
Copien y peguen las URL de la página.
Debería funcionar en muchas de las bibliotecas
alojadas o distribuidas a través de GitHub.
Ahora, abran su aplicación en Xcode, hagan clic en la pestaña File
y seleccionen Swift Packages. Luego, hagan clic en Add Package Dependency,
peguen las URL y hagan clic en Next.
Seleccionen la versión o rama a la que desean apuntar.
Recomendamos la última versión de nuestros SDK
para nuevas funciones…
y también para corrección de errores o mejoras.
Poco después, podrán seleccionar el producto que desean usar.
Aquí usaremos Analytics Auth
y vamos a probar las nuevas API de extensión de SwiftUI.
Si desean agregarlos en un destino diferente
(por ejemplo, en un reloj independiente)
y solo desean instalar mensajería en la app del reloj,
pueden elegir un destino de la derecha.
Cuando estén listos, hagan clic en Finish. Para ver los paquetes,
hagan clic en Project y seleccionan Swift Packages, aquí.
Para agregar más SDK de Firebase más adelante,
vayan al destino que quieren editar, hagan clic en General,
y en Frameworks, Libraries and Embedded Content
pueden agregar o eliminar SDK de Firebase manualmente si ya no los necesitan.
Ahora que creamos un nuevo proyecto con Swift Package Manager,
Ryan nos contará más sobre Swift y SwiftUI.
- Gracias, Chen.
A pesar de escribir nuestros SDK principalmente en Objective-C,
evaluamos cada API para ver cómo se importan a Swift
y tratamos de que sea una gran experiencia.
Pero ¿y los tipos de resultados, la compatibilidad con Codable,
parámetros predeterminados, o enumerados y tipos asociados?
Podemos aprovechar esas fantásticas funciones de Swift
al escribir en Objective-C. A veces, solo hay que escribir código Swift.
Así, lanzamos extensiones Swift opcionales para distintos SDK.
Y algunas fueron aportadas por la comunidad.
Repasemos algunos aspectos destacados. Vamos a ver mucho código.
En este fragmento, descargamos una imagen del almacenamiento de Firebase
con el controlador de finalización tradicional.
Los datos y el error son opcionales.
Eso da lugar a un código extraño que nos hace forzar y ajustar el error.
Nada que queramos hacer si podemos evitarlo.
Si los datos son nulos, el error debe estar completo
y si hay un error, los datos deben ser nulos.
Eso no se puede exigir en el compilador con el código existente.
Al usar la función que ofrece la nueva extensión de Swift,
podemos eliminar ese estado extraño y el desajuste forzado.
Con una instrucción de cambio, el compilador
solo tendrá dos estados representados. Tenemos datos o tenemos un error.
No más estados intermedios. Analicemos los datos en Firestore.
En este fragmento de código vemos el análisis de una versión anterior
del inicio rápido de Firestore. Tras obtener los datos de allí,
queremos convertirlos en un tipo local del diccionario proporcionado,
en este caso, un restaurante. ¿Les resulta familiar este tipo de código?
Cada vez que leo el menú, me deprimo. Se desajusta un error en claves de cadena
y no se aprovechan las características de seguridad de Swift.
Es frágil, difícil de leer y es fácil de cometer errores al escribirlo.
Agreguémosle conformidad de Codable a nuestro tipo de restaurante.
Al confirmar el protocolo Codable,
aprovechamos muchísimo ese análisis de código manual
tal como el compilador lo genera, con actualizaciones estables en todo el tipo.
Ahora, leer datos de Firestore
es tan fácil como llamar a los datos como función
en documentos, instantáneas y análisis en el tipo de restaurante.
No más análisis manual de ese objeto. Codable hace todo el trabajo por nosotros.
Configurar datos en Firestore es igual de fácil.
En vez de una representación de diccionario, se pasa la instancia directamente.
También publicamos una API similar para la BBDD de Firebase
gracias a un colaborador externo.
A continuación, mi favorito: el nuevo y emocionante SwiftUI.
Recientemente publicamos API específicas de SwiftUI, y habrá más.
En WWDC 2020, presentaron un nuevo ciclo de vida de la aplicación SwiftUI
que se comparte entre plataformas.
Antes, les recomendamos que pusieran FirebaseApp.configure
al comienzo de su app, que termina iniciando la llamada en el delegado de la app.
¿A dónde va si no hay delegado de la aplicación?
Simplemente anulamos la función init que se llama al iniciar una aplicación
y llamamos a FirebaseApp.configure allí.
Esto se verifica aun si después deben usar una app de IU delegada para controlar
cosas como notificaciones push.
Lo veremos después en una demostración de Chen.
La primera API nueva que quería mostrarles
registra eventos screen_view manuales
en Google Analytics para Firebase. Su API actual
registra automáticamente vistas y clases de pantalla para el kit de IU,
pero dado que SwiftUI
no tiene un controlador de vistas de IU al que podamos acceder,
eso no funciona cuando se usa SwiftUI.
El año pasado agregamos un evento screen_view manual
para poder controlar cuidadosamente cuándo se registran estos eventos.
Es útil al escribir un kit de IU. Si lo integran en viewDidAppear,
no los molestará.
Veamos qué aspecto tiene en SwiftUI.
Cada vez que aparece una vista
podemos llamar a las API de registro manual con el modificador onAppear.
Esto funciona, pero es muy detallado y puede desordenar el código
y quitar la estructura de tu vista.
Limítense a lo que podemos ofrecer desde el enfoque de la API en Objective-C,
pero en Swift saldrá mejor.
Una gran oportunidad para el modificador de vista personalizado.
Eso es exactamente lo que hicimos.
Podemos marcar una vista
con el modificador analyticsScreen incorporado
para declarar el nombre de la vista, la clase o en este caso, la estructura,
pero ajustado a los nombres de análisis que hay aquí
y a otros parámetros que quieran registrar
cuando esta vista aparezca en pantalla.
Los argumentos predeterminados de Swift
permiten proporcionar solo el nombre
y el resto es opcional. En este caso,
omitimos el argumento de parámetros adicionales.
Esta nueva forma de marcar vistas
y registrar eventos Screen_view nos entusiasma.
Otra mejora de SwiftUI: la creación de vistas propias de InAppMessage.
En este ejemplo, usamos el modificador modalInAppMessage.
El compilador de vistas cierra
y los argumentos son el mensaje que contiene los datos
que se configuraron en la consola,
más el delegado para notificar el SDK de interacciones
de InAppMessaging, como al tocar o descartar un mensaje
para registrar métricas e impresiones.
Hay una API para cada tipo de mensaje. Suministrar interfaces personalizadas
desde sus mensajes integrados nunca fue tan sencillo.
En la discusión de Github, cuéntennos si tienen ideas
para otros asistentes de SwiftUI.
La comunidad está entusiasmada con Combine y tienen toda la razón.
Nosotros también lo estamos. Recibimos contribuciones increíbles
de la gente de la comunidad
y nosotros mismos trabajamos en algunos cambios.
Queda mucho por hacer en este espacio.
Esto es un adelanto de lo que pueden esperar.
Un publicador de inicio de sesión para Auth
con correo electrónico y contraseña.
Devuelve una función de Combine
con resultados de los datos de autenticación o error asociado.
Está un poco simplificado, pero en este proceso
extraemos el usuario, reemplazamos cualquier error con nil
y lo asignamos a la propiedad signedInUser
que se representa en la IU.
Tenemos publicadores en diferentes SDK para ayudar
con su flujo de datos Async.
Pueden ver el progreso en nuestras API de Combine
usando el proyecto de GitHub configurado. Combine no es el único avance
en código de manejo Async. Estamos muy cerca de ver Async/await
en una actualización de la toolchain de Swift.
Veamos el inicio de sesión con correo electrónico y contraseña,
comparando el controlador de finalización con Async/await.
Usamos controladores de finalización para manejar el flujo de control.
Dentro de ese controlador, querríamos hacer más llamadas asincrónicas,
lo que puede provocar la clásica pirámide de la muerte.
¿Cómo transforma Async/await esta llamada?
En lugar de administrar el estado completo en el controlador de finalización,
se parece más a un código síncrono sobre el que es más fácil razonar.
Podemos hacer lo mismo para otras llamadas asincrónicas
y será mucho más simple mantener el estado
y asegurarse del manejo adecuado de los errores.
Ahora volvamos con Chen para una demostración increíble.
- Gracias, Ryan.
Analicemos cómo pueden hacer la app de reloj independiente con Firebase.
Quieren controlar su consumo diario de café en el reloj.
Lo bueno de esta app es que se la puede usar sin sincronizar
desde el teléfono.
En Firebase trabajamos para simplificar el desarrollo de la app,
conectando el reloj directamente al servicio Firebase Cloud.
Tenemos varios productos con soporte comunitario para WatchOS,
para que puedan, por ejemplo, enviar notificaciones push
desde la consola de Firebase directamente a su app de reloj,
sincronizar su consumo de café con nuestra BBDD en tiempo real
sin un teléfono vinculado,
o descargar la imagen desde la nube directamente a su reloj.
Sepan que las apps que configuraron en la consola
deben coincidir una por una con las apps en Apple Store Connect.
Si la app abarca varias plataformas, usen una sola app fibrosa
y el info.plist del servicio de Google de las plataformas donde la app se ejecute.
Háganlo también en extensiones de apps para iOS.
Si una app tiene una app para iOS, una app para Mac y el destino del widget,
importen el info.plist de los servidores de Google
de la app principal a los destinos.
Ahora que lograron configurar su producto de Firebase
e importar los archivos .plist a Xcode, veamos cómo podemos enviar
notificaciones push a su app de reloj.
Aquí usaremos el último ciclo de vida de SwiftUI.
Notarán que no hay delegados de extensión disponibles.
De forma predeterminada, un ciclo de vida de SwiftUI
no incluye ningún delegado de tipo de app o extensión.
Aquí pueden usar el adaptador de delegado WKExtension
para inyectar el delegado a su app y así agregar código
para solicitar permisos de notificaciones push de WatchOS
y manejar cualquier API de SDK de Firebase que requiera un delegado de aplicación.
En este caso, deben configurar un apnsToken para el SDK de mensajería.
Antes, este paso se manejaba automáticamente mediante mensajería
cuando se habilitó el swizzling.
Como el swizzling se ha vuelto más frágil,
ya no recomendamos este enfoque en WatchOS.
En cambio, deben implementar un registro did
para notificaciones remotas desde el delegado de WKExtension,
para configurar manualmente apnsToken como mensajería.
Lo mismo se aplica a la app para iOS si usan un ciclo de vida SwiftUI.
Deben usar el adaptador delegado de la aplicación de IU
para inyectar, desde el kit de IU, su delegado de app.
Luego, pueden implementar código que requiera un delegado de app.
Quiero mostrarles un fragmento de código para descargar una imagen llamativa
directamente a su app de reloj. Usamos el almacenamiento de Firebase.
¿Notaron que se puede ejecutar exactamente el mismo código en su app para iOS?
Sí, el almacenamiento de Firebase
no requiere API de clave de reloj especial, como la mensajería,
así que pueden tener un código casi idéntico en sus apps para WatchOS, iOS, tvOS, macOS.
Ofrecemos compatibilidad con extensiones de apps
porque son útiles para simplificar el acceso
de los usuarios a su app y puedan hacer cosas más divertidas.
Tomen el widget como ejemplo.
Presenten la información de su app con extensiones de widgets
y para los usuarios, será más atractivo hacer clic.
Este fragmento de código permite extraer imágenes
para su extensión de widget usando almacenamiento.
Con eso tendrán una imagen llamativa en su kit de widgets.
Es una excelente manera de mostrar información clave de su app a los usuarios,
en lugar del icono básico, lo que es bastante bueno.
Eso es todo.
Ojalá lo hayan pasado bien creando apps de Apple.
Pasen por nuestro repositorio de GitHub.
Encontrarán mucha información útil allí.
Pruébenlo, sigan los errores e inicien discusiones de GitHub.
Estamos ansiosos por ver qué pueden crear con Firebase.
[Música]