Llevando tu aplicación web de React a nativa con Capacitor

De acuerdo, este masterclass está llevando tu aplicación web de React a nativo con Capacitor. Como dije, mi nombre es Mike Hardington. Trabajo en esta tecnología. Trabajo en una empresa llamada Ionic. Hacemos cosas geniales no solo con tecnología web sino también con nativo. Así que sabemos algo sobre cómo llevar aplicaciones web a nativo. Y también traer algo de la bondad web a nativo.

Un pequeño aviso sobre algunos detalles. Esto se está grabando. Podrás ver cualquier repetición más adelante. Intentaré publicar todas las diapositivas. Aunque no creo que las diapositivas sean muy aplicables más adelante. La mayor parte de la conversación que tendremos aquí será la parte más importante. Intentaré publicar lo que pueda después. Pero no te preocupes demasiado por las diapositivas y todo. Como dije, haz tus preguntas. Hay una función de chat, la usaremos. También usa Discord si te sientes cómodo allí. Intentaré encontrarte donde estés, en lugar de obligarte a usar una cosa en particular.

Entonces, con eso fuera del camino, parece que llegamos a un punto en común en los asistentes. ¡Vamos a sumergirnos! Primero quiero profundizar en este concepto porque será el punto central de todo lo que vamos a cubrir hoy. Es esta idea de desarrollo multiplataforma. El desarrollo multiplataforma no es algo poco común. Se hace en casi todas las especialidades de software. Si pensamos en los juegos, los juegos de video, rara vez vemos a las personas escribir un juego una vez para PlayStation, una vez para Xbox y luego, nuevamente, para PC. Por lo general, hay alguna herramienta que están utilizando para construir sus juegos y luego pueden ejecutarlos en todas las consolas, los entornos de escritorio. Y todo lo que realmente necesitan hacer es construir sus juegos usando estas herramientas para poder aprovechar este desarrollo multiplataforma. Así que este es un enfoque muy probado para construir un producto y construir cualquier cosa. Solo lo vamos a ver en el contexto de construir una aplicación y llevar tus aplicaciones web existentes a poder portarlas a estas diferentes plataformas. Entonces, lo que estamos tratando de averiguar es cómo podemos reducir la necesidad de aprender cosas nuevas, reducir la necesidad de crear más código específico de una plataforma diferente y reducir el tiempo que nos lleva realmente lanzar todo porque tener todas las diferentes opciones tecnológicas disponibles para nosotros es algo increíble, pero si estamos gastando mucho tiempo teniendo que enfocarnos en aprender una herramienta en particular y luego nunca llegamos a lanzar, es un poco en vano. Así que reducir nuestro conocimiento general que necesitamos saber, reducir el código que necesitamos escribir y luego reducir la cantidad de tiempo que nos lleva lanzar algo.

Al comparar diferentes tecnologías, tenemos que verlo en términos de abstracción. Con demasiada frecuencia, nos encontramos en una situación en la que a la gente le gusta decir que x es mejor que y por estas tres razones. Quiero decir, piensa en cuántos artículos de comparación existen por ahí, React Native versus Flutter, Flutter versus la web. Todas estas comparaciones de tecnología diferentes se están haciendo un flaco favor a sí mismas porque están tratando de ir punto por punto con la cosa con la que se están comparando. No siempre funciona de esa manera. Pensar en términos de niveles de abstracción para mí tiene un poco más de sentido. Vamos a ver algunos de ellos. La forma en que suelo pensar en esto es qué tan alejada está nuestra elección tecnológica de un objetivo dado. Aquí a la izquierda, tenemos un entorno de desarrollo web puro. Ni siquiera te estás enfocando en móvil o nativo móvil. Solo te estás enfocando en construir una buena experiencia web receptiva. Por otro lado, tenemos el desarrollo nativo puro, donde no nos importa la web. Solo nos enfocamos en construir una aplicación nativa dedicada para cada plataforma. Y tenemos muchos equipos que pueden enfocarse en eso y trabajar en ese entorno.

Entonces, comencemos con el sitio web puro. Y voy a analizar este primero. Lo más probable es que si has sido desarrollador durante al menos cinco años, es posible que hayas oído hablar de este proyecto. Se llama Cordova. Probablemente fue uno de los primeros proyectos en promover este lema de escribir una vez y ejecutar en cualquier lugar.

Donde básicamente te daban un relleno para las funciones nativas del dispositivo. Eran un grupo de desarrolladores que querían construir aplicaciones web. Pero en ese momento, la web no era realmente una buena plataforma para desarrollar. Faltaban varias funciones clave que los dispositivos nativos tenían de inmediato. Así que decidieron construir esta tecnología para exponer estas funciones nativas a través de JavaScript y permitir que los desarrolladores envolvieran sus aplicaciones web en este tiempo de ejecución y luego proporcionar acceso a esas funciones mediante la ampliación de las funciones integradas de la plataforma web.

Por ejemplo, si había una antigua especificación de geolocalización, envolvían su propia API de geolocalización sobre esa antigua especificación. Así que extendieron muchas de las funciones integradas que se envían con el navegador para complementar sus propias funciones nativas del tiempo de ejecución. Comenzaron usando este enfoque y se dieron cuenta de que ciertas API no se mapeaban bien a las funciones integradas. Así que eventualmente tuvieron que crear sus propias API globales y las construyeron sobre el objeto Navigator, por alguna razón, y dentro de esto pudieron construir objetos que tenían todas las funcionalidades para los complementos principales. Uno de los primeros que tenían era este complemento de cámara y luego crearon una forma de tomar una foto o presentar una actividad de cámara nativa a tus usuarios directamente desde tu JavaScript. Tenían este navigator.camera.getPicture. Tenía un callback onSuccess, onFail y luego había un tercer parámetro donde permitían configurar todas las diferentes opciones para esta ejecución. Si la llamada a la cámara tenía éxito, obtenías los datos de la imagen y si fallaba por alguna razón, obtenías un mensaje de error devuelto.

Funcionó bien. Ahora, este enfoque de usar navigator y tener todo vinculado a eso falla de inmediato cuando te das cuenta de que necesitas incluir Cordova con todo para que funcione. Actualmente no hay una API de cámara integrada en el navegador, aunque sería una nueva función fantástica. Así que automáticamente no es tan multiplataforma, porque si no lo incluyes en tu navegador web, o si intentas ejecutar esto en tu navegador web en este momento, fallaría porque no hay forma de simular la cámara con algo que exista en el navegador. El navegador. Así que esto solo está disponible cuando te diriges a iOS o Android.

