Herramienta Multiplataforma de React Native Kotlin

Bueno, gracias por la agradable introducción. Como dije antes, soy Eric y conmigo está Leon y queremos hablar sobre la combinación de React Native y Kotlin Multiplatform para crear la configuración cross-platform definitiva para desarrollar aplicaciones iOS y Android. Así que primero permíteme presentar un poco a Voice. Voice es la empresa que ha construido reconocimiento de voz para la salud. Tenemos una aplicación donde los trabajadores de la salud pueden hablar libremente en nuestra aplicación. Transcribimos el texto y creamos registros médicos estructurados a partir de la transcripción. Luego somos capaces de usar una integración en la infraestructura existente y la instalación para sincronizar este registro en los sistemas existentes de Registros de Salud Electrónicos. Esto es lo que hacemos, y puedes verlo en el GIF. Y de esta manera ya hemos creado más de un millón de registros médicos y nuestra aplicación está impulsada por un reconocimiento de voz personalizado de última generación que hemos ajustado para el uso en la salud y todos nuestros modelos funcionan en el dispositivo, sin conexión, por lo que una instalación no tiene que tener cobertura Wi-Fi completa para usar nuestra aplicación.

No estaríamos aquí si esto no tuviera nada que ver con React. Nuestra aplicación está construida con React Native, por lo que toda la UI que ves aquí está construida en React Native. Aún utilizamos muchas funcionalidades nativas para hacer algunas tareas pesadas, y hablaremos sobre esto más tarde. ¿Quién aquí en la audiencia ha escrito una aplicación en React Native? Oh, bien. Genial. Entonces, ¿quién escribió un módulo nativo para React Native antes? Sí, todavía algunos. Bien. ¿Quién tiene una gran parte de su base de code en nativo? Vale. ¿Y quién piensa en reescribir partes de su implementación JS en nativo? Vale, interesante. Así que tenemos tres personas en esta sala. Creo que la primera persona es la más representada, es gente que tiene todo o la mayoría de su code escrito en JS. Tienen muy poco code nativo, tal vez solo el código de plantilla que se necesita para React Y el tipo de uso de las bibliotecas de código abierto que ya hicieron el trabajo y envolvieron la funcionalidad nativa en módulos nativos para que estén disponibles en JavaScript. El otro probablemente no tan representado aquí es gente que tiene como su aplicación de pila completa en Android e iOS, completamente personalizada y tienen muy poco código JS code o incluso solo están pensando en introducir React Native para agilizar algunas de sus aplicaciones para ser multiplataforma. Y el tercer grupo de personas tal vez solo mezcla JS y nativo y usa lo que necesitan en el momento y lo que mejor se adapta a sus necesidades.

Entonces, ¿por qué son tan impresionantes los módulos nativos y por qué los necesitamos en React Native es el primero uno es la razón más obvia, queremos acceder a la funcionalidad nativa, no podemos simplemente hacer todo en JavaScript, tienes que tener acceso a cosas más específicas de la plataforma. Y esto es también lo que hacen la mayoría de las bibliotecas de React Native, tienen una implementación de Android para alguna funcionalidad, implementación de iOS, y luego crean un módulo nativo por lo que crean una interfaz común para esta funcionalidad nativa y te proporcionan una interfaz JS para que simplemente la llames y puedas consumir esta biblioteca desde NPM. Pero también hay casos de uso como tener code existente como Android e iOS y por ejemplo tienes un estado que se almacena de forma nativa pero quieres tener una UI que pueda mostrar el estado o actualizar el estado por lo que tienes que crear módulos nativos para hacer la comunicación entre lo que está en nativo y lo que está en JS. Y también tal vez las personas que quieren migrar partes de su cosas de JS a nativo lo hacen por razones de performance o para aprovechar la concurrency que tienes en nativo así que simplemente separar el trabajo del hilo JS. Entonces, ¿por qué tan pocas personas realmente escriben módulos nativos? Probablemente el primero es que React Native tiene un muy buen ecosystem y hay bibliotecas bien mantenidas para la mayoría de las funcionalidades nativas que necesitarías por lo que no hay tanto caso para escribir módulos nativos todo el tiempo porque el soporte de la biblioteca es muy bueno. Pero si necesitas escribir módulos nativos es bastante difícil porque necesitas con la pila de tecnología Android, con la pila de tecnología y la cadena de herramientas de iOS necesitas por ejemplo quieres construir un administrador de Bluetooth tienes que implementarlo en iOS, en Swift, o Objective-C y tienes que implementarlo en Android, Kotlin o Java. Y luego también tienes que crear estos adaptadores, módulos nativos, que mapean estructuras de data y argumentos de nativo a JAS y también necesitas exponer a través del manejo de eventos con un módulo nativo o migrar excepciones o convertir excepciones en rechazos de promesas en tu módulo nativo.

