Es más fácil que nunca usar JavaScript para construir aplicaciones móviles nativas. Pero para los desarrolladores web que construyen en el ecosistema móvil por primera vez, desplegar aplicaciones multiplataforma construidas con herramientas como Capacitor o React Native puede ser complejo. Aprenda sobre las consideraciones específicas de implementación móvil a través de la perspectiva de un desarrollador web, incluyendo las diferencias clave entre móvil y web, cómo desarrollar una estrategia de implementación y cómo evaluar las opciones de herramientas.
This talk has been presented at JSNation 2023, check out the latest edition of this JavaScript Conference.
FAQ
Los desarrolladores web deberían interesarse en las implementaciones móviles debido al creciente uso de dispositivos móviles para acceder a aplicaciones y servicios. Esto implica la necesidad de adaptar y optimizar aplicaciones web para plataformas móviles, así como considerar el desarrollo de aplicaciones nativas.
Herramientas como Capacitor de Ionic, Native Script y otras que permiten agregar funcionalidad nativa a contenido web, son útiles para convertir aplicaciones web en móviles.
Las pruebas móviles requieren compilaciones binarias nativas y pruebas en dispositivos físicos o virtuales, mientras que las pruebas web generalmente se realizan en navegadores y pueden incluir pruebas unitarias, de integración y de extremo a extremo en un entorno de desarrollo o staging.
AppFlow es una plataforma de CI/CD móvil desarrollada por Ionic que facilita la implementación y gestión de aplicaciones móviles, permitiendo automatizar procesos como la compilación, prueba y despliegue de aplicaciones.
La firma de código es crucial en las aplicaciones móviles porque valida la identidad del desarrollador y asegura que el binario de la aplicación no ha sido modificado tras su firma, lo cual es vital para la seguridad y la distribución en tiendas de aplicaciones.
Google Play permite lanzar aplicaciones a través de diferentes pistas de prueba como la interna, alfa y beta, mientras que Apple utiliza lanzamientos ad hoc y TestFlight para pruebas antes de la aprobación final en la App Store, donde se requieren perfiles de aprovisionamiento y certificados específicos.
El mantenimiento de aplicaciones móviles es más complejo debido a la diversidad de versiones y la necesidad de cumplir con requisitos de seguridad y SDK de las tiendas de aplicaciones, lo que puede complicar las actualizaciones y el manejo de errores en comparación con las aplicaciones web que pueden actualizarse más fácilmente y en tiempo real.
Las implementaciones móviles son cruciales para los desarrolladores web debido al creciente número de usuarios en dispositivos móviles. El desarrollo multiplataforma y las migraciones de web a móvil están en aumento con herramientas como React Native, Ionic, Capacitor y Native Script. Las pruebas móviles requieren compilación binaria nativa y pruebas en dispositivos reales. Google Play y iOS tienen métodos específicos para lanzar aplicaciones a probadores, mientras que el desarrollo web permite actualizaciones dinámicas y despliegue rápido. La construcción y despliegue de aplicaciones móviles requieren una infraestructura específica y procesos de firma de código. Las pautas de aprobación de las tiendas de aplicaciones y las actualizaciones de versiones plantean desafíos en la implementación de aplicaciones móviles.
Bienvenido a las implementaciones móviles para desarrolladores web. Como desarrollador web, es importante comprender la importancia de las implementaciones móviles. Los usuarios cada vez utilizan más dispositivos móviles, por lo que es crucial construir para la plataforma móvil. El desarrollo multiplataforma y las migraciones de web a móvil están en aumento, con herramientas como React Native, Ionic, Capacitor y Native Script. La plataforma móvil difiere de la web en términos de hardware y compilación de un binario nativo. La plataforma establece las reglas en las implementaciones móviles.
Hola, bienvenido. Esto es Implementaciones Móviles para Desarrolladores Web. Soy Cecilia Martinez. Soy una defensora del desarrollo para aplicaciones móviles en AppFlow, la plataforma de CI/CD móvil desarrollada por Ionic. No dudes en conectarte conmigo. Estoy en Cecilia Creates en Twitter y GitHub, o también puedes conectarte conmigo en LinkedIn. Búscame por mi nombre, es n slash Cecilia Martinez. Estoy encantada de hablar contigo sobre las implementaciones móviles si tienes alguna pregunta.
La primera pregunta que puedes tener es por qué, como desarrollador web, deberías preocuparte por las implementaciones móviles. Bueno, cada vez más vemos que los usuarios utilizan dispositivos móviles. Esto significa que, como desarrollador web, estás construyendo para la plataforma móvil en términos de una aplicación web móvil o, en algunos casos, aplicaciones nativas reales también. Estamos viendo un aumento en el desarrollo multiplataforma, lo que significa construir desde una única base de código para la web móvil, iOS y Android utilizando herramientas como React Native o Ionic. Y también estamos viendo un aumento en las migraciones de web a móvil. Esto significa utilizar contenido web existente o construir una aplicación web y luego convertirla en una aplicación móvil. Puedes hacer esto con herramientas como Capacitor, que también es desarrollada por Ionic, Native Script o cualquier cosa donde básicamente agregas funcionalidad nativa y luego construyes para la plataforma Android o iOS. También puedes hacer esto utilizando lo que llamamos micro frontends móviles, donde estás incrustando contenido web en una aplicación móvil nativa. Por lo tanto, es posible que llegues a un punto en el que te pidan crear contenido web para una aplicación móvil y también necesites comprender cómo implementarlo. Por lo tanto, comprender lo que hace que el móvil sea diferente es realmente importante cuando se trata de tomar una aplicación web y convertirla en una aplicación móvil. En última instancia, lo que hace que el móvil sea diferente es la plataforma para la que estás construyendo. Cuando construyes una aplicación web, estás construyendo para software o estás construyendo para un navegador. Tu aplicación web interactuará en última instancia con otra pieza de software y se ejecutará en ese navegador. Para una aplicación móvil, estás construyendo para hardware. Estás construyendo para un dispositivo nativo real. Y debido a eso, estás compilando un binario nativo que luego se ejecutará en ese dispositivo en un momento posterior una vez que se haya instalado. Esto es diferente a una aplicación web donde tenemos código interpretado que es realmente dinámico y que se ejecuta en el navegador en tiempo de ejecución. Estas son las diferencias que ocurren entre la web y el móvil que deben tenerse en cuenta. Pero en general, la gran diferencia es que con el móvil, la plataforma establece las reglas. Con una aplicación web, tienes control total sobre cuándo implementas tu aplicación, qué herramientas utilizas para construirla, qué dependencias utilizas. Con el móvil, eso no es así. Ya sea que estés construyendo para iOS, Android o ambos, esas plataformas van a dictar
2. Pruebas de implementación web y móvil
Short description:
Vamos a explorar las diferencias entre las implementaciones web y móviles. Las pruebas web generalmente se realizan en un entorno de desarrollo, pruebas o puesta en escena, con pruebas automatizadas para la integración continua. Las pruebas móviles requieren compilación binaria nativa y pruebas en dispositivos reales. Se pueden utilizar dispositivos virtuales para implementaciones rápidas, pero es necesario realizar pruebas en dispositivos reales. Puedes conectar un dispositivo real a tu máquina de desarrollo o utilizar una granja de dispositivos reales para pruebas automatizadas. También están disponibles los canales de prueba.
gran parte del proceso de implementación. Así que echemos un vistazo a ese proceso de implementación y las diferentes etapas y cómo las implementaciones web y móviles son diferentes en cada etapa. Comenzaremos con pruebas. Cuando pensamos en las pruebas para las aplicaciones web, por lo general, estamos probando en un entorno de desarrollo, pruebas o puesta en escena. También se pueden realizar pruebas en producción, pero nos centraremos en las pruebas previas a la producción por ahora. Cuando realizas pruebas en un entorno de desarrollo, pruebas o puesta en escena, puedes probar tu código real utilizando pruebas unitarias, pruebas de integración o pruebas de API. También puedes realizar pruebas de extremo a extremo donde lanzas tu aplicación en un navegador, generalmente de forma invisible, y ejecutas tus pruebas automatizadas. Idealmente, se realizarán pocas pruebas manuales para tu aplicación web. Idealmente, tienes muchas pruebas automatizadas lo que permite una integración continua automatizada. Esto significa que si realizas un cambio en tu código, todas tus pruebas se ejecutan automáticamente y si todo parece correcto, puedes integrar ese cambio en tu código sin necesidad de realizar muchas pruebas manuales. Es muy diferente en el lado móvil. Esto se debe a que necesitas tener una compilación binaria nativa para las pruebas de extremo a extremo. También necesitas poder probarlo en un dispositivo. No puedes simplemente lanzarlo en un navegador y hacerlo en tu entorno de pruebas. Esto significa que debes aprovechar tanto los dispositivos virtuales como los dispositivos reales para las pruebas. Y también se requiere un mayor número de pruebas manuales. Existen marcos de pruebas automatizadas para probar tanto en dispositivos virtuales como en dispositivos reales, pero lo que generalmente veremos es que habrá múltiples rondas de versiones de prueba y se utilizarán probadores manuales y seguimientos de pruebas para probar completamente tu aplicación antes de que se lance a los usuarios. Mencioné que hay varias opciones de dispositivos para las pruebas, por lo que tienes dispositivos virtuales. Estos serán emuladores para Android o simuladores para iOS. Hay algunas pequeñas diferencias técnicas entre los dos, pero en última instancia, lo que hacen es replicar un dispositivo real, pero se ejecuta en tu computadora. Es un dispositivo virtual. Estos pueden ser útiles para ver implementaciones rápidas de tu aplicación o mostrarla a las partes interesadas o realizar algunas pruebas de depuración, pero no replican completamente la experiencia de un dispositivo real. Por eso, generalmente debes realizar pruebas en dispositivos reales en algún momento. Puedes conectar un dispositivo real a tu máquina de desarrollo, conectar tu iPhone o tu dispositivo Android y ejecutar la aplicación que estás construyendo. También puedes instalar manualmente el binario en tu dispositivo. AppFlow, por ejemplo, tiene un código QR de Android donde después de compilar tu aplicación de Android puedes escanear el código QR y se instalará y abrirá en tu dispositivo de pruebas de Android. También puedes cargar el binario en lo que se llama una granja de dispositivos reales. Esto se puede hacer con pruebas automatizadas, por lo que cargas tu compilación de la aplicación que acabas de crear y puedes ejecutar pruebas automatizadas en dispositivos reales en la nube. Algunos de estos incluyen AWS Device Farm, Sauce Labs, hay bastantes opciones. Pero te permiten realizar algunas pruebas en dispositivos reales sin tener que aprovisionar esos dispositivos reales tú mismo.
3. Canales de Prueba y Proceso de Construcción Web
Short description:
Tanto Google Play como iOS tienen métodos específicos para lanzar aplicaciones a probadores. Google Play tiene pistas de prueba internas, alfa y beta, mientras que iOS tiene lanzamientos ad hoc y Apple TestFlight. TestFlight te permite invitar hasta 10,000 probadores y proporciona herramientas integradas para recopilar comentarios. Al construir para la web, no es necesario realizar una compilación real, ya que el desarrollo web moderno permite actualizaciones dinámicas y una implementación rápida.
También existen canales de prueba. Entonces, cuando mencioné anteriormente que la plataforma establece las reglas, eso es de lo que estamos hablando en este ejemplo cuando hablamos de canales de prueba. Tanto Google Play como iOS tienen métodos específicos para lanzar tus aplicaciones a probadores.
En el lado de Google Play, tienes tres pistas de prueba. Tienes la interna, que se utiliza para implementaciones rápidas de hasta 100 usuarios. Puedes implementar aplicaciones que aún no se hayan configurado completamente en pistas de prueba internas. Es bueno para tus probadores de control de calidad, partes interesadas, cualquier cosa que sea interna para tu organización. Debes autorizar a todos en esta lista manualmente con una dirección de correo electrónico. Por lo tanto, no se debe utilizar para lanzar tu aplicación de manera más amplia.
Luego tienes la pista de prueba alfa, que también se llama pista de prueba cerrada. Esto permite implementaciones en una lista más amplia de probadores autorizados. Entonces, si necesitas más de los 100 para la interna, entonces deberás pasar a la pista de prueba beta, que también se llama pista de prueba abierta. Cuando estás en beta, cualquier persona puede instalar y probar tu aplicación. Por lo tanto, debe estar lista para aparecer en la tienda de Google Play y lista para ser visible. Esta es realmente la última etapa de las pruebas antes de lanzar tu aplicación por completo.
En el lado de iOS, tienes lo que se llaman lanzamientos ad hoc. Los lanzamientos ad hoc se pueden utilizar para implementar aplicaciones en hasta 100 dispositivos al año. Entonces, Google Play se basa en usuarios. Apple ad hoc se basa en dispositivos. Cada dispositivo de prueba debe agregarse manualmente a tu perfil de aprovisionamiento y tú construyes tu aplicación. Por lo tanto, nuevamente, es útil para las pruebas internas, tus pruebas de control de calidad, solo tus partes interesadas. Si necesitas implementar en más dispositivos de prueba, o si estás listo para compartirlo de manera más amplia, entonces está Apple TestFlight. Apple TestFlight es un programa proporcionado por la App Store de Apple que te permite invitar hasta 10,000 probadores utilizando direcciones de correo electrónico o también puedes compartir un enlace público. Lo bueno de TestFlight es que tiene herramientas integradas para recopilar comentarios, como informes de errores, envío de capturas de pantalla, cosas que facilitan la obtención de comentarios de tus probadores mientras está en el programa. Debes tener una compilación de la tienda de aplicaciones para implementar en TestFlight, por lo que tu aplicación debe estar configurada y lista para eso.
Hablando de compilaciones de la tienda de aplicaciones, hablemos del proceso de compilación a continuación. Cuando estás construyendo para la web, técnicamente no necesitas una compilación real. Esto es un requisito del desarrollo web moderno, donde estamos utilizando cosas como frameworks y transpiladores en paquetes para optimizar o minimizar HTML, CSS, JavaScript y nuestros activos estáticos para la web. Es muy fácil realizar actualizaciones de forma dinámica en la web. Las compilaciones web no deberían llevar mucho tiempo. Podemos implementar actualizaciones muy rápidamente cuando hablamos de construir nuestras aplicaciones web.
4. Mobile App Building and Deployment
Short description:
En el lado móvil, estás creando un binario ejecutable para tu plataforma nativa. Necesitas requisitos de infraestructura específicos, como hardware Mac para compilaciones de iOS y versiones específicas de Xcode y Android SDK. Los tipos de compilación y la versión son importantes, y el proceso de firma de código garantiza la integridad de la aplicación. Android tiene tipos de compilación de depuración y lanzamiento, mientras que iOS tiene simulador, desarrollo, ad hoc, App Store y empresa. Se necesitan credenciales como la clave de carga y la clave de firma de la aplicación para la firma de aplicaciones de Android. Para iOS, hay certificados de firma y perfiles de aprovisionamiento. Una vez que la aplicación se ha construido y firmado, está lista para su implementación. La implementación web implica colocar los archivos en el servidor.
En el lado móvil, como mencioné anteriormente, estás creando un binario ejecutable para tu plataforma nativa. Esto también significa que debes tener requisitos de infraestructura muy específicos en el entorno en el que vas a construir. Ya sea que lo hagas localmente, manualmente en tu computadora Mac, o en un entorno de CI/CD, necesitarás hardware Mac para las compilaciones de iOS. También necesitarás tener instaladas versiones específicas de Xcode y Android SDK en tu entorno para poder construir tu aplicación móvil.
Hay tipos de compilación muy específicos entre los que debes seleccionar, y debes asegurarte de versionar cada compilación correctamente, porque se requieren diferentes versiones a medida que actualizas tu aplicación. Y querrás poder hacer un seguimiento de qué versión de la aplicación estás construyendo y cómo se relaciona con la versión de tu base de código. La mayor diferencia, sin embargo, cuando se trata de construir tu aplicación móvil, será el proceso de firma de código. Mencioné los tipos de compilación. Para Android, hay tipos de compilación de depuración y lanzamiento. Para iOS, hay simulador, desarrollo, ad hoc, App Store y empresa. En última instancia, necesitarás una compilación de la App Store para poder lanzarla en TestFlight o en la App Store. En Android, necesitarás una compilación de lanzamiento si quieres lanzarla en las pistas de prueba beta o producción, y luego también lanzarla. De lo contrario, los otros tipos de compilación son útiles para varios tipos de pruebas y desarrollo.
Mencioné la firma de código. Lo que hace es validar la identidad del firmante, así como en qué dispositivos puede ejecutarse, y desde una perspectiva de seguridad, garantiza que el binario de la aplicación no se haya modificado desde el momento en que se firmó. La firma de tu aplicación de Android implica dos credenciales. Tienes una clave de carga que se genera localmente en tu máquina, y lo que hace es utilizarse durante el proceso de compilación para generar lo que se llama un paquete firmado. Este es un archivo .keystore o .jks. También hay una clave de firma de la aplicación, y esta suele generarse por Google y se utiliza para firmar tu aplicación después de haberla subido a la tienda de aplicaciones, pero antes de que se entregue a los usuarios. No necesitas esto en tu entorno de compilación, por lo que no es necesario si estás utilizando un pipeline de CI/CD para tu compilación. Esto es algo que ocurre dentro del proceso de Google Play. Lo menciono porque se llama clave de firma de la aplicación, por lo que algunas personas piensan que necesitas tenerla durante el proceso de compilación. Para iOS, tienes dos credenciales, un certificado de firma, que valida la identidad de quien generó esa compilación autorizada, y también un perfil de aprovisionamiento que indica en qué dispositivos puede ejecutarse un paquete firmado. Si estás haciendo una compilación para la App Store y tienes lo que se llama un perfil de aprovisionamiento de distribución, lo que significa que la aplicación puede ejecutarse en cualquier dispositivo, pero como mencioné, para esas compilaciones ad hoc, debes especificar en qué dispositivos puede ejecutarse, y es entonces cuando necesitarás tener un perfil de aprovisionamiento específico que enumere todos esos dispositivos. Todas estas credenciales, en realidad todas estas credenciales, deben estar en tu entorno cuando vayas a construir tu aplicación.
Una vez que tu aplicación se ha construido y firmado, está lista para su implementación. Cuando hablamos de implementación, hablamos del proceso de llevar realmente la aplicación a los usuarios, ¿verdad? Para la web, lo único que tienes que hacer es colocar los archivos en el servidor. Eso es todo. Recuerdo que solía usar FTPZilla en el pasado y simplemente arrastraba la nueva carpeta de archivos de compilación y la reemplazaba por la anterior, y una vez que eso se completaba, todos tus usuarios
5. Desafíos en la Implementación de Aplicaciones Móviles
Short description:
Tienes control sobre cuándo se implementa tu aplicación. La plataforma establece las reglas. Debes enviar tu aplicación para su aprobación en la tienda de aplicaciones antes de que pueda ser implementada para los usuarios. Es importante comprender las pautas de aprobación de la tienda y qué puede causar el rechazo de tu aplicación. No puedes tener fallas o errores en tu aplicación, ni enlaces rotos ni información de marcador de posición. Tampoco puedes tener una interfaz de usuario deficiente. Tu aplicación puede ser rechazada por no tener suficiente valor duradero. Al mantener aplicaciones web, tenemos control sobre nuestras propias implementaciones y todos los usuarios tienen la misma versión de la aplicación al mismo tiempo. Con las aplicaciones web, puedes elegir qué dependencias necesitas y cuándo actualizarlas. No es fácil corregir errores o actualizar la aplicación en dispositivos móviles debido a la larga lista de versiones de aplicaciones que se deben admitir.
Tienes control sobre cuándo se implementa tu aplicación. La plataforma establece las reglas. Debes enviar tu aplicación para su aprobación en la tienda antes de que pueda ser implementada para los usuarios. Hay algunas formas de hacer que las aplicaciones lleguen a los usuarios, evitando las tiendas de aplicaciones, pero es muy, muy raro y, sinceramente, la mayoría de los usuarios no instalarán una aplicación que no provenga de la tienda, y con razón. Las tiendas de aplicaciones establecen políticas específicas de privacidad y seguridad para garantizar la calidad de las aplicaciones, por lo que también debes crear una lista en la tienda. Necesitarás tener todos los detalles y activos en esa lista, como el ícono de la aplicación, capturas de pantalla y vistas previas, y también deberás establecer tus acuerdos de privacidad y datos. Cuando usas una aplicación móvil y esta solicita acceso a tus fotos o ubicación, estas son solicitudes de acceso a datos que deben especificarse en la lista de la tienda, al igual que el código de tu aplicación y los permisos que necesitas, y esto puede hacer que tu aplicación sea rechazada si no se configuran correctamente. El proceso de aprobación puede llevar hasta una semana o más. No te dan un número específico y, si te rechazan, debes pasar por un proceso de reenvío que puede llevar aún más tiempo. Debido a esto, no tienes tanto control sobre el proceso de implementación y estás a merced de las tiendas de aplicaciones. Por eso es muy importante comprender las pautas de aprobación de la tienda y qué puede causar el rechazo de tu aplicación. Estas son las razones proporcionadas por Apple, las razones más comunes por las que se rechazan las aplicaciones. Incluyen cosas como no poder tener fallas o errores en tu aplicación, ni enlaces rotos ni información de marcador de posición. Mencioné específicamente el problema de la política de privacidad y las solicitudes de acceso a datos poco claras, eso definitivamente es un gran problema. Tampoco puedes tener una interfaz de usuario deficiente. La documentación de Apple proporciona algunos ejemplos de capturas de pantalla de lo que consideran una interfaz de usuario deficiente. Esto me hace reír un poco porque si no permitiéramos interfaces de usuario deficientes en las aplicaciones web, muchas de ellas no estarían en producción. El contenido web estático, esto no significa que no puedas usar contenido web en tu aplicación nativa, solo significa que la aplicación nativa debe tener una razón para ser nativa. Si tomas un blog existente, por ejemplo, y lo conviertes en una aplicación móvil nativa sin hacer cambios, eso es algo que podría ser rechazado porque no necesita existir como una aplicación. Además, tu aplicación puede ser rechazada por no tener suficiente valor duradero. Por eso es importante comprender cuáles son estos posibles obstáculos para que puedas implementar rápidamente. Esto se debe a que necesitarás poder mantener tu aplicación a medida que avanza, ¿verdad? Cuando hablamos de mantener aplicaciones web, como mencioné antes, tenemos control sobre nuestras propias implementaciones y todos los usuarios tienen la misma versión de la aplicación al mismo tiempo. A excepción de las banderas de funciones o las pruebas A-B, una vez que el usuario accede al servidor, obtiene la misma versión de tu aplicación. Con las aplicaciones web, es posible que debas mantener algunas dependencias. Pero en última instancia, puedes elegir qué dependencias necesitas y cuándo actualizarlas. Por lo tanto, tienes un control total sobre tus lanzamientos. Y puedes corregir errores críticos o actualizar cuando sea necesario. No es fácil corregir errores en dispositivos móviles. Tampoco es fácil actualizar y mantener tu aplicación en dispositivos móviles. Esto se debe a la larga lista de versiones de aplicaciones que se deben admitir.
6. Versionado y Actualizaciones de Aplicaciones Móviles
Short description:
En móvil, no todos tienen la misma versión de la aplicación. Se deben seguir los requisitos y actualizaciones de la tienda de aplicaciones para evitar ser eliminado. Las correcciones de errores para aplicaciones multiplataforma se pueden hacer a través de implementaciones por aire, actualizando el contenido web sin una nueva versión de la tienda de aplicaciones.
En Web, todos tienen la misma versión de tu aplicación, pero en móvil, eso no es así, ¿verdad? Puede que tengas tu aplicación configurada para actualizarse automáticamente en la tienda de aplicaciones, o puede que tengas una versión muy antigua de una aplicación en tu teléfono porque nunca la has actualizado manualmente. Si realizas cambios en tu API, tal vez agregues nuevas características, debes asegurarte de que tu aplicación siga funcionando incluso en las versiones más antiguas que están en uso. También debes cumplir con los requisitos de la tienda de aplicaciones. Tanto iOS como Android actualizan sus requisitos de seguridad y el SDK mínimo necesario para construir tu aplicación. Si no cumples con estos requisitos, puedes ser eliminado de la tienda de aplicaciones. También debes pensar en cuál será tu estrategia de actualización, ya que las correcciones de errores y las actualizaciones son difíciles de implementar. Si estás construyendo una aplicación multiplataforma o una aplicación que utiliza contenido web, una opción para las correcciones de errores es utilizar implementaciones en vivo, o lo que llamamos implementaciones por aire. Esto te permite actualizar el contenido web de tu aplicación sin lanzar una nueva versión de la tienda de aplicaciones. No puedes utilizar esto para cambios nativos y tu aplicación debe estar preconfigurada. Pero existen diversas herramientas disponibles que te permiten enviar nuevos cambios a ese contenido web y evitar una nueva versión nativa. Tenlo en cuenta como una posible estrategia de actualización. Hay beneficios al automatizar este proceso, ¿verdad? Automatizar el proceso de implementación. Y serán similares a los beneficios de la automatización en la web. Tienes una reducción de los silos de conocimiento y varias personas en el equipo pueden implementar. También puedes gestionar las credenciales compartidas, por lo que no necesitas generar individualmente los certificados de inicio de sesión y los perfiles de aprovisionamiento. Obviamente, tienes una mayor velocidad de lanzamiento si puedes automatizar algunos de estos pasos y poner tu aplicación en manos de los probadores más rápidamente. También tienes una mejor visibilidad del proceso de implementación. Puedes ver quién generó una compilación, a qué confirmación de código correspondió, qué versión corresponde en la tienda de aplicaciones tanto para iOS como para Android, todo en un mismo lugar. Tienes algunas opciones de herramientas cuando se trata de automatizar tus compilaciones. Algunas de ellas serán específicas de la plataforma, es decir, solo para iOS o Android. Algunas de ellas serán específicas del marco de trabajo, es decir, solo para React Native o solo para Capacitor. O algunas de ellas serán generales, en el sentido de que se pueden utilizar para varias plataformas y varios marcos de trabajo. También hay herramientas para integrarse con tu plataforma CICD existente, o utilizar algo específico para móvil, pero dedicado a tus implementaciones móviles. Cuando hablamos de herramientas CICD, hay algunas que tienen una sola función, es decir, solo realizan la compilación, solo la distribución, solo la configuración, pero lo más probable es que veas herramientas multifunción. Estas son cosas como Fastlane, que es desarrollado por Google, que te permite gestionar la versión, la compilación, la carga y la publicación de diferentes fases de tus implementaciones CICD. También hay interfaces de línea de comandos y APIs de servicios en la nube, como AppFlow, CodeMagic, Bitrise y AppCircle, que ofrecen múltiples funcionalidades relacionadas con las implementaciones móviles. Si no tienes una plataforma CICD existente o no quieres utilizarla para móvil, también puedes obtener una plataforma CICD específica para móvil. Por lo general, estas tienen una interfaz gráfica de usuario que te permite crear flujos de trabajo y gestionar tus certificados de inicio de sesión y tus entornos en un entorno en la nube. Nuevamente, estas pueden ser específicas de la plataforma, como Xcode Cloud, específicas del marco de trabajo, como EIS para aplicaciones Expo de React Native, o de múltiple soporte, como AppFlow y Bitrise. Al decidir qué tipo de herramientas utilizar, debes tener en cuenta la experiencia en DevOps de tu equipo. También debes pensar en la infraestructura existente que tienes. Por ejemplo, si ya tienes un equipo de DevOps dedicado con una infraestructura CICD tradicional sólida, entonces es posible que desees utilizar herramientas de manera fragmentada para integrar la funcionalidad móvil. Sin embargo, si no tienes un equipo de DevOps dedicado y alguien del equipo móvil será responsable de sus propias implementaciones, y no tienes esa infraestructura existente, es posible que desees utilizar algo que sea un servicio completo, una herramienta multifunción. También debes pensar en las plataformas que admites y los marcos de trabajo que utilizas para construir, y debes pensar en cómo protegerlos en el futuro. Ahora mismo, es posible que solo estés construyendo para una plataforma, por lo que una solución para una sola plataforma puede ser una buena opción, pero ¿tienes planes de expandirte en el futuro? Debes tener en cuenta todas estas cosas al decidir qué herramientas quieres utilizar para tus implementaciones móviles. Y si deseas obtener más información, tenemos un libro electrónico gratuito llamado Solving Mobile CICD with AppFlow, puedes escanear el código QR o visitar el enlace para recibirlo y obtener más información sobre CICD e implementaciones móviles en general. O siempre puedes comunicarte conmigo si tienes alguna pregunta. Nuevamente, me encuentro en ceciliacreates en Twitter, en GitHub. O también puedes enviarnos un correo electrónico a appflow.io. Muchas gracias.
This Talk discusses Rack Native at Microsoft and the efforts to improve code integration, developer experience, and leadership goals. The goal is to extend Rack Native to any app, utilize web code, and increase developer velocity. Implementing web APIs for React Native is being explored, as well as collaboration with Meta. The ultimate aim is to make web code into universal code and enable developers to write code once and have it work on all platforms.
React Server Components (RSC) offer a more accessible approach within the React model, addressing challenges like big initial bundle size and unnecessary data over the network. RSC can benefit React Native development by adding a new server layer and enabling faster requests. They also allow for faster publishing of changes in mobile apps and can be integrated into federated super apps. However, implementing RSC in mobile apps requires careful consideration of offline-first apps, caching, and Apple's review process.
The Talk discusses the combination of React Native and Kotlin Multiplatform for cross-platform app development. Challenges with native modules in React Native are addressed, and the potential improvements of using Kotlin Multiplatform Mobile are explored. The integration of Kotlin Multiplatform with React Native streamlines native implementation and eliminates boilerplate code. Questions about architecture and compatibility, as well as the possibility of supporting React Native Web, are discussed. The React Native toolkit works with native animations and has potential for open-source development.
This Talk discusses building cross-platform component libraries for React and React Native, based on a successful project with a large government-owned news organization. It covers the requirements for React Native knowledge, building cross-platform components, platform-specific components, styling, and the tools used. The Talk also highlights the challenges of implementing responsive design in React Native.
This Talk is about the development of MDX, a combination of Markdown and JSX, by a freelance full stack JavaScript developer. MDX is a powerful technology that allows for the creation of interactive content within blog posts and supports React components. The speaker developed RnMDX, a proper and polished MDX library for React Native, which can be dropped into any React Native app. RnMDX provides solutions for common issues with Markdown content in React Native and allows for the rendering of MDX content into native views. Bringing MDX into native apps is now easier, and it can be used for various purposes, such as serving the app layout from a CMS or creating interactive online magazines or blogs.
Presentando FlashList: Construyamos juntos una lista performante en React Native
Top Content
WorkshopFree
3 authors
En esta masterclass aprenderás por qué creamos FlashList en Shopify y cómo puedes usarlo en tu código hoy. Te mostraremos cómo tomar una lista que no es performante en FlatList y hacerla performante usando FlashList con mínimo esfuerzo. Usaremos herramientas como Flipper, nuestro propio código de benchmarking, y te enseñaremos cómo la API de FlashList puede cubrir casos de uso más complejos y aún así mantener un rendimiento de primera categoría.Sabrás:- Breve presentación sobre qué es FlashList, por qué lo construimos, etc.- Migrando de FlatList a FlashList- Enseñando cómo escribir una lista performante- Utilizando las herramientas proporcionadas por la biblioteca FlashList (principalmente el hook useBenchmark)- Usando los plugins de Flipper (gráfico de llamas, nuestro perfilador de listas, perfilador de UI & JS FPS, etc.)- Optimizando el rendimiento de FlashList utilizando props más avanzados como `getType`- 5-6 tareas de muestra donde descubriremos y solucionaremos problemas juntos- Preguntas y respuestas con el equipo de Shopify
A diferencia de las pruebas unitarias, las pruebas de extremo a extremo buscan interactuar con su aplicación tal como lo haría un usuario real. Y como todos sabemos, puede ser bastante desafiante. Especialmente cuando hablamos de aplicaciones móviles. Las pruebas dependen de muchas condiciones y se consideran lentas e inestables. Por otro lado, las pruebas de extremo a extremo pueden dar la mayor confianza de que su aplicación está funcionando. Y si se hace correctamente, puede convertirse en una herramienta increíble para aumentar la velocidad del desarrollador. Detox es un marco de pruebas de extremo a extremo en caja gris para aplicaciones móviles. Desarrollado por Wix para resolver el problema de la lentitud e inestabilidad y utilizado por React Native en sí como su herramienta de pruebas E2E. Únete a mí en esta masterclass para aprender cómo hacer que tus pruebas de extremo a extremo móviles con Detox sean excelentes. Prerrequisitos- iOS/Android: MacOS Catalina o más reciente- Solo Android: Linux- Instalar antes de la masterclass
- Introducción - Cleo & nuestra misión- Lo que queremos construir, cómo encaja en nuestro producto & propósito, revisar los diseños- Comenzando con la configuración del entorno & “hola mundo”- Introducción a la animación de React Native- Paso 1: Hacer girar la rueda al presionar un botón- Paso 2: Arrastrar la rueda para darle velocidad- Paso 3: Agregar fricción a la rueda para frenarla- Paso 4 (extra): Agregar hápticos para una sensación inmersiva
Desplegar aplicaciones React Native manualmente en una máquina local puede ser complejo. Las diferencias entre Android e iOS requieren que los desarrolladores utilicen herramientas y procesos específicos para cada plataforma, incluidos los requisitos de hardware para iOS. Los despliegues manuales también dificultan la gestión de las credenciales de firma, las configuraciones de entorno, el seguimiento de las versiones y la colaboración en equipo. Appflow es la plataforma de DevOps móvil en la nube creada por Ionic. Utilizar un servicio como Appflow para construir aplicaciones React Native no solo proporciona acceso a potentes recursos informáticos, sino que también simplifica el proceso de despliegue al proporcionar un entorno centralizado para gestionar y distribuir tu aplicación en múltiples plataformas. Esto puede ahorrar tiempo y recursos, permitir la colaboración, así como mejorar la confiabilidad y escalabilidad general de una aplicación. En este masterclass, desplegarás una aplicación React Native para su entrega en dispositivos de prueba Android e iOS utilizando Appflow. También aprenderás los pasos para publicar en Google Play y Apple App Stores. No se requiere experiencia previa en el despliegue de aplicaciones nativas, y obtendrás una comprensión más profunda del proceso de despliegue móvil y las mejores prácticas para utilizar una plataforma de DevOps móvil en la nube para enviar rápidamente a gran escala.
Así que has configurado Detox para probar tu aplicación React Native. ¡Buen trabajo! Pero aún no has terminado: todavía hay muchas preguntas que necesitas responder. ¿Cuántas pruebas escribes? ¿Cuándo y dónde las ejecutas? ¿Cómo te aseguras de que hay datos de prueba disponibles? ¿Qué haces con partes de tu aplicación que utilizan APIs móviles que son difíciles de automatizar? Podrías invertir mucho esfuerzo en estas cosas, ¿vale la pena? En esta masterclass de tres horas abordaremos estas preguntas discutiendo cómo integrar Detox en tu flujo de trabajo de desarrollo. Saldrás con las habilidades e información que necesitas para hacer de las pruebas Detox una parte natural y productiva del desarrollo diario. Tabla de contenidos: - Decidir qué probar con Detox vs React Native Testing Library vs pruebas manuales- Configuración de una capa de API falsa para pruebas- Cómo hacer que Detox funcione en CI en GitHub Actions de forma gratuita- Decidir cuánto de tu aplicación probar con Detox: una escala móvil- Integración de Detox en tu flujo de trabajo de desarrollo local Prerrequisitos - Familiaridad con la construcción de aplicaciones con React Native- Experiencia básica con Detox- Configuración de la máquina: un entorno de desarrollo CLI de React Native en funcionamiento que incluye Xcode o Android Studio
Entonces, tienes una increíble aplicación web que has construido y quieres llevarla de tu navegador web a la App Store. Seguro, hay muchas opciones aquí, pero la mayoría requerirá que mantengas aplicaciones separadas para cada plataforma. Quieres que tu código base sea lo más cercano posible en la Web, Android e iOS. Afortunadamente, con Capacitor, puedes tomar tu aplicación web existente y crear rápidamente aplicaciones nativas para iOS y Android para distribuir en tu App Store favorita. Contenido: Este masterclass está dirigido a desarrolladores principiantes que tienen una aplicación web existente o están interesados en el desarrollo móvil. Repasaremos:- ¿Qué es Capacitor?- ¿Cómo se compara con otras soluciones multiplataforma?- Usando Capacitor para construir una aplicación nativa utilizando tu código web existente- Organizando nuestra aplicación para su distribución en tiendas de aplicaciones móviles con convenciones de nombres, iconos, pantallas de inicio y más
Comments