La cámara era una API, pero había todo un ecosistema que surgió de Cordova, donde tenían cosas para Firebase, tenían complementos para... se me olvidó el nombre, Century, PayPal, tuvieron mucho éxito al hacer que las personas construyeran complementos y ellos mismos también enviaron una buena colección, creo que alrededor de 12 a 14 API principales que consideraron esenciales para un dispositivo. Entonces, geolocalización, cámara, acceso al sistema de archivos, controles de pantalla de inicio, controles de barra de estado, todos esos tipos de cosas. Realmente no tenían un administrador de paquetes. Cordova es anterior a NPM, lo cual es bastante difícil de imaginar en un entorno donde no teníamos NPM. Y esto también fue antes de Bower para las personas que recuerdan qué era Bower. Básicamente tenían estos scripts personalizados que se ejecutaban cada vez que querías iniciar un lanzamiento, lo cual no era muy bueno. Tenían muchas curvas de aprendizaje, porque estaban bastante adelantados a su tiempo en 2010. Así que toda esta idea era mantener la web, rellenar la web hasta que el navegador finalmente agregara esas funciones. Estamos en 2022, algunas de estas funciones aún no existen en el navegador en este momento. Así que es bastante justo decir que su objetivo objetivo fue bastante fallido. También no querían que tú como desarrollador necesitaras abrir un IDE nativo, lo cual no sé por qué. Un IDE nativo es en realidad una herramienta bastante buena para configurar estos proyectos nativos. Así que volviendo a esa cosa de scripts personalizados, si querías configurar tus perfiles para firmar y lanzar la aplicación, todo tenía que hacerse a través de etiquetas de script bastante oscuras o tareas de script y pasando diferentes opciones. No es ideal. Pero llevaron esto aún más lejos y hicieron que los proyectos nativos fueran cosas que se destruían y no se comprometían con el control de versiones. Si tú y un compañero de trabajo están tratando de trabajar en la misma aplicación, estableces un permiso en tu máquina, ellos establecen un permiso en su máquina, no hay forma de que esos permisos se compartan. Constantemente tienen que restablecerse. No es ideal. Ok. Así que ese es el comienzo del desarrollo multiplataforma. Eso estuvo sucediendo por un tiempo. La gente estaba bastante contenta con eso. Seguro, había algunos puntos problemáticos, pero en su mayor parte era el único proyecto en este espacio. Luego llegó algo llamado React Native y varios otros `compilar a nativo` donde su objetivo principal era decir, hey, escribe en esta herramienta y te dará una aplicación nativa pura después. Así que puse esto de manera un poco irónica diciendo que aprende una vez, escribe en cualquier lugar, como el objetivo inicial de React Native. Su idea era que tratar de escribir una vez, ejecutar en cualquier lugar nunca iba a funcionar. Así que en lugar de eso, te daban una abstracción donde podías aprender una API o un estilo de programación y permitirte escribir para todas estas plataformas diferentes. Prometieron que sería una aplicación verdaderamente nativa, lo cual no es necesariamente cierto. No es muy diferente de Cordova, y construyeron abstracciones alrededor de los controles nativos. Proporcionaron una buena biblioteca estándar, por así decirlo, alrededor de estas API nativas. Pero básicamente dependía de la comunidad agregar más funciones que las que realmente quería el equipo principal o cualquier equipo principal de varios proyectos.

Entonces, en cierto sentido, cuando estás construyendo, y esto es solo una simplificación para React Native, cuando estás construyendo una aplicación de React Native, tienes tu aplicación aquí en esta caja azul que se ejecuta dentro de un tiempo de ejecución de JavaScript. Podría ser V8, algo más. Pero esencialmente, eso está ejecutando tu JavaScript, y ese tiempo de ejecución se comunicará a través de una capa de puente. Cada vez que esa capa de puente intenta acceder a las funciones del dispositivo, se va a comunicar con las funciones reales del dispositivo, obtener los resultados, serializar eso a JSON y luego devolver eso al tiempo de ejecución de JavaScript y eso se enviará de vuelta a tu aplicación.

A medida que se evalúa la interfaz de usuario, la capa de puente también se comunicará con el tiempo de ejecución nativo y renderizará todos los controles esencialmente sobre la marcha. Así que todos los elementos de la interfaz de usuario, los botones, las tarjetas, la navegación por pestañas, se están renderizando internamente a través de React Native. Y esta es en realidad una infraestructura bastante similar a otros proyectos. No es específico de React Native, así que no asumas eso. Hay una arquitectura muy similar a Cordova aquí. La única diferencia es que en lugar de un tiempo de ejecución de JavaScript, es un ecosistema de navegador completo, y separamos el proceso de renderizado y simplemente usamos el navegador para renderizar. Así que estas son arquitecturas muy similares.

Y esto es un poco mi propia opinión personal al respecto, donde se descompone un poco es tener esta idea de tener que aprender una nueva sintaxis que no es esencialmente lo mismo que has aprendido para el desarrollo web. Tener que aprender cómo volver a hacer etiquetas h1, h2, párrafos, enlaces es un poco frustrante. Entiendo por qué lo hicieron, pero es otra cosa más que aprender. Si tienes una aplicación web existente que estás tratando de llevar al tiempo de ejecución nativo o a las tiendas nativas, lamentablemente tendrás que reescribir esa aplicación para que sea compatible con este tiempo de ejecución de React Native. Algunas personas lo harán y dirán que está bien, pero sigue siendo una sensación frustrante. Y finalmente, si hay una biblioteca de terceros que realmente te gusta, si no admite React Native de forma nativa, no puedes usarla. Tengo una de mis bibliotecas favoritas que se llama fill.js, que es un editor de texto enriquecido. No puedes usarlo en React Native debido a cómo está construido y cómo funciona. Tienes que encontrar uno específico para React Native para que funcione en una aplicación de React Native, lo cual no parece correcto, en mi opinión.

Sí, lo mencioné antes, pero la idea de que sea verdaderamente nativo es un poco engañosa. Arquitectónicamente, todavía se ejecuta JavaScript, los controles se renderizan sobre la marcha, esencialmente hay un agente de renderizado personalizado. Este último punto para aquellos interesados en Flutter, esto es algo con lo que debes lidiar, el renderizado no está realmente renderizando controles nativos, está renderizando cosas en el sentido más amplio en un lienzo. Y luego estás interactuando y volviendo a implementar todas las interacciones nativas. Tómalo como quieras, es simplemente un hecho. Siguiendo adelante, ¿cuáles son las otras opciones aquí? Idealmente, queremos algo que combine el ciclo de vida del desarrollo nativo, pero que aún esté muy en esta mentalidad de desarrollador web donde solo estoy escribiendo HTML, CSS y JavaScript. Puedo llevar no solo React, sino cualquier framework a mi conjunto de herramientas y puedo enviar lo que quiera. Así que eso es en lo que nos enfocaremos hoy, y eso es Capacitor.

Entonces, en un tiempo de ejecución, Capacitor es un tiempo de ejecución nativo y una biblioteca de JavaScript. Es, en primer lugar, una forma de importar paquetes que proporcionan acceso a las funciones nativas del dispositivo. Similar a Cordova en ese sentido. Excepto que cada paquete en sí mismo permite envolver varias API diferentes y veremos cómo funciona eso. Las API con las que interactúas como desarrollador están simplificadas. De esta manera, tienes una forma particular de acceder al sistema de archivos y luego los paquetes con los que interactuarás saben cómo enviar esas opciones y llamar a ciertos métodos que se ajustan a iOS o Android. Y cuando quieres incluir un nuevo paquete, básicamente solo estás obteniendo eso de los administradores de paquetes nativos dentro de los proyectos respectivos. Entonces, si instalo, digamos, nuestra API de sistema de archivos, es una instalación de npm para mí, pero detrás de escena está utilizando CocoaPods para obtener las dependencias para iOS, utilizando bibliotecas de Android para Android. Por lo tanto, la historia de la gestión de paquetes aquí y cómo el código llega desde tus módulos de nodo al proyecto nativo se siente familiar para esas plataformas respectivas.