Y tienes tanto código repetitivo para exponer simplemente la funcionalidad que acabas de escribir en nativo. Y también no hay nada inherente acerca de los módulos nativos que mantenga las interfaces sincronizadas por lo que eres totalmente responsable de mantener las interfaces de Android, iOS, y JAS sincronizadas para que todo funcione en conjunto. Y si tienes una base de código existente en iOS y Android, es bastante difícil usar React Native en primer lugar porque tal vez son mantenidos por diferentes equipos o en diferentes repositorios, y es difícil para esos equipos llegar a un acuerdo sobre la interfaz del módulo nativo que luego puede ser usado en un proyecto compartido que tiene componentes de React Native.

Así que estos problemas nos afectan profundamente porque aparte de las bibliotecas que existen que tienen módulos nativos en ellos, también tenemos más de 20 módulos nativos personalizados que hemos escrito para hacer comunicación entre JAS y nativo porque hacemos nuestro procesamiento automático en nativo y necesitamos comunicar datos alrededor de él. Hacemos toda nuestra inferencia de modelos obviamente en nativo gestionando artefactos de modelos, descargando cosas, y haciendo trabajo en segundo plano en general. Por eso necesitamos una solución para esto. Si haces tantos módulos nativos y expones tanta funcionalidad nativa, necesitas tener una mejor manera que hacer todo este código repetitivo y Leon te contará más sobre el status quo y lo que podemos hacer para mejorar.

Así es como se ve la configuración típica de un proyecto de React Native. Tienes en realidad tres subproyectos para Android, iOS, y React, y cada uno de estos proyectos usa su propio lenguaje y su propio ecosistema y sus propias herramientas. Así que si quieres exponer código nativo, tendrías que escribirlo dos veces para cada plataforma nativa, y cuando escribes módulos de React Native, la API para exponerlo es muy de bajo nivel y dependiente de la plataforma. Así que imagina que tienes que escribir 20 módulos de React Native para exponer tu lógica nativa. Debe haber una mejor manera de aprovechar la concurrencia nativa y las mejoras de rendimiento nativas en tu aplicación de React Native.

Así que presentemos Kotlin Multiplatform Mobile. Con Kotlin Multiplatform, puedes ejecutar tu código Kotlin en iOS y Android. A diferencia del código JS con React Native, es capaz de ejecutarse en múltiples plataformas. Pero a diferencia de React Native, Kotlin se compila directamente, de forma nativa, a las especificaciones de la plataforma. Por lo tanto, no tiene tiempo de ejecución intermedio. Y por lo tanto, porque se compila para la plataforma, también te permite usar APIs específicas de la plataforma directamente sin necesidad de bibliotecas adicionales que creen un envoltorio para las APIs nativas específicas de la plataforma.

Para entender mejor cómo se puede usar Kotlin Multiplatform junto con React Native, Eric te mostrará una demostración. Vale, cambiemos a la demostración. Aquí tenemos un archivo Kotlin, y este archivo Kotlin está dentro de un proyecto Kotlin Multiplatform. Así que aquí estamos en la carpeta principal común, y en el proyecto Kotlin Multiplatform, esta es una carpeta especial también llamada conjunto de fuentes, y todo lo que escribimos aquí es independiente de la plataforma. Así que es código cross-platform que se escribe en Kotlin, y como dijo Leon, se compilará de forma nativa a JVM en Android y a nativo para iOS.

Así que lo que tenemos aquí es un administrador de nombres que tiene dos métodos, setName y getName, y setName lanzará una excepción si el nombre no es uno de los válidos, Eric o Leon. Y internamente, utiliza config persistente para establecer esto de una manera persistente en nativo. Así que veamos la configuración persistente, y puedes ver que la configuración persistente es como una especie de interfaz, pero ahí está el identificador expect, y esto significa que esperamos que haya una implementación específica de la plataforma para esta clase en iOS y en Android. Y veamos esto. Así que puedo ir aquí y ver el de Android, y puedes ver que ahora estamos en el conjunto de fuentes principal de Android. Y esto significa que podemos acceder a las APIs específicas de Android. Así que puedo importar desde Android, y si quiero tener un almacén de claves y valores en Android, eso es bastante simple. Solo uso las preferencias compartidas, y puedo importar desde Android, obtener del contexto de las preferencias compartidas para nuestro paquete, y luego implementar nuestros métodos que están definidos por la clase expect.