Echemos un vistazo a la arquitectura porque creo que esto es realmente importante. Tenemos nuestra aplicación web aquí en la caja azul nuevamente, y se renderiza dentro de una vista web nativa. Esta vista web nativa es básicamente una versión optimizada de Chrome, Safari, lo que sea, sin ninguno de los elementos de la interfaz de usuario del navegador. Cuando haces una llamada desde tu aplicación web a través de las API de Capacitor, esa vista web nativa podrá escuchar esa llamada, o al menos saber que algo dentro de ella está intentando llamar a una API de Capacitor. Obtendrá la información de a qué dispositivo estás intentando llamar y enviará eso a la capa de puente. La capa de puente luego se comunicará con las funciones nativas, ya sean funciones a nivel del sistema operativo o funciones de hardware. Serializará los resultados, los devolverá, los enviará de vuelta a la vista web nativa y luego eso se devolverá a tu código JavaScript. Entonces, arquitectónicamente, esto es muy similar a cómo funciona React Native, con la excepción de que estamos renderizando nuestra propia interfaz de usuario. Entonces, si tienes una biblioteca de interfaz de usuario, o si tienes tu propio sistema de diseño implementado, puedes llevar eso a un proyecto de Capacitor y seguir teniendo la misma experiencia entre tu sitio web, tu aplicación nativa de iOS y tu aplicación nativa de Android. Una gran experiencia en general. Lo que hace que esto sea diferente es que, como dije, puedes reutilizar tus aplicaciones web existentes y tus habilidades web existentes. Esto incluye bibliotecas de terceros, frameworks, nuevamente, hoy lo estamos viendo con React, pero esto es independiente del framework. Entonces, si más adelante trabajas en un proyecto y tienes que usar algo como Svelte o Solid, o Vue en el futuro, puedes hacerlo. El tiempo de carga del tiempo de ejecución es instantáneo, por lo que mientras tu aplicación se está iniciando, esencialmente puede llamar

Entonces, eso es suficiente para las diapositivas. Suficiente para todo eso. Vamos a ver, tenemos una pregunta. ¿Produce una aplicación nativa o una aplicación web con características del sistema operativo del hardware móvil? Sí a ambos. Sé que no es realmente una gran respuesta en este momento, pero te mostraré más sobre por qué creo que es ambas cosas. Y puedes debatir si crees que estoy equivocado. Vamos a mi terminal. Así que tengo una aplicación aquí. La abriré en VS code. Y cambiaré mi esquema de colores muy rápido porque está muy brillante. Y luego también iniciaré mi terminal. Esto es literalmente un proyecto de aplicación en blanco de React. Y vamos a poner esto aquí y hacer una gestión rápida de ventanas. Solo una más. ¿Puedo obtener un pulgar hacia arriba si puedes dar pulgar hacia arriba en el chat? ¿O puedo obtener alguna indicación en el chat si crees que eso está bien? Index.ts. Dex.tx. ¿Cómo se ve el tamaño de fuente? ¿Demasiado grande? ¿No lo suficientemente grande? ¿Se ve bien? ¿Algo? De acuerdo. Vi un pulgar hacia arriba, así que vamos a asumir que está bien. Genial. Gracias a todos. Entonces, acabo de crear esta aplicación. Puedes crear tu propia aplicación con create React app si quieres. Creo que es MPX create React app init. No me cites en eso. Pero la idea es que esto no es más que lo que sugieren los documentos de React que hagas. Creas un proyecto, ahora tienes todos tus archivos aquí. Tienes un app.tsx. Estoy usando TypeScript para esto. No es obligatorio. Solo creo que es probablemente la mejor manera de hacer esto en 2022. Y asegurarse de que todo tenga sentido. Es de una manera segura en cuanto a tipos. tenemos nuestra aplicación aquí. Se está cargando una imagen. Tenemos algunos documentos en el código. Probablemente podamos eliminar esta etiqueta de enlace. Todo se está actualizando bastante bien. Y nos vamos a enfocar en esto durante la mayor parte de esto. Porque no siento que esté tratando de incluir tantas opiniones

Y con eso instalado... tenemos una pregunta. Genial. Stephane, responderemos a tu pregunta en un momento. Solo quiero inicializar este proyecto primero. Para inicializar el proyecto, una vez que tengamos instalada la CLI de Capacitor, simplemente podemos ejecutar npx cap, y luego init. Así que este será nuestro pequeño proceso de inicio de cómo creamos un proyecto. ¿Cuál debería ser el nombre de nuestra aplicación? Podemos decir React Summit. Nuevamente, amigable para el usuario, debería ser algo que la gente buscará. La siguiente parte es el ID del paquete. Ahora, el ID del paquete es algo bastante estándar que ocurre tanto en iOS como en Android. Si nunca has hecho desarrollo nativo antes, puede ser un poco confuso. Suelen esperar este estilo de dominio inverso, pero no hay una práctica establecida sobre cómo debería funcionar esto. Así que simplemente voy a poner com.mhartington.app. Esperemos que funcione, y luego verás que crea este archivo de configuración para nosotros, capacitor.config.ts, y luego produce algunos documentos sobre cómo comenzar y qué hacer a continuación. Vamos a recorrer todo esto juntos, por lo que realmente no necesitamos consultar esos documentos, pero los mantendremos en segundo plano en caso de que algo salga mal, lo cual no debería ocurrir.

Así que echemos un vistazo a ese archivo de configuración de Capacitor. Nuestro archivo de configuración básicamente le dice a nuestra herramienta cómo gestionar el proyecto y manejar todas las diferentes dependencias en el código web que creamos. Obviamente, tenemos el ID de la aplicación aquí, que es ese ID de paquete de dominio inverso. Tenemos el nombre de nuestra aplicación, que se utilizará y mostrará en, por ejemplo, nuestro simulador o nuestro dispositivo real. El directorio web es básicamente donde se construye todo nuestro código de JavaScript. Entonces, para un proyecto de React, esto será build. Si tienes una estructura de proyecto personalizada o una configuración personalizada y no construyes el build, cambia esto a lo que quieras. Y luego, bundle-webruntime es solo un valor predeterminado si no estás usando un bundler, como Webpack o Vite. Puedes establecer esto en true e incluirá una referencia de etiqueta de script. No necesitamos preocuparnos por eso porque estamos usando Webpack en este caso. A partir de aquí, quiero incluir una... Vale, por alguna razón, Zoom ha capturado mis controles de teclado. Bien, espero que siga grabando. De acuerdo, lo que voy a hacer rápidamente es este pequeño truco que React no proporciona de forma predeterminada. Y eso es esta etiqueta meta viewport. Y soy terrible para recordarlo. Así que lo voy a copiar de un proyecto existente de un directorio. Y voy a copiar este viewport en su lugar. Permíteme volver al código S. ¿Dónde lo tenía? Viewport, ¿es eso? Sí, meta Viewport. Básicamente, lo que acabo de hacer aquí, debido a los dispositivos que tienen una muesca, iPhone, ciertos dispositivos Pixel, dispositivos Samsung ahora, necesitamos incluir esta parte del Viewport para decirle esencialmente al tiempo de ejecución web que use todo el espacio disponible. De lo contrario, se cortaría debajo de la muesca y se vería un poco extraño. Así que lo mantendremos ahí, y guardaremos, nuestro proyecto sigue ejecutándose en el navegador web, y vamos a comenzar a acceder a nuestra primera función nativa. Voy a usar la geolocalización primero, porque es una API bastante familiar, porque existe en el navegador en este momento, y puedes usar la API de geolocalización del navegador en su lugar. Quiero mostrar por qué usarías capacitor.

Pero primero necesitamos instalarlo. Para instalarlo, tenemos todas las API principales divididas en sus propios paquetes npm. Por lo tanto, podemos instalarlo simplemente diciendo npm install capacitor geolocation. El complemento de geolocalización se centra únicamente en la geolocalización y proporciona todas las dependencias necesarias para eso, que básicamente son el código iOS apropiado y el código Android apropiado. Luego envuelve la geolocalización web para un entorno web.

Entonces, volviendo a VS Code, y con eso instalado, vamos a nuestro app.tsx, y agreguemos algunas cosas aquí para comenzar a llamar a la geolocalización. Primero vamos a importar de at capacitor geolocation, e importaremos la API de geolocalización. La API de geolocalización contendrá todos los métodos disponibles para nosotros, nos permitirá proporcionar todos los permisos necesarios y nos permitirá gestionar esos permisos internamente. Así que vamos a importar también de capacitor core porque hay algunas diferencias en cómo las plataformas gestionan la ubicación o los permisos. Vamos a importar esta clase principal de capacitor y nos dará todo lo que necesitamos aquí. Ahora, también necesitamos tener, creo que puedes hacerlo aquí arriba, en realidad no necesitamos importar React de Reactive, al menos necesitamos importar use, use effect para poder gestionar el manejo de estos permisos. Así que vamos a crear este use effect y no tendrá dependencias. Por lo tanto, actuará como un gancho de ciclo de vida de inicio y el use effect será asíncrono, lo cual no sé si es recomendable. Aún lo hago porque, bueno, lo hago. En realidad, no lo haremos. Haremos las cosas correctamente, apropiadamente. Entonces, nuestra forma de gestionar los permisos o obtener todas estas cosas es vamos a querer tener una función de solicitud de permiso que se llame cuando la aplicación se inicie inicialmente o cuando este componente se renderice inicialmente. Debido a que no tiene dependencias, solo llamarías a esta instancia de useEffect una vez. Y luego necesitamos una constante request permission. Será una función asíncrona. Y dentro de esto, simplemente podríamos llamar geolocation.requestPermission. Entonces, oh, mala desplazamiento. Esto es literalmente cómo se solicitará y tratará de solicitar permiso del navegador para obtener la ubicación. Guardemos esto primero y veamos cómo funciona. Entonces, no sucede nada realmente. Abramos las DevTools. Estoy usando Safari. Comentarios para ti sobre eso. Pero lo que tenemos aquí es que tenemos este rechazo de promesa no resuelta. Como dije, la web no maneja los permisos realmente bien en comparación con iOS o Android. Por lo tanto, habrá casos en los que tengas algunas API que se comporten ligeramente diferentes entre las diferentes plataformas. No es un problema muy grande porque la advertencia aquí o el error aquí es solo un simple rechazo no resuelto que podríamos rechazar y manejar nosotros mismos. Por lo tanto, tu aplicación no se bloqueará por completo si haces esto. Si no te gusta ver estos rechazos de promesas no resueltas, maneja bien el rechazo o puedes hacer lo que haría yo y simplemente decir, si capacitor.isnativeplatform y luego llevar esto aquí arriba y solo se ejecutará si está en una plataforma nativa. Así que ya tenemos una buena experiencia aquí. Podemos hacer algunas comprobaciones rápidas de runtime para ver si estamos en una plataforma nativa. Y si lo estamos, deberíamos poder solicitar permiso.

Continuando a continuación, primero debemos obtener nuestra ubicación. Entonces podemos tener un nuevo método llamado get AutoCompleteFailingMe, getLocation, que intentará obtener nuestros datos de ubicación. Así que vamos a hacer un boceto rápido de esto. GetLocation, genial. Voy a centrar esto rápidamente. Entonces, esta función getLocation, simplemente es una forma, esta es una función asíncrona, nuevamente, todo en Capacitor es asíncrono. Por lo tanto, estarás lidiando con muchas async await o promesas si eso es lo que prefieres. En este caso, quiero usar async await porque creo que es un poco más fácil, pero también podríamos usar promesas. Entonces, dentro de esta getLocation, queremos tener una variable y será await geolocation.getCurrentPosition. Ahora, getCurrentPosition será básicamente una llamada única. En iOS y Android, en segundo plano, dividirá una llamada de ubicación única, devolverá esos datos y luego limpiará después de sí mismo. Por lo tanto, administrará la memoria y el impacto de esta llamada por ti sin que tengas que hacer ninguna limpieza. Esperaremos los resultados de esto y los almacenaremos en una variable de bloqueo.

Y podemos ver los diferentes valores de retorno que obtenemos. Podemos obtener un conjunto de coordenadas o, si mi cursor quisiera moverse, o una marca de tiempo. La marca de tiempo podría ser útil si estás haciendo algún tipo de seguimiento de ubicación donde quieres actualizar a tus usuarios. Por ejemplo, si estás haciendo una aplicación de entrega, podrías usar las marcas de tiempo para informar que tu conductor ha salido del edificio a tal hora o que tu repartidor ha salido a cierta hora. Queremos obtener esta posición actual y también queremos mostrarla dentro de nuestra aplicación.

Así que continuemos en la parte superior de nuestra función y vamos a crear algunas variables de estado rápidamente. Usaremos simplemente date y tendremos location data y set location data. Y tendremos location data y set location data. Con eso, podemos decir que set location data va a ser igual a una llamada de función y tendremos nuestra longitud, que será lock.coordinates.longitude. Y luego también tendremos una latitud, que será lock.coords.latitude. Ahora voy a hacer una pequeña limpieza rápida, TypeScript se va a enojar mucho conmigo, y solo le daré un tipo. Proporcionar los tipos adecuados para todo. Y en realidad, veamos qué hay en las coordenadas. Entonces, las coordenadas nos dan varias cosas de forma predeterminada, latitud, longitud, precisión, y también precisión de altitud. Por lo tanto, puede devolver si estás a una elevación. También dentro de ella, hay algunas cosas opcionales, lock.coords, aquí dentro. Por ejemplo, podríamos tener la dirección, podríamos tener, veamos, altitud, precisión. Solo está disponible en plataformas nativas, por lo que es opcional, podría ser indefinido. Puedes manejar eso en ciertas situaciones donde no devuelve un valor. Tenlo en cuenta al hacer cosas. Cerrémoslo.

Y luego, debajo de nuestro, o dentro de esta etiqueta de párrafo, en realidad, cambiemos la etiqueta de párrafo por una etiqueta pre, y dentro de esto vamos a renderizar JSON, eso es Stringify, location data. Y este es un truco realmente divertido sobre cómo indentar todo esto de una manera legible. No lo mostraré en Safari, porque Safari no simula realmente mi ubicación. No es que no confíe en todos ustedes. Simplemente no quiero que mi ubicación esté ahí fuera. Creo que es localhost 3000. Y veamos qué sucede. Ahí tienes, viste nuestra ubicación. Así que en realidad, sigamos adelante y gestionemos esta ubicación. Eliminaremos esto, solo porque quiero mostrar cómo se configura el permiso. Y todo esto se gestiona a través de la instancia real del navegador en este punto. Entonces, cuando estás en el navegador, porque no hay un modelo de permisos incorporado o una configuración de permisos comparable a iOS o Android, a medida que intentas solicitar permiso, utilizará el modelo de ajuste en tiempo real. Por lo tanto, puedes ver aquí que en esta promesa para getCurrentPosition, tenemos un tiempo de espera, que se puede configurar para que puedas esperar un poco más. Pero si no lo permites en cierta cantidad de tiempo, obtienes una promesa rechazada. En este caso, vamos a permitirlo. Y debido a que ocurrió el tiempo de espera, haremos una actualización rápida, y puedes ver que tenemos nuestra ubicación data que nos señala nuestra ubicación simulada. Hasta ahora, todo bien. Esto es exactamente lo que queremos. Esto es simplemente lo mínimo indispensable. Dije, no espero que todos ustedes tengan configurado el SDK de iOS o Android, pero quiero agregar primero una plataforma nativa para mostrar cómo puede funcionar esto. Si quieres intentar instalar el SDK de iOS o Android, tenemos mucha, no permitas, tenemos una buena documentación aquí sobre cómo comenzar con esto y cómo configurar tu entorno para trabajar con estas plataformas nativas. Vamos a omitir eso. Definitivamente échale un vistazo. Si quieres, Capacitorjs.com/docs, lo dejaré en el chat. Nos vamos a centrar y asumir que algunas de estas cosas ya están configuradas. Para agregar una plataforma, simplemente podemos ejecutar npm install en capacitor, y luego tenemos dos plataformas disponibles que admitimos de forma predeterminada. Obviamente iOS y, veamos, iOS y Android. Y vamos a instalarlos rápidamente. Ahora, cuando, quiero mencionar una de las preguntas, que fue de Stefan, comparando Ionic Cordova versus Ionic con Capacitor.