De manera similar, puedo ir a la implementación de iOS, y aquí es donde se pone interesante, porque ahora estamos en el conjunto de fuentes principal de iOS, y podemos acceder a las APIs específicas de la plataforma de iOS. Y esto es algo notable, porque las importaciones como importar desde la fundación son generalmente importaciones que solo tienes en Objective-C o Swift, pero con Kotlin Multiplatform, puedes simplemente importar y son las preferencias del usuario, y lo que hace, tendrá, finalmente generará una interfaz de inter-operación a esta API nativa. Así que podemos simplemente codificar contra esta API nativa en Kotlin, y Kotlin Multiplatform hará el resto, y enlazará y compilará contra esta plataforma nativa. Así que el almacén de claves y valores en iOS, simplemente usamos NSUserDefaults, e implementamos nuestros métodos. Volvemos a nuestro código común, y ahora podemos entender cómo funciona esto, tenemos código común y cuando necesitamos código específico de la plataforma, definimos una clase expect que tiene implementaciones reales en ambas plataformas, y en el código común, podemos hacer lo que queramos en cross-platform. Y eso es súper genial, podemos mezclar código cross-platform y código específico de la plataforma. Así que ahora tenemos este administrador de nombres cross-platform que es súper genial que escribe en el estado nativo, pero ¿cómo conseguimos esta súper genial clase cross-platform en React Native, donde la necesitamos? Así que lo que hemos construido es que puedes simplemente añadir una anotación, se llama React Native Module, y darle un nombre. Y esto expone automáticamente esta clase de código común a React Native. Y puedes ver que importamos de nuestro toolkit, que se llama react-native-gudwit con una K para Kotlin. Eso es una broma. Y ahora exponemos la clase de código común.

Pero aún no hemos terminado, también necesitamos exponer los métodos que necesitamos. Así que vamos a exportar el método aquí. Y ahora hemos expuesto nuestra clase común completa de Kotlin. Y esto es súper genial. Y ahora cambiemos a JS.

Esta es una aplicación básica, donde puedo establecer el nombre con un campo de entrada, puedo, y un botón, y puedo refrescar para obtener el nombre desde Nativo. Así que, actualmente, esto no funciona en absoluto porque realmente no hace nada cuando digo obtener nombre o establecer nombre. Pero puedes ver que esto funciona porque lo que estamos cargando es su cosa.

Y ahora queremos implementar nuestra clase común que acabamos de exponer. Y podemos hacer esto a través de la configuración del módulo nativo. Así que simplemente decimos que el administrador de nombres es de los módulos nativos modules. Y decimos bien, vamos a hacer la implementación de establecer nombre. Y tenemos una promesa que esperamos establecer nombre desde la entrada. Vale. Recuerdas, cuando introducimos un nombre que no es ErgoLeon, lanzará una excepción. Así que simplemente digamos Adam. Y puedes ver la excepción que se lanzó en el código de Kotlin code ahora se mapea a la promesa de rechazo. Así que establezcamos un nombre que sea válido. Genial.

Pero aún no tenemos ninguna configuración obtenida. Así que exponemos la configuración obtenida así que simplemente establecemos nuestro nombre aquí para esperar el nombre del administrador obtener nombre y ahora podemos refrescar. Y tenemos a Leon. Así que usamos esto, los métodos que acabamos de exponer también deberían funcionar en iOS. Bien. Y cuando digo algo diferente, sí. Vale. Así que, pero ahora siempre tenemos que presionar refrescar para obtener el nombre desde nativo y tal vez podamos hacerlo mejor. Así que volvamos a nuestro código de Kotlin code. Y lo que está oculto aquí debajo es el nombre es flujo. Y esto usa la clase de configuración persistente, que define obtener configuración como flujo.

No tienes que saber demasiado sobre los flujos de Kotlin, pero puedes suscribirte a ellos y luego te notifican cada vez que hay un nuevo valor. Así que intentemos usar esto y hagamos un nuevo método de react native, que es una función de suspensión llamada nombre, que tiene este interesante argumento y dice nombre como flujo para react anterior. Así que ahora exportamos esta interesante función a react native. Y ahora veamos. Acabamos de salir del estado local que tenemos aquí para el nombre y simplemente decimos nombre, usa flujo, name manager.name. Ahora permíteme introducir otro nombre. Y automáticamente cambia a la configuración porque nos suscribimos al flujo nativo. Y esto es lo que puede hacer el kit de herramientas, puedes exportar fácilmente el código común, pero como estamos en código común, podemos agregar utilidades para facilitar otras cosas. Por ejemplo, como exponer directamente los flujos de Kotlin, porque los flujos de Kotlin son increíbles, y por qué no tener utilidades para exportarlos directamente usando nuestro kit de herramientas. Así que hay una dependencia de Kotlin que es el kit de herramientas, y también hay una dependencia de JavaScript para las utilidades que acabamos de usar.

Bueno, esto fue una demostración, volvamos. Resumen rápido, vimos Kotlin multiplatform en acción. Tenemos código code, código específico de la platform, podemos mezclarlos y podemos usar expect actual para crear una especie de interfaz y crear una abstracción en implementaciones específicas de la platform. Y podemos usar el kit de herramientas de React Native para exponer directamente las clases de código común a React Native a través de un módulo nativo, y usar toReact y usar flow y utilidades para hacer nuestra vida más fácil para trabajar con el código Kotlin.

Entonces, ¿qué problemas se resuelven al combinar Kotlin multiplatform con React Native? En primer lugar, se trata de simplificar una implementación nativa a través de KMM. Y también eliminaríamos el código repetitivo usando nuestro kit de herramientas porque no tienes que crear tú mismo en módulos nativos, sino que se generan utilizando la anotación. También, usando Kotlin multiplatform se garantiza que las interfaces para las diferentes plataformas permanezcan sincronizadas. Y lo que también es agradable es que ahora podemos migrar el código nativo a Kotlin multiplatform y luego exponerlo directa y fácilmente a React Native.

Y veamos cómo cambió la estructura del proyecto con esta configuración. Ahora tenemos una única base de código que está en Kotlin para nuestro código nativo. Y en este proyecto hay tres conjuntos de fuentes. Un conjunto de fuentes de código común que debería contener la mayor parte de tu lógica de negocio que estás compartiendo entre todas las plataformas. Y solo pequeñas porciones de tu código son realmente específicas para Android y iOS. Y ahora también podemos ver que los módulos de React Native solo tienen que ser definidos una vez en un código común y no para ambas plataformas. Y creemos que esta es la última configuración de plataforma para el desarrollo móvil porque puedes escribir tu UI con React e implementar tu lógica de negocio de forma nativa con Kotlin Multiplatform. Y entre ellos tienes el kit de herramientas de React Native que te ayuda a moverte entre ellos. ¿Y cómo empezar? Creamos el repositorio de GitHub del kit de herramientas de React Native. Hay una buena guía que te ayuda a configurar y empezar con el kit de herramientas de React Native pero también te ayuda a usar Kotlin Multiplatform con un proyecto de React Native.

Entonces, muchas gracias por escuchar. Por favor, echa un vistazo al repositorio que acabo de mencionar. Es nuevo, como lanzado hace unas dos semanas y déjanos una estrella y también si te parece interesante lo que estamos haciendo como cerrando la brecha React, Kotlin y aprendizaje automático y haciendo algo para los trabajadores de la salud, por favor considera contactarnos. Estamos contratando ingenieros de React y Kotlin. Puedes encontrarnos en voice.de y estaremos encantados de recibir tus preguntas. Realmente buena presentación. Quiero decir, estoy impresionado. No sabía de este paquete. Muchas gracias por crearlo. Parece que es realmente fácil integrar todo, lo cual es, sí, realmente agradable. Pero me gustaría invitarte aquí. Quizás podamos repasar algunas preguntas.

Tenemos algunas preguntas. Eso es agradable. Pero mientras tanto, mientras las reviso, ¿podrías por favor agregar más sobre la nueva architecture y la antigua? ¿Has pensado alguna vez en ello o qué crees que es? ¿Es adecuada para esta biblioteca?

Sí. Acabamos de tener la masterclass sobre la nueva architecture de Nicola y es increíble lo que el equipo de React Native ha hecho. Y estamos tomando un enfoque un poco diferente. Pero hemos hablado con Nicola y con el equipo de React Native para adaptar esta biblioteca para también generar modules que se ajusten más a la nueva architecture. También Nicola dijo que todos los modules que generamos ahora son todavía compatibles hacia atrás incluso en la nueva architecture, pero podemos ir más allá y también generar code desde Kotlin que sea compatible con la nueva architecture. Eso es genial. Sí, muchas gracias. Hay otra. ¿Qué opinas de la nueva API de modules nativos de Xpo? Dejemos esta pregunta para más tarde. ¿Se puede crear un módulo nativo independiente para ser importado en un proyecto de React Native puro? ¿O todo este proyecto necesita ser creado con esto, creo que se refiere a la biblioteca en sí?