¿Cuál es la diferencia de rendimiento? ¿Cuál es la diferencia en los complementos? Si usamos complementos de Cordova dentro de Capacitor, ¿es más lento que usar un complemento alternativo de Capacitor?

Entonces, asegurémonos, puedes activar el sonido si quieres, Stefan. Solo quiero asegurarme de entender completamente tu pregunta en este contexto. Sí. De acuerdo. Para mí es importante, el rendimiento de Cordova, en comparación con Capacitor. ¿Y por qué debería cambiar mi proyecto de Cordova a Capacitor? Esa es mi pregunta. Sí, sí, sí. Entonces, esto es un poco adelantado. Pero puedes responder más tarde si quieres. Cuando lleguemos a eso. De acuerdo, hagamos eso y luego puedo proporcionar más detalles. Sí, gracias. Genial. No hay problema.

Entonces, hemos instalado las dos plataformas, iOS y Android. Sigamos adelante y luego llamemos a cap add iOS. Ahora, dividimos la instalación y los comandos de agregar en dos cosas diferentes, porque es posible que tenga una instalación de paquetes de iOS, pero no esté en una Mac y esté en una Windows. Eso fallaría, pero aún queremos que pueda instalar los paquetes sin problemas. Entonces, los dividimos en dos cosas diferentes y simplifica nuestro trabajo que necesitamos hacer.

Entonces, agregaremos un proyecto iOS. Puedes ver, va a crear este proyecto nativo de Xcode. Ya son milisegundos. No pudo ejecutarlo, o no pudo sincronizarlo con los activos web al proyecto nativo porque no hay un directorio de compilación. Y luego obtenemos este pequeño documento agradable sobre cómo manejar los flujos de trabajo. Si te pierdes, la documentación siempre estará ahí. Podemos hacer lo mismo para Android. Hará los mismos pasos exactos y producirá la misma salida exacta en diferentes momentos. Así que voy a mostrar iOS primero porque es donde estoy más familiarizado pero mostraremos Android después.

Entonces, sigamos adelante y hagamos una compilación rápida. Ejecutará los scripts de React y ejecutará nuestra compilación nativa o nuestra compilación web y generará el JavaScript que necesitamos implementar en iOS. Con ese proceso terminado, podemos ejecutar mpx cap sync iOS. Ahora puedes ver que está avanzando, copió todos los activos web pero también está utilizando esta dependencia nativa y no sé qué tan bien puedas ver con los destellos. Está utilizando esta herramienta nativa de CocoaPods que usa iOS. Entonces, todas las dependencias se instalan a través de CocoaPods para iOS y bibliotecas de Android para Android y mantiene las herramientas que necesitamos generar al mínimo y utiliza el ecosistema existente.

Una vez que hayamos terminado con eso, podemos ejecutar mpx cap open iOS y abrirá nuestro espacio de trabajo nativo de Xcode. Démosle un momento. Si Xcode está un poco lento hoy, eso es bastante normal. Xcode es de alguna manera más lento que cualquier aplicación de Electron que haya usado, lo cual será realmente doloroso para los entusiastas de las aplicaciones de escritorio nativas. Voy a seleccionar mi dispositivo como 13 Pro. Voy a dejar que termine de indexar todos los archivos. Puedes ver aquí tenemos un poco de un árbol de archivos donde tenemos todas las dependencias que nuestro proyecto nativo necesita, las versiones de desarrollo, y luego los frameworks y herramientas reales que se incluyen con esto. Aquí puedes ver que tenemos el capacitor. Tenemos este Capacitor Cordova Pod, que es nuestra capa de puente. Entonces, si eres alguien que tiene una aplicación de Cordova y solo quieres migrar, pero no estás completamente decidido a poder reemplazar todo, Capacitor puede tomar tu aplicación de Cordova y también admitir eso. Tenemos un buen puente a las API de Cordova y una buena selección de API de terceros. Sugeriría mover todos tus complementos a usar Capacitor una vez.

Y tenemos nuestra API de geolocalización, veamos en qué consiste esto. Solo creo que esto es divertido. Entonces tenemos nuestro código nativo bastante típico aquí. Estamos importando algunas versiones de complementos, algunos datos agradables, tenemos todos los diferentes métodos y en realidad admite todos los métodos como getCurrentPosition, watchPosition, revelar un pequeño secreto de lo que haremos más tarde. Y luego checkPermissions y requestPermissions. Todo esto se hace dentro de nuestro código Swift. Swift es un lenguaje, si nunca lo has escrito antes, no nos enfocaremos demasiado en eso, pero puedes ver que tenemos esta forma agradable, asíncrona de obtener la ubicación y administrar todo esto por ti. Lo mismo ocurre con watchPosition. Tenemos toda esta forma completa de obtener la posición actual y observar los cambios a medida que ocurren con el tiempo. Entonces hay un montón de código nativo aquí. También tenemos nuestra aplicación, que es nuestro app.delegate. El delegado de la aplicación es probablemente algo que no personalizarás o no usarás demasiado. Pero si eres parte de un equipo donde hay una colaboración entre desarrolladores web y un desarrollador nativo, ya sea iOS o Android, puedes hacer que ellos vengan aquí y proporcionen algunas características de anulación cuando tu aplicación comienza a lanzarse, cuando vuelve a estar activa después de estar en segundo plano, o cuando desea recibir notificaciones. Entonces, todo esto se puede personalizar a tu gusto. El guión principal, los guiones gráficos, la mejor manera que se me ocurre para describirlos es que son nuestras especie de maquetas y nuestras formas de construir la estructura de nuestra aplicación, como agregar widgets en la interfaz de usuario. Realmente no necesitamos enfocarnos demasiado en eso, primero vamos a intentar ejecutar esto y hacer que todo se cargue en un simulador. Voy a ejecutar esto desde este pequeño botón de reproducción, intentará implementar esto en mi simulador de iPhone 13 Pro. Vamos a darle un momento.