Puedo responder a esta pregunta. Así que si generas modules nativos de React Native, puedes importarlos en otros proyectos. Y de hecho estamos haciendo esto con nuestra aplicación. Y tienes que tener en cuenta que al generar varios modules de React Native, no pueden ser auto-enlazados. Así que tienes que enlazarlos manualmente en tu code. Pero eso también es una característica agradable de tener, porque entonces puedes inyectar dependencias en modules de React Native, lo que no sería posible si son auto-enlazados, porque son el constructor. Tienes que llamarlo tú mismo, puedes dar algunos argumentos extra allí.

Muy bien, Ian. Hay otra. ¿Sería posible apoyar también a React Native Web, ya sea con Kotlin a JS o con la compilación de Wasm? Difícil, porque esto es sólo para React Native. No sé si React Native también es compatible con la web.

Sí, también está React Native Web. OK. Pero no lo hemos investigado. Pero probablemente es interesante, porque Kotlin, como dijiste, el multiplatform también puede compilar a JS. Así que tal vez es interesante si se podría hacer algo allí para interop con cosas más específicas del navegador, y escribir modules nativos para cosas específicas del navegador.

Sí, también hay otra pregunta en relación a esta compilación a JavaScript para las UIs de React Native en general. Así que, sí, creo que esa pregunta también fue abordada.

¿Y cómo funciona este kit de herramientas con la construcción de animaciones nativas? Creo que esta es una pregunta un poco vaga de una forma u otra, pero tal vez aprovechando como módulos nativos que tienen animaciones preconstruidas, creo. Sí, creo que lo que imagino es que tienes quizás algún flujo que hace una animación. Pero tienes que recordar que todavía estamos pasando por el puente, y todavía tendrás una actualización de renderizado si recibes algo de useflow. Así que hacer como animaciones super pesadas sobre este useflow todavía no es realmente, no lo hace realmente. Deberías seguir usando un poco diferente de react, reanimado. Así que no tienes estos, estos problemas. Así que es más básicamente, como un caso de uso de fuego y olvido, no para obtener ninguna información del lado nativo. Es para ambos lados, pero no deberías confiar en él para hacer como información de fuego rápido desde nativo. Es sólo para la lógica de negocio, actualizaciones de estado normales, todas las cosas que normalmente escribirías como con un Kotlin.

Tengo curiosidad por ver si hay alguna biblioteca de código abierto construida con el kit de herramientas de React Native ya. Actualmente no, porque como dijimos, es fresco de la prensa y lo lanzamos hace dos semanas. ¿Y tienen planes de abrir el código de algunos de esos 20 diferentes módulos nativos, excepto la lógica de negocio por supuesto y darlo al público? La cosa acerca de estos 20 módulos nativos, están muy estrechamente vinculados a nuestra lógica de negocio de la aplicación dentro de nuestra aplicación. Así que por eso hemos construido estos módulos personalizados porque están exponiendo, especialmente esta lógica que tenemos en nuestro código y no podemos usar alguna biblioteca pública de la estantería porque no se integran tan bien con nuestra propia lógica de negocio que ya tenemos en el código nativo de Kotlin. Esto es también de lo que Leon habló sobre la inyección de dependencia es un tema super importante. La mayoría de las naturalezas que tenemos tienen inyecciones de dependencia de dependencias que están super adaptadas a nuestra aplicación, nuestro gestor de modelos, nuestro procesamiento e inferencias y cosas así.

Alguien está enviando saludos desde la oficina. Estoy totalmente de acuerdo, fue como una presentación que me voló la mente, definitivamente le daré una oportunidad. Hay otra pregunta, ¿qué piensas sobre los nuevos módulos nativos de Expo y cuál crees que podría ser la diferencia? ¿Te refieres a React Native? Módulos Nativos de Expo. No estamos familiarizados con Expo en absoluto. Ok, eso tiene sentido. Es bueno vivir en tu propio mundo de una forma u otra para llegar a diferentes soluciones y no ser influenciado por otros. Creo que esto es lo que has presentado hoy. Es algo nuevo, algo fresco desde mi opinión. Porque he estado en este ecosistema de React Native por un tiempo. Nunca he visto nada como esto. Estoy realmente feliz de estar aquí en la primera fila para verlo realmente en acción. Me gustaría decir felicitaciones una vez más y sí, fue una charla increíble. Muchas gracias por dar esta presentación y estamos esperando ver a dónde va a ir este paquete. Gracias, gracias. Muy bien.