Como dije, Xcode puede ser muy lento. Voy a abrir este registro de antemano, y nos permitirá ver qué sucede detrás de escena. La compilación se realizó correctamente, eso es genial. Dejemos que esto se ejecute rápidamente, y observaré esto para el simulador. Genial, el simulador está en marcha. Vamos a activar esta función rápidamente, establecer la ubicación en Apple Park, y pondremos en marcha nuestra aplicación. Y esperemos poder ver la ubicación. Solo démosle un momento para que realmente se ponga en marcha todo. Y podrás darte cuenta cuando todo esté listo ya que el dispositivo podrá imprimir algunas cosas aquí. Esto no funciona. Sí, ¿ves? Genial, así que lleva un poco de tiempo poner en marcha todas estas cosas. Las ejecuciones posteriores serán más rápidas. Es solo porque esto fue un inicio en frío. Y solo para demostrar eso, detengámoslo rápidamente y ejecutémoslo nuevamente. Veamos, ya está en marcha. Ahora, nota que estamos tratando de obtener la posición actual, pero tenemos un error. Esto fue intencional. El error es que la aplicación ha intentado acceder a algunos datos sensibles de privacidad sin ninguna descripción de uso. Entonces, necesitamos agregar aquí una gestión de permisos nativa que nos permita acceder a estos datos. Así que vamos a copiar esto. Entonces, NSLocation, cuando se utiliza, descripción de uso. Como dije, esto está obteniendo todo lo real, ya sabes, lo que necesitamos tanto de nativo como de web. Así que vamos a ir a info.plist. Si nunca has trabajado con info.plist antes, es un formato de datos bastante típico para, agregar una fila para configurar cosas para tu proyecto específico. Entonces tenemos nuestro NSLocation, cuando se utiliza, descripción de uso. Es más fácil decir privacidad. Ubicación, descripción de uso. Podemos establecer el valor de esto en, Quiero ver la ubicación para la demostración. Cosas bastante estándar. Ubicación, hay un montón de valores diferentes que podemos poner aquí. Entonces, si has abierto una aplicación antes, Uber, Uber Eats, cualquier tipo de aplicación de entrega donde necesitan conocer tu ubicación. Hay diferentes opciones aquí para un uso único y uso siempre, siempre en segundo plano. Puedes proporcionar esa configuración de privacidad y esperar que tus usuarios puedan aceptarla y puedes ver por qué quieren esa ubicación. Puedes decirles, solo quiero ver la ubicación para una demostración. Con eso configurado, volvamos a ejecutar esto nuevamente y abramos nuestra aplicación. Permitir que React Summit use tu ubicación, permitir una vez, y vamos a establecer la ubicación en Apple Park. No te pierdas que también obtenemos este pequeño icono aquí en la esquina superior para iOS. Solo indicará que algo intentó obtener nuestra ubicación. Ahora podemos ver la secuencia de eventos que han ocurrido. Entonces inflamos la aplicación, WebView se cargó, la solicitud de permiso de geolocalización fue nuestra primera llamada. Por lo tanto, se imprimió automáticamente. Obtenemos la posición actual y decidimos llamar a nativo. El permiso de ubicación regresó y dijimos, concedido, todo está bien. Y luego tenemos los resultados que regresan de nuestra obtención de ubicación. Por lo tanto, toda nuestra aplicación funciona como se esperaba y estamos obteniendo la ubicación correctamente. Entonces, pasando de esto, podemos comenzar a intentar y personalizar la experiencia de Android. Así que vamos a hacer lo mismo. En lugar de abrir, bueno, primero necesitamos sincronizar Android porque hicimos una compilación, y tiene sus activos web. Funcionó bien, en realidad es mucho más rápido de lo que sorprendentemente iOS, pero haremos npx cap open Android. Ahora, Android Studio, si hay algún fanático de los productos IntelliJ, WebStorm, PHP Storm, esto debería resultarte bastante familiar.

Básicamente, esto es IntelliJ con una apariencia diferente para el desarrollo de Android. Así que vamos a darle un momento, tarda un poco más en iniciarse, al menos para el IDE porque debe obtener todas las dependencias una vez que las instales. Puedes ver que estamos importando todos los diferentes complementos y todas las diferentes tareas y dejándolo operar. También indexará todos nuestros archivos para que podamos examinar toda la estructura del proyecto.

Bien, todo parece estar funcionando bien. Muy bien, ahora deberíamos poder continuar y construir este proyecto. Al igual que tuvimos que hacer para iOS, necesitamos proporcionar los permisos aquí. Y seré honesto, no recuerdo los permisos de Android. Son bastante diferentes en comparación con iOS. Afortunadamente, tenemos todos los complementos que forman parte de la oferta principal. El complemento de geolocalización te dirá qué permisos necesitas solicitar. Así que vamos a copiar estos, y luego dentro de esta aplicación, el manifiesto android manifest.xml, necesitamos imprimirlos o establecerlos aquí. Ya sabes, así obtendremos esta pequeña pestaña aquí que indica dónde deben ir nuestros permisos. Y vamos a imprimir estos tres permisos. Es posible que obtengas una pequeña advertencia que dice que tus permisos están fuera de la pestaña de la aplicación. Eso está totalmente bien. La aplicación seguirá funcionando igual de bien.

Con esos permisos establecidos, podemos ir a la parte superior de Android Studio, y tenemos nuestra selección de dispositivos, ya sea un Pixel 4 o Pixel 3, o cualquier dispositivo real, o podemos crear un nuevo dispositivo virtual. Voy a elegir el Pixel 4. Tenemos la configuración de nuestra aplicación, y luego pulsaremos este botón de reproducción. Tuve que iniciar el emulador completo, y puedes ver que tenía un estado guardado de antes cuando estaba practicando con un ejemplo diferente. Vamos a dejar que esto haga su trabajo. Como dije, Android Studio puede ser un poco más lento, pero no es terrible. Sin embargo, podemos cerrarlo, creo. Y si alguna vez tienes curiosidad, aquí está la salida completa que ocurre cuando estás construyendo tu aplicación. Así que puedes revisar eso para ver qué está sucediendo. Genial, así que nuestra aplicación está en funcionamiento, se implementó en el emulador sin problemas. Lo mismo que la versión de iOS, el inicio en frío de la aplicación tiende a llevar un poco de tiempo. Y esto solo sucede con los simuladores. Así que hay un poco de retraso. Así que permite mientras usas la aplicación, adelante, debería intentar obtener la ubicación. Es posible que haya expirado porque me tomé demasiado tiempo. Vamos a hacer doble clic para cerrarlo. Vamos a intentarlo una vez más. React Summit. ¡Genial! Genial, obtuvimos nuestra ubicación. Nuevamente, el emulador no es la mejor experiencia de desarrollo en mi opinión. Puede ser muy, muy lento. Puede no funcionar bien si tienes un dispositivo con poca potencia o si estás intentando ejecutar, por ejemplo, una llamada de Zoom y un emulador y muchas otras cosas al mismo tiempo. Entonces, si tienes un dispositivo, este es mi Nexus 5a, el último Nexus que hizo LG es mi dispositivo de testing. Es mucho más rápido que el emulador. Siempre vale la pena testing en un dispositivo real también porque tienes acceso a las notificaciones y todo. Así que ahora tenemos nuestra aplicación en ejecución y está utilizando la longitud y latitud. Estamos obteniendo todo y volviendo. Se ejecuta automáticamente en las plataformas web, iOS y Android. Sin que yo hable, probablemente 30 minutos y eso es solo esperar cosas. Muy bien, así que tenemos algunas preguntas aquí. Stephan pregunta, ¿es posible almacenar estos permisos en una configuración o todos los que trabajan en el mismo proyecto deben establecerlos manualmente para sus compilaciones? Muy buena pregunta. En realidad, si detuviéramos la ejecución y luego abriéramos esto aquí. Así que, este es el mismo proyecto, ¿verdad? Estado de Git.

Entonces, ahora tenemos varios archivos que básicamente serán parte del control de versiones, iOS y Android. Entonces, una vez que una persona configura los permisos, el proyecto nativo completo se incluye en, o una vez que han creado un proyecto, debería decir, esa plataforma nativa se agrega al control de versiones. Entonces, Stefan, si hicieras un cambio o agregaras un permiso, y luego lo subieras a Git, y luego yo descargara tus cambios, obtendría todos los permisos aquí y podría seguir trabajando en mi proyecto sin tener que restablecerlos constantemente. Podría haber margen para mejorar al agregarlos en diferentes ubicaciones y establecerlos a través de la API de TypeScript. Pero por el momento, seguirán estando disponibles independientemente de quién esté trabajando en el proyecto porque todos están controlados por versiones. Pero esperemos que eso...

Entonces, solo para recapitular, ¿cuáles son los diferentes beneficios en comparación con React Native nuevamente? Bueno, automáticamente, ahora tenemos, básicamente, una excelente manera de comenzar a trabajar sin tener que desarrollar inicialmente en el dispositivo. Entonces, si volvemos a ejecutar nuestro DevServer, esto se iniciará automáticamente, podríamos comenzar a desarrollar en el navegador primero, tener el mismo acceso a las API en un ciclo de desarrollo mucho más rápido, y simplemente mantener Chrome en el enfoque. Sería genial. Vamos, React DevTools.

Genial, entonces todo esto simplemente comenzará a funcionar en comparación con React Native que tiene que configurar un proyecto de React Native, configurar todas sus dependencias, básicamente aprender la nueva herramienta y sintaxis para ello. Básicamente, esto es solo HTML JavaScript más algunas funciones diferentes de JavaScript. Y funciona en el navegador de inmediato. Entonces no tengo que aprender un nuevo ciclo de desarrollo.

Ahora, si eres alguien que no quiere abrir Xcode o abrir Android Studio, de hecho, vamos a cerrarlos ahora mismo. Eso es justo lo que iba a decir, básicamente. Lo que no me gusta de React Native, como tener que abrir Xcode, compilar, llevar tiempo para hacer estas cosas. Y mientras estás desarrollando, generalmente buscas cosas más rápidas. Así que a veces es un poco molesto. Entonces, si hay una forma alternativa de hacer esto, por ejemplo, en la web, y luego tienes la misma experiencia que debería estar en Nativo, sería genial. Sí, quiero decir, la misma experiencia, se compartirá de la misma manera. Lo que es realmente agradable aquí, es que simplemente estamos desarrollando en el navegador y todo está funcionando, pero si queremos, podemos hacer un pequeño truco. Entonces también podríamos simplemente npm o npxcap run iOS, lo que configurará todo el proceso de compilación para nosotros, copiar todo esto, y en lugar de tener que abrir Xcode, ahora tenemos un pequeño selector aquí donde podemos seleccionar nuestro dispositivo, se encargará de ejecutar la compilación por nosotros, y lo implementará automáticamente en el simulador de iOS. Por lo tanto, reducir la necesidad de tener que abrir Xcode es realmente agradable. Dejaré que esto se ejecute nuevamente rápidamente. ¿Hay alguna otra pregunta?

Oh, veo que tenemos una pregunta. ¿Maneja una vista web proyectos grandes donde se realizan múltiples API nativas, y maneja la animación como lo hace el nativo? Veamos. ¿Maneja una vista web, Cahir, podrías explicar un poco más a qué te refieres? Puedes desactivar el silencio si quieres.

Sí, iba a preguntar si creamos, por ejemplo, un calendario, API, tal vez API de contactos, muchas API, y las API que, por ejemplo, los usuarios de React Native utilizan controladores nativos que mejoran la animación. Porque creo que las animaciones en Capacitor están hechas para CSS y HTML. Esas son las animaciones principales, supongo.

De acuerdo, para las múltiples API nativas, no permiten, todo el acceso a la API, nuevamente, como dije, se encuentra en estos complementos de API oficiales, Entonces mencionaste el Calendario y los contactos. Creo que tenemos un complemento de contactos, si no está en el oficial. Está en los complementos de la comunidad, donde tenemos esta gran comunidad de complementos de terceros que las personas han estado manteniendo para Bluetooth de baja energía, geolocalización en segundo plano. Vamos a verificar los contactos. Sí, aquí está. Este es el complemento de contactos que puedes usar y puedes instalar esto, agregar los complementos, y nuevamente, aquí están tus permisos. Y luego puedes continuar y agregarlos a tu proyecto. Por lo tanto, se pueden utilizar y aprovechar múltiples API nativas. En cuanto a las animaciones, probablemente quieras usar una biblioteca para eso. Dado que esto es solo web, podrías usar algo como Frame o Motion. Podrías construir tus propias animaciones utilizando JavaScript y la API de animaciones web. Varias formas diferentes de construir todas esas cosas. No diría que necesariamente eso es algo que debe ser manejado a través de un capacitor porque eso debería ser algo que forma parte de tu proceso de diseño de aplicaciones web. Genial. Muy bien. Hicimos una compilación única y nuestra aplicación está funcionando. Quiero mostrar una cosa que realmente disfruto y eso es obtener un ciclo de desarrollo más rápido. Tenemos toda esta sección de Conceptos aquí en nuestra documentación y tenemos esta recarga en vivo. Ahora, si estás usando esto con Ionic, hacemos trampa y proporcionamos mucho trabajo por ti. Pero si estás usando, digamos, React, podríamos decir, host equals npm run start y comenzará tu servidor de desarrollo de React. Luego podemos configurar la... Hola en Safari. Luego podemos configurar la URL para que apunte al lugar apropiado dentro de nuestra configuración de proyecto de capacitor. Entonces abriremos eso rápidamente y vamos a la configuración de capacitor.

Y luego tendremos una referencia al servidor. Creo que lo copié. Sí, ya no necesito esto. No necesito texto claro. Genial, así que vamos a verificarlo. No, creo que sí, sí, 30. Ahora necesito recordar cuál es mi IP. Eh, no debería ser un gran problema. Y solo verifiquemos que funcione bien. Increíble. Vamos a ejecutar nuestro mpxcap run iOS. Nuevamente, hará lo mismo que antes. Pero en lugar de apuntar a nuestros activos nativos o a nuestras cosas compiladas estáticamente, lo apuntará al servidor de desarrollo. Continúa y pon esto en marcha. Seguiremos manteniendo nuestros permisos, pero ahora, cuando vengamos a nuestro proyecto, si por alguna razón quisiéramos no usar pretag o si quisiéramos dividir esto, H1 ubicación, en marcha, ahora podríamos comenzar a desarrollar nuestra aplicación y tener todo esto básicamente vinculado a nuestros datos de ubicación data punto. Eso es todo. Básicamente, ahora nuestro ciclo de desarrollo se siente mucho más familiar para el desarrollo web tradicional. No tenemos que esperar estos largos tiempos de compilación porque tenemos carga de biblioteca en servidores de desarrollo. Así que todo esto funciona muy, muy bien. Y también funciona para los cambios de app dot CSS. Así que podríamos eliminar este Text Align Center. No creo que lo necesitemos. Dale un momento, se ve bastante bien. Increíble. Básicamente, ahora tienes un entorno familiar de desarrollo. Quería transmitir esto porque es realmente muy bueno. Si estás desarrollando una aplicación muy grande y compleja, puede ser molesto tener que ir constantemente entre trabajar en el navegador y luego implementar en el dispositivo nativo, descubrir que necesitas hacer cambios, reconstruir, volver a implementar. Esto funciona muy bien en el simulador y se actualiza en tiempo real a medida que hago estos cambios. Entonces, si elimino el H1, funciona de la misma manera. Esto no está limitado solo al uso de un simulador, también puedes implementarlo en un dispositivo real y tener la misma experiencia funcionando para ti. Otras cosas que también puedes manejar aquí, si por alguna razón queremos volver a esta aplicación de React Summit, y queremos cambiar este nombre o incluso cambiar los iconos, hay varias formas diferentes de hacer esto. Cosas, pero primero el servidor de desarrollo. Tenemos una extensión aquí dentro de VS Code. Se llama simplemente Ionic. No está limitado solo al framework. Puedes ver que tenemos muchas configuraciones de capacitor aquí, y podemos generar algunas pantallas de inicio personalizadas para ti utilizando algunas herramientas locales que se incluyen. Entonces usará, creo que es ReSharp, para generar iconos y pantallas de inicio para ti, e incluso incluir colores de fondo y primer plano para iconos complejos en Android. Si quieres tener una forma de GUI de abrir cosas en Android Studio y Xcode, puedes hacerlo. O si por alguna razón quieres gestionar el número de compilación, el número de versión, o cambiar completamente el nombre de la aplicación a algo como getNation, cambiará el nombre de toda la aplicación por ti. Luego puedes volver a implementar y se actualizará automáticamente para ti. Dale un segundo. No necesito eso, no necesito eso. No se encontraron problemas. Luego irá y me pedirá que elija mi simulador nuevamente. Y se asegurará automáticamente de que esté actualizado. Así que creo que si nos sentamos aquí y observamos, sí, actualizó el nombre y aún se implementó en el dispositivo. Así que aquí funciona muy bien. Genial. Quiero asegurarme, verificar cómo estamos de tiempo. No creo que vayamos a llegar a las tres horas completas.

Eso ha sido mucho en esta masterclass, lo cual está totalmente bien. Es mucha información de una vez, pero quiero abrir esto para cualquier otra pregunta o cualquier otra cosa que las personas quieran saber o estén curiosas acerca de ello. Eso está bien.

Entonces, ¿cuáles son los pros y los contras de ejecutar esto en YesWeb o en este Accelure? Android Studio para el desarrollo mientras se desarrolla? Una vez más, lo siento. ¿Cuáles son los pros y los contras? El punto es que tienes dos opciones para ejecutar esto localmente, por ejemplo, solo usando tu navegador web, como un kit de desarrollo o usando XFBOE en Android Studio. Entonces, ¿cuál es el proceso para ejecutar esto en un dispositivo? ¿Eso es lo que estás preguntando? Sí, ¿cuáles son las ventajas y desventajas de esto? Oh, las ventajas. De acuerdo, la ventaja es que obtienes una retroalimentación más rápida en el dispositivo, hay algunas cosas que se pueden emular dentro del navegador con diferentes grados de éxito. Pero si estás tratando de apuntar a un dispositivo móvil, a veces es mejor implementarlo en un dispositivo real y saber que esa será la experiencia para tus usuarios. Entonces, depende realmente de lo que estés tratando de hacer y de lo que estés tratando de lograr. Lograr. Probablemente, tengo una aplicación de mapas en la que he estado trabajando que siempre implemento en un dispositivo real solo para asegurarme de que el renderizado de la aplicación web en el mapa web sea lo más rápido y eficiente posible. Podría intentar emular eso en el navegador, pero el dispositivo es el que me brinda la retroalimentación más rápida y real. Y si lo implementáramos en esos dispositivos, aún podríamos conectar nuestras Chrome DevTools y inspeccionar eso y obtener esa retroalimentación sobre cómo va el performance. Sí, creo que esa es una buena respuesta. Pero aún así, mientras se desarrolla, a veces necesitas simplemente no perder tiempo moviéndote entre estas plataformas. Así que necesitamos desarrollar al final, donde necesitas probarlo completamente en un dispositivo real y ver si funciona correctamente o no. Pero mientras se desarrolla, sí, puedo usar un navegador Chrome. Y sí, si hay una lista de mapeo que indique qué está disponible en el navegador y qué no está disponible. Entonces eso también sería bueno antes de comenzar, construir algo durante dos días y luego descubrir que no es compatible. Eso es todo. Bueno, podemos echar un vistazo, si por ejemplo, en realidad la geolocalización, pero sí tenemos soporte. Creo que solía estar listado aquí donde puedes ver todos los diferentes complementos y qué plataforma es compatible. Creo que nuestro equipo de documentación podría haberlo eliminado. Así que tengo que abrir un problema para que lo vuelvan a agregar. Veamos, ¿cuál es el tamaño promedio o cuál es el tamaño total de la aplicación que se genera? Así que hagamos una compilación rápida y tratemos de obtener una estimación aproximada de lo que va a ser esto. Diría que el tamaño total será significativamente menor. Intentemos ejecutarlo en el simulador rápidamente para ver si podemos obtener un tamaño para eso. El tamaño total definitivamente será mucho más pequeño que, por ejemplo, una aplicación nativa pura. Bueno, será un poco más pequeño que algunas otras soluciones cross-platform y puede ser más pequeño que una aplicación nativa pura porque las herramientas y dependencias incluidas estarán mejor optimizadas. ¿Rompi algo en mi aplicación? Salgamos de aquí, deshagámonos de esto. Intentemos esto de nuevo rápidamente, una vez más. Entonces hay otra pregunta que Tahir está haciendo, qué grandes empresas están utilizando esta tecnología. Así que, de hecho, tengo una diapositiva para eso. Tengo una diapositiva. Tenemos muchas empresas importantes. Esto cambia constantemente. Burger King, Blue Cross, Blue Shield, BBC, IBM. Muchas grandes empresas están utilizando esto. Creo que incluso, creo que Target también lo está utilizando. La documentación de capacitor tendría una sección completa sobre qué empresas están utilizando esto. Veamos qué tenemos aquí. No sé por qué no está funcionando. Configuraciones. Debería poder ver el uso y todo. Veamos el tamaño de la aplicación. No, no me dará el tamaño aquí en el simulador. El tamaño promedio probablemente esté en algún lugar entre 80 megabytes o menos.

Muchas áreas donde esto podría cambiar son qué dependencias estás incluyendo, qué activos web estás incluyendo, ¿estás solicitando cosas desde un servidor o las estás solicitando o incluyendo localmente? Si estás incluyendo una gran cantidad de videos o algo así, eso podría aumentar el tamaño total de la aplicación. Pero la mayoría de las aplicaciones son bastante pequeñas en realidad.

No recuerdo dónde puedo encontrar el uso de esto, así que no tengo un número real que pueda darte.

Naveed, ¿cuáles son las limitaciones de Capacitor en comparación con una aplicación nativa? Es una muy buena pregunta. Diría que las limitaciones reales probablemente estarán en los gráficos intensivos en 3D. Eso no es específico de Capacitor, creo que es una comparación general con la web. Las aplicaciones nativas tienen API altamente optimizadas para manejar gráficos en 3D, crear gráficos en 3D, la web no tiene eso. Probablemente una mejor solución sería usar algo nativo en ese sentido, pero podrías usar Unity en ese caso, que está altamente optimizado para gráficos en 3D multiplataforma. De lo contrario, piensa en las aplicaciones que usas hoy en día que probablemente sean solo listas y desplazadores mejorados. Puedes reconstruir eso en la web sin problemas.

Si quieres obtener más información, porque básicamente estoy en el tiempo de la masterclass, pero tenemos el sitio web de CapacitorJS al que puedes unirte. Tenemos nuestra documentación dedicada que puedes usar aquí, y luego esta organización de la comunidad de Capacitor en GitHub, que tiene una gran cantidad de complementos diferentes, como mencioné. Eliminaremos la consulta para esto primero. No sé por qué todavía está ahí arriba. ¿Cuántos complementos hay? Sí, tenemos cosas para seleccionar fechas e integrar Intercom, integrar Twitter, Twitter Kit, no tenía idea de que eso existía, inicio de sesión de Facebook, básicamente hemos cubierto todos los casos de uso que desearías para desarrollar una aplicación y acceder a APIs de terceros. SQLite es uno bastante interesante que la gente usa con frecuencia. Entonces, si hay algo ahí que quieras probar, probablemente tengamos una API para eso. Creo que estoy en el tiempo y todo para la presentación. Si quieres contactarme, puedes enviarme un tweet.