Llevando tu aplicación web a nativa con Capacitor

Vamos a hablar sobre cómo llevar una aplicación web a nativa utilizando Capacitor. Mi nombre es Blake Hardington. Puedes encontrarme prácticamente en todas partes en línea como mhardington. Twitter como mhartington, blue sky como mhartington, Mastodon como mhartington. Una vez que tienes un nombre, simplemente te aferras a él y la gente te seguirá a donde vayas. Asegurémonos de que todos estén al tanto. Habrá preguntas y respuestas, publicaciones en el chat, cualquier pregunta en el chat o en el canal de Discord. Hay una sala de Discord para todos los talleres, así que podré responder cualquier pregunta después y también proporcionar la demostración que usamos aquí, para que puedas ver el código fuente de lo que construimos. Esto será grabado. Como asistentes, creo que tendrán acceso a la grabación después, así que si hay algo que se hayan perdido o crean que se perdieron o simplemente quieran aclarar algo, siempre pueden volver y verlo. Si sienten que voy un poco rápido y piensan `oh, veré la repetición o simplemente escucharé, no hay problema, está totalmente bien.

Para comenzar, vamos a ver qué es exactamente el desarrollo multiplataforma. Es un término muy cargado que ha existido durante muchos años, principalmente proveniente de la industria de los videojuegos, donde las personas construían bibliotecas completas y SDKs para poder llevar un videojuego escrito específicamente para, digamos, PlayStation, y luego poder portarlo a diferentes entornos para tener juegos compatibles con Xbox, PlayStation, Steam, entre otros.

Todas estas herramientas existen para que los desarrolladores de videojuegos puedan centrarse en construir el mejor juego posible, sin necesidad de preocuparse por cómo hacer que su videojuego funcione en diferentes hardware. Ahora, el mundo web y nativo también han adoptado el enfoque multiplataforma, pero creo que aún comparten algunos objetivos comunes con la industria de los videojuegos en el sentido de que el objetivo es reducir la cantidad de conocimientos necesarios para comenzar. Un desarrollador web no debería tener que conocer todos los detalles sobre un entorno en particular, solo debe saber que tiene estas guías y todo lo que está dentro de ellas está ahí para ayudarlo a seguir el mejor camino posible, y limitar lo que necesita preocuparse. No necesita preocuparse por la infraestructura subyacente, no necesita preocuparse por el entorno de ejecución subyacente. Sabe lo que sabe y puede lanzar algo. También reducen la cantidad de código que se necesita escribir. No significa que el código se haya eliminado, simplemente significa que la cantidad de código que uno debe mantener y escribir puede reducirse. Entonces, aunque todos podemos acceder a cosas como la cámara, la geolocalización, el Bluetooth, la forma en que se hace puede simplificarse y abstraerse de manera que funcione en todas esas diferentes plataformas. Y obviamente, al hacer las cosas de manera multiplataforma, se reduce el tiempo que se tarda en lanzar algo, de modo que no pasamos todo nuestro tiempo probando en múltiples entornos, implementando características múltiples en diferentes aplicaciones y entornos de ejecución. Esto solo se hace una vez y luego está disponible en todas las otras plataformas que queremos soportar.

Así que voy a hacer un poco de historia porque me gusta la historia. Creo que ayuda a mostrar el camino hasta donde estamos ahora. Pero vamos a ver el ecosistema de herramientas en este ecosistema multiplataforma. Y vamos a tratar de comparar cómo difieren y cómo nos llevaron a donde estamos hoy. Probablemente la implementación original, hasta donde puedo decir, es Cordova, si has oído hablar de eso. Probablemente sea PhoneGap, y es posible que no tengas una gran... Opinión al respecto. Eso es bastante común. Pero fue uno de los pioneros. Básicamente fue el primer enfoque que decía vamos a tener una aplicación que puedas ejecutar, escribir una vez y ejecutar en cualquier lugar.

Ahora, la historia divertida detrás de Cordova es que se suponía que era un truco y una forma de obtener una aplicación en las plataformas nativas como un polyfill. Eventualmente, dejó de existir porque los desarrolladores no querían realmente mantener este proyecto. En realidad, no querían construirlo desde el principio, pero como en ese momento la web no tenía todas las características que conocemos y amamos hoy, tuvieron que construir esto. Tenían planeado proporcionar algunos comentarios a los proveedores de navegadores e implementadores de especificaciones web para que estas características se agregaran al navegador y eventualmente desaparecieran. Pero lo que hicieron fue actuar como un puente hacia el entorno nativo a través del navegador, teniendo un pequeño puente nativo dentro de su aplicación. Entonces, tomarías una aplicación web, la envolverías en un entorno de ejecución de Cordova. El entorno de ejecución se encargaría de interceptar las llamadas que el usuario estaba haciendo, pasar esas llamadas al entorno de ejecución nativo, devolver esas llamadas nuevamente y luego serializarlo de nuevo a la aplicación web. Así es como obtuvimos cosas como esta. Veo esto y me estremezco un poco porque es un ejemplo muy antiguo, pero proporcionó un buen patrón sobre cómo los autores de complementos y módulos deberían escribir su código. Tenemos esta cosa llamada Navigator, que es global, y luego tenemos una cámara y luego tenemos una API para obtener una imagen. Esto fue un prototipo sobre cómo llamar a la actividad de la cámara, mostrar una superposición, obtener una foto, y luego podíamos manejar el envío de esos datos de vuelta a la aplicación web. El único problema es que esto no existe en ningún otro lugar de la web. Todo esto es específico de Cordova. Si miramos lo que tenemos ahora para obtener una foto, esto no se tradujo bien. Pero Cordova tenía un problema en el que no podían cambiar nada de esto, porque había personas que mantenían aplicaciones que esperaban que esto funcionara. Así que se quedaron con ello. Tenemos cosas como la cámara que no existe como global, esta calidad, este tipo de destino, ninguna de estas cosas llegó a la web. Y así, su misión fracasó a medida que avanzaban. Construyeron todos estos complementos y nunca los adaptaron a los estándares web en evolución. Ahora, la API de la cámara es solo una implementación. Hubo docenas más proporcionadas por el equipo principal. Y luego este ecosistema bastante grande de autores de complementos que agregarían API adicionales que simplemente podías instalar y agregar a tu proyecto. Ahora, cuando los agregas a tu proyecto, dependiendo de cuándo lo hiciste, tenías que descargar este archivo zip, agregar estos archivos a este directorio y cruzar los dedos y esperar que todo saliera bien. Estos paquetes existían en una época anterior a NPM, lo cual es difícil de creer. Cordova es tan antiguo. NPM finalmente llegó y finalmente pudieron agregar soporte para él, pero aún lo hicieron de una manera muy regular. Muchos de los paquetes que agregaron básicamente usaban NPM y luego tenían un conjunto complejo de scripts que hacían que funcionara con su infraestructura existente porque nadie quería alterar demasiado lo que se esperaba. Y luego, si realmente quieres construir tu aplicación y luego lanzarla a las tiendas, había un conjunto de scripts complejos y a veces en máquinas Mac y Linux tenías un montón de scripts por lotes en Windows, estabas obteniendo algunas ejecuciones por lotes.

Ahora, lo interesante de Cordova, y algunas cosas que creo que tenían que eran bastante interesantes, era, una vez más, la web era su objetivo principal. Querían ser un gran polyfill para cerrar la brecha en lo que el navegador estaba haciendo. La brecha entre lo que el navegador podía hacer y lo que podía hacer el nativo. Realmente no querían que la gente conociera un IDE nativo, lo cual, como alguien que es principalmente desarrollador web, cada vez que tengo que abrir Android Studio, me asusto un poco porque Android Studio es muy complejo. Lo mismo ocurre con Xcode. Puede ser una herramienta muy compleja y confusa, así que creo que tener la idea de abstraer eso fue un buen intento y un buen objetivo, pero la implementación dejó mucho que desear. Y luego los proyectos nativos tienen un objetivo DIST, lo que significa que tu proyecto nativo debería ser algo que se pueda configurar a través de herramientas y luego, si por alguna razón lo subes al control de versiones y luego tu compañero de trabajo tiene que clonarlo y configurarlo nuevamente, deberían poder seguir los mismos pasos y obtener las mismas características y habilitaciones, como acceder al sistema de archivos y la cámara, eso debería ser scriptable. Qué tan exitosos fueron en eso depende pero fue una idea interesante en ese momento. Pero definitivamente, en retrospectiva, es un poco obvio que esto definitivamente no funcionó al 100% bien, pero en ese momento era lo mejor que probablemente teníamos.

Ahora, en el otro extremo de ese espectro donde tenemos a PhoneGap a un paso de desarrollo web, ¿qué está un paso alejado del desarrollo nativo puro? Y eso es compilar a nativo, tus aplicaciones React nativas, por así decirlo, donde tienen un runtime de JavaScript, o un runtime en otro lenguaje. Y luego van y abstraen los controles, te proporcionan un widget o algo que puedes usar en lugar de eso que aísla la diferencia entre cómo se ve el texto en iOS y cómo se ve el texto en Android. Ahora esto es algo que es un punto de... Es un punto muy controvertido donde dicen que es una aplicación verdaderamente nativa. Pero todavía hay un runtime de JavaScript en la mayoría de estos y específicamente nos centraremos en React Native. Todavía hay un runtime de JavaScript ahí que ejecuta todo tu código. Cualquier lógica de tu aplicación que escribas en JavaScript se ejecutará y debe ejecutarse. Entonces, lo nativo verdadero es... Depende de cómo lo veas. Es posible que obtengas controles nativos, pero los controles nativos no son realmente lo más importante. Lo más importante es el código de la aplicación que estás escribiendo para realizar solicitudes, para manejar el estado dentro de tu aplicación. La interfaz de usuario es solo un detalle secundario, en mi opinión. Algo que hicieron bien, y que realmente creo que es un buen movimiento por su parte, es tener una biblioteca estándar alrededor de algunas de estas API nativas. Entonces, React Native proporciona una biblioteca central en la que el ecosistema ha podido construir y que puedes usar para construir y expandir. Pero la mayoría de esas API existen y están disponibles sin que tengas que instalar algo como Expo.

Ahora, oh, esta diapositiva estaba un poco desalineada. Ahora, lo que me gusta asegurarme de que las personas sean conscientes es que arquitecturalmente, React Native y otros proyectos similares son muy similares a Cordova. Donde tienes tu aplicación representada en este cuadro azul, tienes este runtime, que es, en el ejemplo de React Native, vajscore, también tienen algunos personalizados que ejecutan tu aplicación y luego toman las llamadas dentro de tu JavaScript y luego las vinculan con los módulos nativos y las pasan a este puente que llama a esas características, serializa esos resultados, y los devuelve a tu JavaScript. Este mismo flujo de trabajo existe básicamente en todas las soluciones hoy en día. Realmente no hay forma de evitarlo. Así es como funciona Cordova, así es como funciona React Native. Y como veremos, no están solos.

Ahora, no soy necesariamente alguien que hace React Native a diario, así que no voy a intentar mostrar algo de código, pero diré que, en las demos que he construido con React Native, donde se desmorona es tener que entender que no estás necesariamente trabajando en web pura o nativa pura. Por ejemplo, si estás en un entorno nativo puro, es posible que estés acostumbrado a tener acceso directo a las API. Con React Native, lo más probable es que estés construyendo un módulo nativo, que tiene sus propios pasos para exponer esas API de bajo nivel a tu JavaScript. O si estás tratando de obtener acceso directo a él, estás mezclando React Native en una aplicación nativa existente. Y luego estás en este lugar extraño, ¿qué aplicación se está ejecutando? ¿Qué procesos están ocurriendo? Es un lugar muy extraño en el que participar. Si vienes de una aplicación web, o ya tienes una aplicación web existente, y quieres usar algo como React Native, ahí estás un poco fuera de suerte, porque aunque existen bibliotecas como React Native DOM, React Native web, no estás cargando tu aplicación web existente y cargándola allí. Estás reescribiendo tu aplicación para asegurarte de que funcione en esas abstracciones, en primer lugar, y luego esperas poder volver a implementar lo que hace tu aplicación web existente dentro de React Native. Qué tan exitoso sea eso realmente depende del poder de ingeniería y de cuántas horas estás dispuesto a invertir en ello. Creo que es menos exitoso de lo que la gente intenta hacer creer. Hay mucho trabajo que se necesita para poner en marcha React Native web. E incluso entonces, si dependes de ciertas bibliotecas, como una, por ejemplo, llamada Quill.js, es uno de mis complementos favoritos de editor de texto enriquecido, no existe en el ecosistema de React Native. Entonces no puedes simplemente usarlo allí y agregarlo a tu aplicación de React Native. Tienes que volver a implementarlo. Deja mucho que desear.

Y luego esa cosa verdaderamente nativa, es bonita, es bastante engañosa. Así que cambiaré a quién estoy criticando por un momento. Y me referiré a algo como Flutter, que es algo que está aumentando mucho en popularidad. Donde la gente piensa que Flutter les está dando una aplicación verdaderamente nativa, no entienden del todo que Flutter en sí es básicamente un motor de renderizado. Estás renderizando cosas en, en este caso, un lienzo gigante. Así que todos tus botones, y todas tus barras de herramientas, y todos tus encabezados, esos no son controles nativos. Ni siquiera son controles web. Son lienzos gigantes que se renderizan en Android nativo, iOS nativo, e incluso en la web, lo cual es cuestionable. Si estuvieras haciendo cosas con auditorías de accessibility, hay mucho trabajo por hacer para asegurarte de que tu aplicación sea accesible. De lo contrario, al menos aquí en los Estados Unidos, podrías ser demandado. El cumplimiento AA es realmente bueno. El cumplimiento AAA es casi imposible. Con estas herramientas, no llegarás ni cerca de eso. Todos esos controles se renderizan sobre la marcha. Entonces, si estás realizando muchas operaciones complejas, es probable que introduzcas cierta lentitud que ralentizará por completo el proceso de renderizado. Lo he experimentado con Flutter, principalmente porque no sé lo que estoy haciendo, pero es probable que si te adentras en un nuevo runtime en un nuevo lenguaje, te encuentres con esos cuellos de botella, principalmente debido a la falta de experiencia o la falta de comprensión de cómo funciona este runtime completamente nuevo. Ahora, podrías solucionarlo simplemente pasando más tiempo con él, pero no debería ser un problema. Entonces, aquí es donde llegamos a Capacitor, que es una de mis cosas favoritas. Capacitor, creo que se encuentra en el punto medio agradable entre una aplicación nativa pura y tener acceso a lo nativo puro pero al mismo tiempo seguir siendo puramente web.

Entonces, ah, el modo oscuro, vamos a empezar con eso. Capacitor en sí mismo, en su definición más simple, es un proyecto de dos partes. Hay un tiempo de ejecución nativo y una biblioteca nativa que se agrega para exponer las API nativas a través de JavaScript. Y luego hay una biblioteca de JavaScript que publicará llamadas desde una aplicación web. De esa manera, el tiempo de ejecución nativo puede escucharlo y luego aceptar la respuesta. Las propias API están separadas y tienen diferentes implementaciones para el tiempo de ejecución. Por ejemplo, hay una cámara, hay una parte nativa en iOS, hay una parte nativa en Android, y hay una parte para la web, pero todas esas API están abstraídas en una capa delgada con la que nosotros, los desarrolladores, interactuamos. Así que no necesito saber si estoy llamando a la cámara en iOS o si estoy llamando a la cámara en Android. Solo necesito saber que estoy llamando a la cámara y debido a la forma en que está configurado, se saltará muchos condicionales y automáticamente irá a la plataforma en la que se está ejecutando, lo que hace que sea mucho más rápido que las soluciones anteriores. Si estás manejando compilaciones, gestión de paquetes, todas estas cosas para las que, por ejemplo, Cordova escribió herramientas personalizadas, nos deshacemos de eso y básicamente te damos toda la potencia del ecosistema necesario. Entonces, en Android, estamos utilizando bibliotecas de Android para publicar todos nuestros tiempos de ejecución nativos y en iOS, estamos utilizando CocoaPods en este momento para asegurarnos de que puedas tener todas esas dependencias versionadas y gestionadas de forma natural. También hay algunas cosas interesantes con NPM donde, al instalar un complemento, todo el código fuente se envía a través de NPM y luego automáticamente podemos vincularlo a tus proyectos nativos sin tener que realizar un paso adicional. Y podemos ver cómo se ve eso en un momento. Así que arquitectónicamente, esto es muy similar a React Native y Cordova, donde tienes tu aplicación web. Se está representando en una vista web de capacitor pero esto no es como la lógica de Cordova de la vieja escuela. Esta es una vista web muy mejorada que es más rápida de lo que una aplicación Cordova podría ser debido a la forma en que está diseñada. Accederá automáticamente a esas API nativas y luego tu aplicación web puede tener acceso a las funciones del sistema de archivos tan pronto como se lance la aplicación nativa y tu aplicación web esté lista para funcionar. Si estás familiarizado con Cordova, hay algo llamado `device ready`. Eso no existe aquí en Cordova Capacitor, pero es prácticamente lo mismo que en React Native y Cordova. Se serializan los resultados de las funciones nativas y luego se devuelven como JSON para que puedas cargarlos y trabajar con los datos que recibes de ellos. ¿En qué se diferencia eso? Básicamente, puedes simplemente agregar una aplicación web dentro de una aplicación nativa y listo. No se necesita ninguna magia especial. Eres libre de cualquier truco. El tiempo de ejecución está disponible al instante para que pueda llamar automáticamente a esas funciones. Y algo que no tengo aquí pero que también es muy cierto es que puedes descender al nivel nativo si es necesario y aún tener acceso completo a las API de Capacitor. Así que vamos a pasar a mi terminal. Y aquí tengo una aplicación React muy sencilla que creé utilizando las herramientas de Veet. Si quieres seguir, simplemente ejecuté npm create Veet en la última versión y luego elegí React y estoy usando principalmente TypeScript porque el IntelliSense tiene sentido para nuestro taller.

Si no quieres usar TypeScript, eso depende totalmente de ti, aún funcionará sin él. Pero yo seguiré adelante. Voy a inicializar un nuevo proyecto. Mira, en ello para ganar. De acuerdo. Y luego voy a hacer create, git push work en main. Y luego navegar. Y luego voy a dejar esto aquí en los chats. Si quieres el enlace al principio y luego también voy a dejar esto. Lo dejaré al final de todo en Discord si quieres, así puedes tener acceso a él.

Así que voy a abrir una nueva terminal muy rápido para poder instalar algunas dependencias. Así que en realidad echemos un vistazo rápido al proyecto en sí. Es una demostración muy básica de React y Vite. Si nunca has usado Vite antes, es básicamente mejor que todo lo demás, mejor que Webpack, mejor que cualquier otra herramienta personalizada con la que haya trabajado, realmente me gusta mucho. Recomiendo encarecidamente que te subas a ese tren. Pero lo que tenemos aquí es solo tu proyecto estándar de React. Está representando nuestra aplicación. Estamos en modo estricto. Tenemos nuestros componentes. Podemos ir al archivo real. No tengo nada instalado. Puedes ver que solo estamos cargando el estándar tipo de Hola Mundo con un poco de estado que podemos usar aquí. Así que sigamos adelante y, en primer lugar, ejecutemos install para poner todo en marcha. Otro beneficio de Vite es que no tiene tantas dependencias. Así que si esto fuera create React app y React scripts, la instalación no llevaría ocho segundos. Pero lo que vamos a hacer con esto es que vamos a instalar Capacitor core y luego Capacitor CLI. Estas dos dependencias aquí serán nuestra forma principal de interactuar con Capacitor. El CLI será nuestra herramienta que expone un CLI específico del proyecto. Entonces, si estás en una versión de Capacitor en un proyecto y otra versión en otro proyecto, no tienes que preocuparte por tener una instalación global que pueda romperse entre diferentes versiones, una solución realmente simple para un problema bastante común en Cordova. Así que vamos a dejar que esto se instale rápidamente. Esperemos que no tarde mucho. Ahí vamos. Y luego vamos a inicializar Capacitor. Para hacer eso, ejecutaremos mpx cap init. Mpx es básicamente, si no estás familiarizado, es el comando local de MPM, intenta local primero, si no, tendremos que ir al registro. Pero como es local, estaremos bien. Entonces, nuestra aplicación es JS... Sí, esto es JSNation. Aquí, sí, JSNation. No Narshin, JSNation. Ese será el nombre de la aplicación que se mostrará a todos. Nuestro ID de paquete será algo específico de nuestro proyecto en particular. Generalmente, esto se convierte en un problema cuando tienes certificados que estás usando para firmar y publicar tu aplicación. Lo dejaremos como com.example.app porque estaremos bien sin él. Y luego hay una especie de Get Started Next donde podemos seguir adelante y te pedimos que crees una cuenta gratuita. No es necesario. Me gustaría que lo hicieras, pero no es necesario así que seleccionaremos No. Y vamos a seguir adelante y dejar que se ejecute. Así que veamos cuál es la diferencia aquí. Obviamente, PackageLoc y PackageJSON son diferentes pero también tenemos este CapacitorConfig.ts.

Ahora, en cualquier momento, si quisiéramos hacer este cambio antes de agregar nuestros proyectos necesarios, digamos por ejemplo que queremos incluir un espacio aquí, podríamos hacerlo. Pero esta configuración se lee y se utiliza para crear valores iniciales para nuestros proyectos nativos, que veremos en un momento, pero por ahora podemos saber que tomará todo de WebDir de dist, el nombre de la aplicación es JS Nation, y luego el ID de la aplicación o el identificador del paquete es com.example.app. No es gran cosa.

Ahora vamos a ejecutar dev. Y luego vamos a abrir nuestro app.tsx, y luego lo abriré en mi navegador, abriré las herramientas de desarrollo, y vamos a hacer un poco de gestión de ventanas rápida. Y vamos a hacer zoom rápidamente. Ahora, dentro de aquí, vamos a importar desde Capacitor Core y ver qué tenemos. Así que Capacitor Core proporciona muchas características comunes que vas a exponer. Una de ellas es esta clase Core Capacitor, que podemos usar para interactuar con las API de Core Capacitor. Pero el resto de estos son más para establecer cosas como plugins, establecer diferentes valores si estás en la cloud, diferentes valores si eres un autor de plugins. No necesariamente tienes que preocuparte mucho por ellos. Lo más probable es que nunca tengas que tocarlos, pero este Core Capacitor es algo que realmente usaremos. Así que vamos a crear un callback de UseEffect, le pasaré un array vacío, y luego simplemente diremos Console.log Capacitor. Hablar y escribir al mismo tiempo, mucho más difícil de lo que piensas. Voy a mover esto rápidamente y luego vamos a guardar. Ahora, tenemos todo lo que deberíamos esperar recibir. Capacitor en sí está disponible en este proyecto aunque estemos dentro de nuestra aplicación web. Si queremos, podemos ver algunas de las cosas que tenemos aquí. Obtenemos que esta es la plataforma web. Cualquier plugin que esté registrado con una extensión de archivo .web.ts estará disponible y se cargará aquí. Hay muchas otras cosas que puedes ver si estuviéramos en la situación en la que necesitáramos verificar primero antes de hacer algo y quisiéramos tener una llamada a FaceID y no hay ejemplo de eso en tu teléfono. Bueno, podrías hacer una pequeña verificación diciendo, hey, capacitor.isNative, callFaceID, o biometricsAuthentication si no, hacer algo más. Hay algunas utilidades interesantes aquí. Hay esta función platform donde podemos averiguar en qué plataforma estamos. Eso simplemente va a devolver esta cadena de plataforma. Cosas bastante interesantes que tenemos aquí. Vamos a ejecutar esto rápidamente en iOS. En realidad, ahora no vamos a ejecutar esto en iOS todavía. Vamos a agregar un plugin aquí, para que podamos ver cómo funciona. Voy a detener el servidor de desarrollo por ahora porque no sé cómo V manejará la modificación de mis módulos de nodo. Pero voy a instalar la API de geolocalización de ATCapacitor. Ahora, la geolocalización es interesante porque hay una API de geolocalización basada en el navegador, Navigator.Geolocation, que es algo que proviene de Cordova. Es uno de sus pocos éxitos, pero existe. Con la API de geolocalización, obtenemos una forma muy sencilla de obtener la ubicación que se traduce bien entre estas múltiples plataformas. Vamos a importar desde capacitor geolocation, y vamos a traer la API de geolocalización. Ahora, vamos a lanzar eso en nuestro console.log solo para que podamos inspeccionar las cosas antes de llamar a esa API. Ahora, la geolocalización está devolviendo un proxy aquí, que es lo que queremos que haga. Porque esta API está actuando como un intermediario, no necesitamos que devuelva nada de inmediato. Esta API es solo nuestro, si lo pensáramos en términos de clases, esta es nuestra clase abstracta que estamos llamando. Todo lo demás que estamos implementando en las plataformas nativas termina extendiendo esta clase abstracta o implementando la clase abstracta. Vamos a hacer Geolocation.RequestPermissions. Ahora vamos a inspeccionar qué hace esto. La solicitud de permisos de ubicación lanzará una excepción si los servicios de ubicación del sistema están desactivados. Podemos ver que esto es una promesa, así que sabemos que va a ser una operación síncrona, lo cual es genial. Vamos. Genial. Rechazo de promesa no manejado no implementado en la web, pero la aplicación sigue funcionando, todo funciona como se esperaba. Solo sabemos que Location.RequestPermissions es algo específico de la plataforma. Esto es muy común en Capacitor. Ciertas API estarán disponibles en ciertas plataformas que tienen ese modelo correcto.

Cualquier cosa que requiera un permiso estará disponible, o las solicitudes explícitas de permiso solo estarán disponibles en ciertas plataformas. Luego podemos simplemente lanzar una promesa rechazada cuando esa función no esté implementada. Dije, la mayoría de esto implicará solicitar permiso en plataformas nativas. La web no tiene una solicitud de permiso anticipada o una solicitud de permiso. Es un modelo justo a tiempo. Podemos comentar eso porque sabemos que no lo necesitaremos.

Vamos a decir que const getLock es igual a una función asíncrona. Haremos funciones de error hoy. Aquí, podemos decir que const lock es igual a await geolocation.getCurrentLocation. Voy a hacer esto un poco más grande para que sea más fácil de ver. Podemos ver que lock va a devolver una posición. De hecho, podemos desestructurar esto rápidamente porque sé que también va a devolver este campo de coordenadas. Una vez que tengamos esas coordenadas, vamos a decir setLock. Luego, vamos a establecerLat igual a hacia.Latitud.

Ahora, antes de continuar, quiero ver algunas de estas cosas. Tenemos latitud y longitud. Las API web las devolverán. Esas son cosas que tenemos disponibles independientemente de la plataforma. Ahora, los otros, velocidad, rumbo, altitud y precisión de altitud. Observa que también devuelven null o undefined. Básicamente, estos valores son opcionales, lo que significa que algunas plataformas los devolverán y otras no. La web no devolverá ninguno de estos. La web solo devuelve algunos valores. Principalmente longitud, latitud y creo que precisión, que es todo lo que la web realmente dará, principalmente debido a preocupaciones de privacidad. Pero para servicios de ubicación de mayor fidelidad que son proporcionados por los entornos nativos, eso se te dará y es posible que desees tener acceso a eso. Puedes usar cosas como comprobaciones condicionales para decir, hey, si esto está disponible, muéstralo por alguna razón o úsalo en tu aplicación. Un momento, por favor. Vamos a establecer la latitud en quads.lat y tendremos uno llamado launch, que será quads.launch, y haremos una implementación rápida aquí, decir const lock y luego establecer lock. Se utilizará states y lo dejaremos así y deberíamos estar bien aquí. Bajaremos a esta tarjeta aquí.

Solo para asegurarnos de que estamos en el lugar correcto, tenemos una tarjeta y podemos ver que el recuento es ese. Creemos otro botón aquí y al hacer clic, simplemente llamaremos a get lock, y luego lock es lock. Veamos qué obtenemos. Veamos, let es null, long es null y luego a veces cuando usas TypeScript, sientes que tienes que hacer más trabajo del que realmente deberías, pero en su mayor parte debería valer la pena.

De acuerdo. ¿Por qué sigue quejándose? Ah. Eso es algo que no he visto antes. Interesante. Vamos a seguir adelante y en lugar de renderizar eso, vamos a console.log estas coordenadas primero. Si sabes por qué es un problema, lo revisaremos más tarde. Digamos simplemente get lock. Vamos a eliminar esos errores aleatorios y digamos simplemente get lock. Ahora, aquí es donde no necesitamos obtener permiso de solicitud de permiso del navegador de antemano. El navegador ya tiene su propio mecanismo que se realiza en la llamada. Diremos permitir esto y luego puedes ver que obtenemos todos esos datos de geolocalización de nuestra aplicación. Así que podemos echar un vistazo a esto, puedes ver nuestra latitud y longitud, podemos ver la precisión y luego todos esos valores opcionales que podrían devolverse, vamos a devolver null porque no es necesario implementarlos.

Disculpa, vuelvo enseguida, solo voy a tomar un vaso de agua porque tengo la garganta un poco seca, y regresaré. Si tienes alguna pregunta hasta ahora, por favor ponla en el chat, y luego puedo volver y echar un vistazo a algunas de ellas. Solo un momento, por favor. Bien, disculpa por eso, son alergias, no son divertidas. Estoy muy celoso de aquellos que no tienen alergias. Como decía, podemos ver todos los valores que no están disponibles en la plataforma, así que como autores de complementos, en realidad puedes marcarlos como opcionales. Como consumidores de ese complemento, podemos programar en torno a eso de una manera segura en cuanto a tipos. Por ejemplo, podemos usar nullish-coalescing. Podemos usar doble interrogación, o también podemos usar optional chaining si queremos. Sigamos adelante e intentemos hacer esto de nuevo y averiguar simplemente cambiemos esto por... Número o null... número o null, ¿eso lo arregla? Huh. Intentemos esto. Sigamos adelante y digamos Ustate, será 0. Y luego, tendremos otro UState. Y de esa manera, no tenemos que... Porque era un objeto. Eso explica por qué. Bien, ahora que realmente sé lo que estoy haciendo. Simplemente cambiaremos esto para que sea JSON.stringifyLoc. Es solo un pequeño truco. Si alguna vez quieres formatear las cosas correctamente, usa los otros valores en JSON.stringifyLoc, usa null y 2. Eso devolverá los formatos de valor correctos. Ahora puedes ver que se devuelve nuestra ubicación. Podemos obtener esos valores. Podemos mostrarlos dentro de nuestra aplicación, lo cual es muy fácil una vez que nos damos cuenta de que estamos haciendo esto usando JSON.stringifyLoc en lugar de tener que hacer algo más. Vamos a mover eso a su propia cosa. Nuestra latitud y longitud se ven bien. Vamos a agregar esto y hacer algo con la plataforma nativa. Como dije, vamos a detener nuestro servidor de desarrollo e instalar una plataforma nativa. Al igual que la geolocalización es su propio paquete separado, las plataformas nativas también son su propio paquete separado. Así que vamos a instalar capacitor. Vamos a instalar iOS. Esto es algo aparte.

Se gestionan sus propias dependencias. Una vez que lo hayamos instalado, podemos ejecutar npx cap add iOS. En versiones anteriores, habíamos hecho que cap add instalara la dependencia si era necesario. Hacerlo después es más sencillo de mantener. La única razón por la que menciono esto es porque la gente lo ha preguntado antes. Es más fácil mantenerlo si instalas el paquete tú mismo. Además, no necesitamos adivinar qué gestor de paquetes estás usando.

Como yarn era muy popular en ese momento, ahora tenemos cosas como pnpm. Solo instálalo tú mismo y encontraremos el binario nativo. Podemos ver que se ha creado el proyecto nativo. Sin embargo, tenemos una advertencia aquí. Este paso de sincronización no se pudo ejecutar porque falta nuestro directorio dist. Este paso de sincronización es cómo mantenemos nuestro proyecto nativo sincronizado con nuestros proyectos web, como su nombre indica. Podemos ver el flujo de trabajo de cómo debería funcionar dentro de la salida. Podemos ver que deberíamos compilar el código web y luego sincronizar el proyecto con nuestra aplicación nativa y luego ejecutarlo en nuestro simulador o dispositivo nativo.

Vamos a hacer una compilación rápida. Haremos build. Vamos a corregir eso rápidamente porque me molestará. Genial, y luego podemos ejecutar npm cap sync ios. Hace un poco más que simplemente copiar los activos web. Así que vio que teníamos capacitor geolocalización como una dependencia nativa. Y lo que hizo fue buscar todas las otras dependencias en las que ese complemento podría depender. Por ejemplo, como autor de un complemento, podrías depender de algo de Firebase. Podrías depender de algo de Revenue Cap. Depender de muchos paquetes de terceros. Pero podemos declararlos dentro de nuestro archivo pod y saber que CocoaPods se encargará de incluirlos, en lugar de tener que buscar formas de agregarlos a nuestro proyecto. Eso ya es muy bueno. Ahora vamos a ejecutar el comando open, que abrirá nuestro IDE nativo. Ahora, si tienes miedo de Xcode, no te preocupes. Es como iTunes pero para aplicaciones nativas. Podemos ver una estructura rápida aquí. No sé si puedo hacer que la interfaz de usuario sea un poco más grande. No voy a intentarlo ahora, pero veamos si puedo. No puedo. Bien, así que tendremos que esperar a que puedas ver esto muy bien. Pero tenemos este directorio de la aplicación, que es nuestro proyecto de la aplicación, que contendrá todas las capacidades de firma. Lo haré rápidamente porque necesitará hacerlo, y dejaremos que Xcode se encargue de crear todos estos certificados por nosotros en lugar de tener que hacerlo nosotros mismos. Tenemos nuestros objetivos mínimos de implementación, que es iOS 13. Tenemos nuestra categoría, por lo que si queremos adelantarnos y averiguar cómo queremos publicar esto. Tenemos todos nuestros análisis de búsqueda, nuestras orientaciones admitidas, nuestras orientaciones admitidas en iPad y luego el estilo de la barra de estado. Todas estas cosas básicamente determinan cómo debe aparecer y comportarse nuestra aplicación para el usuario. Estas deben estar configuradas. Luego tenemos esta carpeta de la aplicación donde tenemos nuestra Configuración de Capacitor ahora convertida a JSON. Y luego tenemos este delegado de la aplicación. Ahora, vamos a hacer esto un poco más grande, y creo que este tiene modos grandes. De esa manera puedes leer esto un poco más fácilmente. Pero puedes ver que tenemos código Swift real aquí dentro de nuestra aplicación. Este código Swift básicamente instancia nuestra parte nativa de la aplicación.

La aplicación ingresó al segundo plano, volverá al primer plano y se activará. Luego tenemos este otro en el que la aplicación recibió... Veamos. Hay uno aquí cuando... Notificaciones, pero creo que se ha movido. Podemos ver cuando la aplicación se ha lanzado a través de una URL específica de la aplicación. Básicamente, cualquier tipo de gancho de vida en el que queramos engancharnos aquí, podemos hacerlo. Tenemos nuestro storyboard principal, que mostrará el controlador real y el puente que vamos a instanciar. Puedes ver cómo esto se conecta a la aplicación nativa. Tenemos nuestros activos, como la pantalla de inicio y los iconos, nuestro controlador de vista, nuestro controlador de storyboard, por lo que si queremos tener un fondo completamente diferente para el modo oscuro o si queremos personalizar cómo se presenta la imagen de inicio, podemos hacerlo. Info.plist es algo de lo que debemos hablar. Ahora, como dije aquí, dentro de las herramientas de desarrollo, cuando intentamos llamar a un permiso de solicitud, obtuvimos un error. Básicamente, significa que no teníamos permiso o no teníamos una API de permisos, lo cual es totalmente esperado debido al navegador, como dije. Pero los tiempos de ejecución nativos reales tienen una API de permisos realmente buena. Algunos de ellos son bastante oscuros. Voy a mostrarte un pequeño secreto. Si vamos a la documentación de Capacitor para todos los complementos principales, puedes ver la lista de todos los complementos principales que tenemos y que admitimos. Pero estamos viendo la geolocalización, y podemos ver que tenemos un conjunto de permisos que debemos agregar para que nuestra aplicación pueda usar la geolocalización. Así que vamos a agregar una fila, y será NS location always usage description. En realidad, vamos a usar location always usage y ver si podemos encontrar eso rápidamente. Debería estar bajo el encabezado de privacidad, y luego podemos desplazarnos hacia abajo y tener la descripción de uso siempre, y luego vamos a agregar uno más, y eso será privacy location when in usage description. Así que tenemos dos descriptores diferentes para esta aplicación. Básicamente, cuando se solicita y se pide la ubicación en ese momento, o si quieres usar siempre la ubicación. Básicamente, nunca se nos debería volver a pedir permiso. Hay preocupaciones de privacidad para ambos, y depende de ti proporcionar una razón significativa por la que las personas deberían permitir eso, pero cuando estamos usando tu ubicación, obteniendo una ubicación detallada para la demostración. Luego diré, siempre, bueno, en realidad, mezclé eso, así que vamos a cambiarles el nombre rápidamente o restablecer esos valores. Tenemos dos razones diferentes por las que deberíamos obtener la ubicación. Siempre vamos a querer la ubicación o solo una vez, cuando se esté utilizando. Vamos a continuar revisando nuestro proyecto rápidamente. Tenemos algunas compatibilidades inversas de Cordova. Si por alguna razón tienes una aplicación Cordova existente y quieres migrarla, pero aún necesitas algunas API, no te preocupes, te tenemos cubierto. Las que quería ver son estos archivos POD. Ahora, los archivos POD son básicamente la versión de iOS de NPM en nuestro package JSON. Puedes ver que tenemos algunos lugares diferentes donde podemos usar algunas dependencias adicionales. Aquí, tenemos los principales para Capacitor. Puedes ver que tenemos el módulo principal de Capacitor, y está disponible dentro de los módulos de nodo, Capacitor/iOS. Es una forma perfectamente aceptable de obtener ese paquete, y puedes ver cómo dependemos del archivo POD y CocoaPods para poder recuperar esa dependencia y se vinculará automáticamente. No tenemos que tener un paso de NPM o de enlace como a veces tiene que hacer React Native. Nuevamente, nuestro paquete de compatibilidad de PackWords para Cordova, si quieres, y luego nuestros complementos también agregan esta entrada una vez que se instalan. Si queremos instalar Capacitor con NPM, ¿qué otro queremos instalar? Echemos un vistazo a nuestros documentos nuevamente. Vamos a llamar al de la aplicación. Podemos dejar que esto se ejecute NPNCAPSYNC, verá que tenemos una nueva dependencia. Luego, cuando volvamos a Xcode, verás que teníamos una pequeña advertencia como, eh, este archivo cambió, y ahora tenemos la nueva dependencia cargada en él. Es muy rápido, es muy fácil mantener esto sincronizado, ejecutas NPM Install y luego sync, automáticamente agregará estas referencias. Ahora, estas son para complementos y dependencias de Capacitor, pero tu proyecto también podría tener un conjunto completo de dependencias nativas aquí también. Por cualquier motivo, si quieres bajar a ese nivel nativo y agregar esas dependencias, puedes hacerlo y luego será como instalar cualquier dependencia nativa. No espero que muchas personas estén familiarizadas con esto ya que somos principalmente desarrolladores web. Pero es bueno saber que si tienes desarrolladores nativos en tu equipo o en tu departamento que les gustaría hacer esto y participar en este proceso, también pueden hacerlo.

Dejemos de hablar por un momento y procedamos a ejecutar esto. Voy a seleccionar el iPhone. Por qué no, vamos por el Pro Max. Vamos a dejar que esto se compile. En segundo plano, se están ejecutando todos los procesos de compilación de Xcode. Vamos a llevar esto a esta pantalla. Lo vamos a colocar aquí. Ahora, vemos que la aplicación está en funcionamiento. Se ve genial. Tenemos algunas cosas cuestionables aquí, pero las arreglaremos en un momento.

Veamos lo que tenemos aquí abajo. Este es un archivo de registro nativo. Si nunca has trabajado con Xcode y los registros nativos, esto nos dará información muy detallada. Es muy útil para registrar proyectos nativos, pero no es muy útil para nosotros en nuestro mundo de desarrollo web. Sin embargo, si vamos a, en este caso, Safari, sé que Safari probablemente no sea el navegador más genial, pero es un navegador y me encanta. Tenemos esta opción de mostrar el menú de desarrollador en la barra de menú, y eso nos da la opción de inspeccionar nuestra aplicación en ejecución dentro del simulador. Solo para demostrarlo, puedes ver que podemos resaltar todos los nodos del DOM, puedes ver nuestra raíz, puedes ver todo lo que estamos renderizando, se ve genial, muy familiar a todo lo demás. De hecho, podemos ver algunas de las fuentes aquí, así que podemos echar un vistazo. Este es código de producción, por lo que, obviamente, estará ofuscado y minimizado y todas esas cosas divertidas. Vamos a intentar obtener nuestra ubicación. Por supuesto, cuando hacemos clic en un enlace dentro del teléfono, se abre en un recurso externo. Vamos a decir, obtener ubicación. Permitimos que JSNation obtenga nuestra ubicación. Esta será nuestra autorización única, así que podemos decir, permitir una vez, y obtendremos los resultados de nuestra ubicación. Ahora, podemos ver los otros valores que obtenemos aquí. Ahora, puedes ver que, debido a que estamos en un tiempo de ejecución nativo, obtenemos muchos más detalles aquí. De hecho, si abrimos y vemos dónde están nuestros valores de ubicación, en realidad se hará una pequeña comparación. Puedes ver que la ubicación y la latitud son muy diferentes, principalmente porque el simulador simulará una ubicación diferente. Podemos ver que obtenemos una velocidad, obtenemos una altitud, obtenemos una precisión, obtenemos toda esta otra información que podría ser valiosa para nuestra aplicación. Ahora, si pensamos en el tipo de aplicaciones que necesitarían esta información, podría ser una aplicación de entrega, piensa en DoorDash, Uber Eats, Postmates, cualquier aplicación útil en tu área, o si estás utilizando DHL, FedEx, UPS, varios servicios de entrega. Toda esta información se puede utilizar para construir un contexto rico de un servicio de mapas que muestre dónde podría estar un repartidor, y luego puedes notificar al usuario diciendo: 'Oye, el usuario ha ingresado a esta ubicación, están a unas paradas de distancia, sigue tu progreso aquí'. Hagámoslo rápido. Como dije, si obtenemos la ubicación nuevamente, se fijará ese servicio de ubicación allí arriba, y puedes ver la pequeña flecha. Vamos a ponerlo en un viaje por la autopista. Obtendremos la ubicación y, con suerte, esto se actualizará en algún lugar diferente. Lo dejaremos ejecutarse un poco. Puedes ver que estamos empezando a obtener una ubicación ligeramente diferente. Es muy sutil, pero podemos rastrear este cambio, y esto requerirá una pequeña refactorización. Nuestro servicio de ubicación aquí está funcionando bien. Vamos a crear un nuevo valor de estado aquí, y será una cadena. Será watchId, y luego setWatchId. En lugar de que getLocation sea una función asíncrona, lo que haremos es llamar a geolocation.watchPosition. Ahora, este es el mismo valor. Lo mismo en todas las plataformas, devuelve un observador. Ese observador ejecutará una devolución de llamada cada vez que obtenga nuevos datos de ubicación. Le daremos ninguna opción porque los valores predeterminados funcionan muy bien y obtendrá una devolución de llamada con algunos datos de posición. Lo dejaremos así por ahora. Luego, dentro de eso, también hagamos, ID = await. Solo para asegurarme de obtener toda la información de tipo. Por eso me gusta tener TypeScript en un proyecto. Puede que a ti no te guste, pero a mí sí.

Luego simplemente diremos que establezcamos el ID de observación en ID. Vamos a comentar todo esto por ahora porque vamos a hacer algunas cosas aquí arriba. Ahora, simplemente diremos que las coordenadas son iguales a position.coordinates porque eso podría estar disponible. Luego, con eso, podemos simplemente decir establecer lock en, bueno, vamos a ir si cords set lock. Ahora podemos verificar de forma segura porque esto podría no estar disponible porque la posición podría no estar disponible por cualquier motivo. Esto se ve bien. Tenemos este ID de observación, que necesitamos limpiar un poco en nuestra función de retorno de nuestro useEffect. Simplemente diremos geolocation.clearWatch, y luego el ID será watchID. Todo esto se ve bastante bien. Vamos a hacer una ejecución rápida. Necesitaremos NPM run builds. Eso funciona bien. NPM o npxSync. Eso sincronizará nuestros activos con la aplicación nativa. Podemos volver a Xcode. Vamos a detener esto y luego volver a ejecutar nuestra aplicación y dejar que se inicie. ¿Puedes ver lo rápido que fue? Solo quiero asegurarme de que haya funcionado, genial. Asegúrate de que todo esto esté cerrado en segundo plano. Ejecuta eso nuevamente, se inicia muy, muy rápido, lo cual es genial. Vamos a llamar a getLocation nuevamente. Permitiremos una vez más, y vamos a dejar que esto se ejecute. Ahora, como todavía estamos simulando un viaje por la autopista, podríamos obtener todos estos data de vuelta, y luego podríamos observar los valores y actualizarlos en tiempo real. Si, por alguna razón, cometemos un error, ya estamos en un lugar donde creo que puedes ver dónde está el mayor cuello de botella, y eso es el tiempo desde que hacemos un cambio aquí hasta que se envía dentro de la aplicación. Ya hay algunas cosas sucediendo allí. Podemos hacer el cambio aquí, construimos, sincronizamos, sería genial si pudiéramos simplemente tener esto ejecutándose localmente. Bueno, podemos. Vamos a ejecutar npm run dev, creo que es externo, y vamos a copiar esto, luego vamos a ir a nuestra configuración de capacitor. Creo que lo que hacemos es ir y podemos anular cómo se ejecuta realmente esto, en nuestro dispositivo utilizando la recarga en vivo. Ahora, si hay algo que es confuso, lo que podemos hacer es mirar los menús principales. Podemos ver nuestra documentación. Tenemos una sección completa de guías sobre cómo hacer ciertas cosas. Veamos, Recarga en Vivo. Adelante. Podemos ir a nuestro servidor. Solo para asegurarnos de que lo tengamos configurado correctamente, vamos a nuestro campo de Servidor, diremos que la URL será, ¿cuál es? Vamos a hacer un poco de copiar y pegar. La URL será eso. Estableceremos el texto sin formato en verdadero. Eso debería estar bien. Ahora, podemos ir a una nueva terminal. Haremos npm o npx cap sync. Nuevamente, para sincronizar todo junto, volvamos a Xcode. Ejecutaremos nuestra compilación una vez más. Ya estamos conectados, pero podemos ver algo diferente aquí. Estamos usando V y estamos obteniendo esos registros en el IDE nativo, que es lo que queremos. Ahora, podemos volver a nuestra aplicación, y asegurémonos de que esto funcione. Eliminaremos los enlaces a Vit y la documentación de React. Perfecto. Esto se ve bien. V más React más cap, excelente. Sabes qué, no necesitamos Vit porque no es tan importante en este momento.

Ver botón, coche, ubicación. Ya no estamos haciendo nada con el botón. Deshagámonos de él. Ya no lo necesitamos. Ya tenemos un proceso muy rápido e iterativo. Podemos seguir adelante con todo esto. Voy a mover el pre fuera de la tarjeta. Veamos, obtengamos la ubicación. Continuará, permitir una vez. Mientras se captura esa ubicación, podemos seguir adelante, podemos comenzar a actualizar partes de nuestras aplicaciones. En lugar de esto, diremos cap más react, que todos esos valores cambien. Esto no es necesariamente una característica de capacitor. Es realmente una característica de v y su reemplazo de módulo en caliente. Pero puedes ver que, a medida que comienzas a acceder a funciones y API nativas, el ciclo de retroalimentación desde la construcción de tu aplicación y obtener algo en funcionamiento en el dispositivo puede ser muy, muy rápido. Ya no necesitamos esto. Ya no necesitamos esto, pero hay algo que podríamos hacer. Si miramos nuevamente en Xcode, puedes ver que limpiamos la observación porque se llamó a un useEffect. Entonces podemos obtener eso nuevamente. Si ponemos la aplicación en segundo plano, las ubicaciones aún se llaman, pero no se hace de una manera realmente eficiente o óptima para los usuarios. En cambio, tenemos esta oferta de la comunidad de capacitor, que creo que es un poco mejor. Ubicación en segundo plano. Entonces, si has utilizado alguna vez la ubicación en segundo plano antes, cualquier servicio en segundo plano en, digamos, React Native o Cordova, sabes que pueden ser un dolor. IOS es muy particular en cómo permiten que ocurran tareas en segundo plano. Este complemento simplifica todo eso y lo hace mucho más fácil. Lo que vamos a hacer es configurarlo, y vamos a utilizar algunos servicios de ubicación en segundo plano dentro de nuestra aplicación, y para hacer eso, vamos a seguir adelante, y primero lo instalaremos, y luego lo agregaremos a nuestro proyecto. Vamos a detener el servidor de desarrollo, y luego ejecutaremos ese comando de instalación. Esta es una excelente manera de ver que aunque hay cosas básicas que proporciona capacitor, a veces, una comunidad puede proporcionar diferentes alternativas que son, en muchas opiniones, mejores, pero también hacen algo ligeramente diferente, lo que también las hace válidas. Nuevamente, no digo que una sea mejor que la otra, es simplemente una forma diferente de hacer las cosas que podría ser importante. Ahí vamos. En lugar de usar la geolocalización de capacitor, coméntalo, vamos a usar estos servicios de ubicación en segundo plano, que son impulsados y compatibles con la comunidad de capacitor. Gracias al autor de este complemento. Ahora lo que vamos a hacer es echar un vistazo rápido a la documentación porque necesitamos ver cómo funciona esto, ya que tiene una firma diferente a la incorporada. En lugar de hacer esta posición de observación, tenemos este observador adicional. Como observador, tiene una función de devolución de llamada donde podemos decir, ''Oye, esto no fue autorizado'', y luego podemos borrar esto después de que se hayan hecho las cosas. Es ligeramente diferente. El ejemplo es un poco más detallado. Vamos a adaptarlo a nuestros casos de uso. Diremos background geolocation.AddWatcher, Ahora, vamos a echar un vistazo a lo que tenemos aquí. Vamos a copiar más o menos todas estas opciones. Principalmente porque si están en la documentación, son muy útiles, pero vamos a eliminar los comentarios. Una de las cosas que hacen y que realmente apruebo es que solicitan permiso y lo manejan por ti. Luego, en la función de devolución de llamada, obtenemos la ubicación y luego potencialmente un error. Podemos ver, asegurémonos de que no haya abierto nada. Obtenemos el código de error, lo que podría estar sucediendo. De lo contrario, deberíamos comentar la consola de registro en el error real. Pero lo que es realmente bueno es que proporcionan esta función de configuración abierta. Nuevamente, construyendo sobre lo que ya hemos proporcionado con características adicionales, vamos a seguir adelante y decir error, simplemente diremos si hay un error console.error y luego podemos obtener los datos de ubicación de aquí. La ubicación no nos devolverá las coordenadas. En realidad, nos devolverá un punto de posición. En realidad, nos devolverá todo automáticamente.

Lo que podemos hacer es simplemente eliminar eso. De hecho, podemos deshacernos de eso por completo y podemos simplemente decir ubicación, en realidad, no es ubicación, ubicación es posición. Sí, sí, eso debería estar bien. Podemos continuar y configurarlo todo y luego el ID aún se devuelve aquí y luego podemos solucionar eso. La duración debe eliminarse. Pero sigamos adelante e intentemos ejecutar esto nuevamente. Ahora ejecutaremos nuestro comando de desarrollo y luego ejecutaremos la sincronización. Porque nuevamente, se encontró que la ubicación en segundo plano es un complemento de terceros y necesita configurarse. Con nuestro simulador abierto, podemos continuar y ejecutar esto. Y podemos ver que esto es en realidad un error. Entonces, geo-location.clearWatch no es una función, eso es culpa mía porque no lo aclaré. Lo que podemos hacer, y creo que es removeWatcher. Correcto, ubicación en segundo plano, eso es lo que es. ubicación en segundo plano.removeWatcher. ID = watchID. Pongámoslo en marcha. OK, ahora está bien. Sigamos adelante y limpiemos esto rápidamente. Y obtengamos nuestro bloqueo. Ahora puedes ver que tenemos otros problemas aquí. Y esto va a ser bastante común. Esto es una excepción. Esto es lo que sucede en nativo cuando obtienes una excepción, obtienes un error. Y solo lo obtengo porque sé lo que realmente necesitamos hacer. Necesitamos asegurarnos de agregar algunas cosas como estos modos de fondo de la interfaz de usuario. Esto es algo que iOS hace cuando intentas acceder al procesamiento en segundo plano o actividades en segundo plano sin declarar los permisos adecuados. Ya tenemos esta ubicación cuando se usa. Ya tenemos nuestra ubicación siempre cuando se usa, y luego tenemos nuestro modo de fondo de la interfaz de usuario. Entonces, sigamos adelante y voy a copiar esto. Y voy a modificar directamente las cosas de iOS porque ya sé dónde está. No, no eso. Vamos a continuar y vamos a agregar esto. Y luego podemos detener la ejecución. Podemos volver solo para verificar que realmente está ahí. Modos de fondo adquiridos, puedes ver que la aplicación está registrada para actualizaciones de ubicación cuando está en segundo plano. Eso es lo que queremos. Eso es lo que necesitamos. Sigamos adelante y ejecutemos eso nuevamente, y llamemos a get lock, y puedes ver que esta aplicación ha intentado acceder a datos sensibles de privacidad sin una descripción de uso. El uso debe contener NSLocation siempre y cuando se usa. Perfecto. Tenemos cuando se usa. Tenemos siempre, pero necesitamos uno más. Sigamos adelante y agreguemos eso también. Privacidad de ubicación. Ubicación. Siempre y cuando se use. Obteniendo detalles de ubicación en segundo plano. OK. Una última vez, lo cual es muy bueno. No solo nos permite hacer esto.

Avancemos y obtengamos esa ubicación data. Oye, obteniendo ubicaciones detalladas para demostraciones. Sigamos adelante y pongámoslo en marcha. Ahora esto está llamando a la implementación de ubicación en segundo plano. Ahora podemos seguir adelante, podemos cerrar esto, y luego sabemos que esto está sucediendo en segundo plano y que data ya está ahí. No necesitamos preocuparnos por eso. Se está haciendo de una manera que es eficiente, está utilizando las API y permisos correctos que suceden en segundo plano. De hecho, si abrimos Configuración, podemos ver dónde está nuestra aplicación ¿configuraciones? Tal vez no. Es posible que no esté aquí en el simulador. Normalmente está en un dispositivo real, así que volvamos de eso. Pero puedes ver que todavía está obteniendo esa ubicación, sigue actualizando todas nuestras conexiones, y es mucho más rápido y utiliza esos permisos correctos.

Así que voy a hacer una pausa por un segundo, tomar un sorbo de agua. Si hay alguna pregunta hasta ahora, por favor, colóquenlas en el chat.

De acuerdo, lo que vamos a hacer ahora, vamos a detener esto, de esa manera podemos limpiar esas ubicaciones y no dejar que esto siga ejecutándose. En lugar de hacer más con las ubicaciones, porque las ubicaciones no son tan impresionantes cuando sabemos que las tenemos en la web, vamos a intentar echar un vistazo a otra API. Y esta es una que tengo y que podríamos usar con bastante regularidad. De hecho, vamos a seguir adelante y simplemente, vamos a comprometer esto agregar demostración de ubicación. Y vamos a seguir adelante y crear otro proyecto. Uno con el que estoy más familiarizado. Puede ser un poco más complicado. Puede que me arrepienta, pero esto va a ser realmente, realmente divertido. Así que con eso, la rama del repositorio del proyecto ya debería estar actualizada.

Lo que vamos a hacer es vamos a crear otro proyecto. Tomador de notas y será un tipo de aplicación en blanco React. Vamos a usar esto con Ionic, que es solo una biblioteca de interfaz de usuario. Puedes reemplazar Ionic con algo como Tailwind o tu propia biblioteca de interfaz de usuario personalizada, preferiblemente tu propia biblioteca de interfaz de usuario personalizada. No creo que todos necesiten usar Tailwind, pero vas a implementar esto con una interfaz de usuario. Vamos a crear un pequeño tomador de notas rápido que interactúe con el sistema de archivos. Esto nos dará una implementación práctica de cómo se pueden hacer estas interfaces de usuario. Luego veremos cómo difieren al usar Capacitor solo sin un marco, o al usar Capacitor con otra herramienta gratuita como Ionic. Los principios aún se pueden aplicar. Como dije, aún puedes hacer todo esto sin Ionic, pero Ionic simplemente facilita un poco más, en mi opinión. Por ejemplo, esa aplicación se veía bien, pero vamos a hacer que se vea mejor que bien. Vamos a ejecutar serve. Esto nos dará una aplicación en blanco de Ionic que podemos ver. Ya tiene algo de interfaz de usuario aquí, y realmente no necesitamos esto. Vamos a entrar en nuestra página de inicio, que sé que es homepage.tsx. Al final del día, esto sigue siendo un proyecto de React, y todo esto son solo componentes de React. Vamos a crear un mapa. Diremos notas.mappnotes, y vamos a devolver. Simplemente vamos a hacer JSON.StringifyNotes. Principalmente porque sé lo que vamos a renderizar aquí. Muy bien. Así que tenemos algunas cosas que necesitamos agregar. Principalmente la nota y las notas. Así que vamos a decir const notes y luego setNotes. Esos van a ser algunos usedState, que será un array con el tipo de any. Importaremos usedState y también necesitamos seguir adelante, e instalaremos atCapacitor, y vamos a instalar el complemento de archivos. Creo que no lleva guion, pero por si acaso, vamos a consultar una referencia de la documentación. Vamos a obtener el sistema de archivos.

Sí, no lleva guion. Vamos a instalar la API de sistema de archivos. Esto nos permitirá tener acceso al sistema de archivos de una manera muy familiar si has trabajado con la API de sistema de archivos de Node. Así que vamos a importar desde atCapacitor File System, e importaremos la clase de sistema de archivos. Ahora vamos a usar un gancho de ciclo de vida que es específico de Ionic, no necesariamente específico de React, pero es familiar, bueno en realidad, vamos a usar el equivalente de React por ahora. No tendrá dependencias, hacia atrás hacia matrices vacías que son nulas, lo que vamos a hacer es vamos a solicitar permiso para acceder al sistema de archivos. Así que diremos 콘t, initfs será una función asíncrona, o diremos filesystem.requestpermission, y de hecho, movamos esto aquí afuera, para que no se ejecute cada vez en useEffect, y simplemente diremos initfs. Veamos cómo va eso. Ok, el sistema de archivos ha sido resuelto. Y luego vamos a seguir adelante y vamos a decir leer directorio. Ahora leer directorio será otra función asíncrona. Y aquí es donde vamos a seguir adelante y leer el directorio de archivos en nuestro sistema de archivos. Así que diremos await filesystem.reader. Y le daremos un directorio, que será un directorio.documento. Ahora este directorio es en realidad un enum que proviene de la API de sistema de archivos básicamente nos está dando una forma segura de decir ve a buscar algo desde un directorio de documentos. Y luego le daremos una ruta, que será la carpeta real que queremos leer. En este caso, solo vamos a leer las notas y luego estamos listos. Pero si estamos en una situación en la que ese directorio no existe, esto dará un error. Y de hecho, vamos a seguir adelante y vamos a crear otra función aquí llamada make dir, y make dir hará exactamente lo que suena. Llamará a make dir y si ese directorio existe, make dir simplemente dirá, el directorio ya existe, no hay nada que hacer aquí. Rechazará esa promesa y luego seguiremos adelante, iniciaremos una lectura de directorio. Así que digamos init file system y luego .then seguiremos adelante y diremos, make dir .then, seguiremos adelante y diremos this o read dir. Vamos a seguir adelante y guardar eso. El directorio ya existe, puedes ver que ya lo hemos manejado correctamente. Con este .then, vamos a seguir adelante y simplemente diremos no arriba, en realidad, ¿cómo queremos hacer esto? Oh, simplemente vamos a seguir adelante y encadenarlos todos juntos. ¿Por qué no? Porque async lo hace mucho más fácil. Espera, espera. Make dir await read dir. Y luego en lugar de llamar a eso, simplemente diremos init. Todo listo, bien, este directorio es un problema, o existe, porque podemos capturar esto aquí arriba. Console.log dir mate, y en lugar de eso, dices, console.log dir ya existía. Genial, ya está bien, las cosas se ven geniales. De hecho, vamos a limpiar esto rápidamente, para que sea más fácil de leer. Ahora, con todo esto junto, vamos a seguir adelante y simplemente diremos, console files igual a esto, y vamos a console.log todos los archivos que obtuvimos de esto. Los archivos nos dan un array de, o nos dan un objeto de archivos que es un array. Hagamos esto aún mejor, porque la destructuración existe, y podemos ver que obtenemos un array de archivos de esto. No hay archivos aquí, el directorio ya existe sin embargo, así que no tenemos nada que crear aquí, pero tenemos acceso a un almacenamiento en un navegador que no admite una API de almacenamiento. ¿Qué está pasando aquí? Bueno, resulta que hay una API de almacenamiento dentro del navegador, y es muy clara un almacenamiento de archivos por una carpeta. En realidad estamos usando IndexedDB para simular una API de sistema de archivos, lo cual cuando he descrito esto a la gente, pensaron que era un hack terrible, pero funciona. IndexedDB es en realidad muy capaz y proporciona muchas características interesantes. Podemos obtener todo el tiempo de un, podemos obtener la carpeta, podemos obtener un directorio, podemos obtener el tamaño del directorio. Muchas cosas interesantes se pueden hacer aquí que simplemente hacen que se sienta tan correcto hacerlo en IndexedDB. Vamos a seguir adelante y vamos a, por el bien de una demostración, vamos a seguir adelante y hacer que todos nuestros archivos se hagan aquí. Simplemente diremos, establecer notas y será nuestro array de archivos. Vamos a verificar en un navegador, todo se ve bien. Vamos a crear una función más aquí, y eso va a ser const make file. Esto también será una función asíncrona. Capacitor, si no te has dado cuenta hasta ahora, es completamente asíncrono, todo basado en promesas. Verás async bastante dentro de tus proyectos. Pero vamos a tener algunos data.

En este punto, simplemente lo dejaremos como una cadena vacía. O de hecho, digamos que es, hola demos o demo. Luego vamos a llamar a await. Sistema de archivos. Luego vamos a seguir adelante y llamar a write file. Write file nos dará una forma rápida de simplemente decir, haciendo un archivo en este directorio con estos data, con esta codificación. Si has usado write file sincronizado en Node, esto funciona de la misma manera. Tenemos una función. Diremos que los data serán data. Diremos que el directorio será directory.enums, o.documents, path, notes, y luego la codificación. No sé por qué está sucediendo eso..utfa. Nuestro sistema de archivos va a seguir adelante y luego va a escribir un archivo para nosotros y luego simplemente podemos decir entonces, lector, porque solo queremos volver a leer el directorio después de que se cree ese archivo. De hecho, vamos a seguir adelante. Sí, eso estará bien. En realidad, vamos a seguir adelante y vamos a cambiar esto. Será un cambio rápido. Simplemente diremos date.now. Esto debería estar bien. Vamos a guardarlo. Luego vamos a agregar un botón que nos permitirá llamar a eso. Si no te importa, esto será solo un poco de ionic rápido, slot equals end ion button on click. Bueno, en realidad, antes de hacer eso, importemos el botón. En el evento on click, será add make file y luego ion icon, icon equals plus, qué es, add. Déjame averiguar de dónde viene el icono. Eso debería estar bien. Ahora, nuestras carpetas de documentos están aquí, tenemos nuestro botón aquí en las DevTools, vamos a seguir adelante y crear uno nuevo y ver qué sucede. La ruta proporcionada es un directorio. ¿Qué significa eso? Tenemos que darle un nombre. Me olvidé de esa parte. En realidad, este es muy bueno. Debes agregar un nuevo nombre cada vez que creas un archivo. Lo que vamos a hacer aquí es cambiar el entorno para que sean unas comillas invertidas. En realidad, vamos a pasar data, y luego le daremos un punto txt. Luego lo llamaremos de nuevo y veremos qué explota. Cada elemento debe tener su propia clave. Eso está totalmente bien. Vamos a hacer una coerción de tipo aquí, será un archivo, que es de capacitor en sí mismo. Puedes ver todas las diferentes data disponibles automáticamente aquí y simplemente le daremos una clave de note dots, o name. Esto funciona bien. Vamos a seguir adelante y agregar otro. Cada nota aquí es una cosa propia con su propio bit de data. Ahora, si seguimos adelante y actualizamos este directorio, puedes ver que todos esos data se están almacenando aquí. Y luego podemos ver todas las diferentes piezas en ese documento real. Esto se vuelve muy convincente a medida que intentas construir aplicaciones ricas que serán complejas. Ahora, lo genial de local store, sobre IndexedDB aquí, es que esto solo está disponible para hosts locales. Esto solo está disponible para mí. Nunca estará disponible para un tercero, lo cual es por design y muy bueno. Ahora, lo mismo puede suceder si seguimos adelante y ejecutamos una compilación y tratamos de hacer esto en iOS. Ahora, la compilación llevará un poco más de tiempo porque es un poco más complicada. Pero si hacemos los mismos procesos que antes, agregaremos iOS.

Esto va a continuar, tener todo funcionando Ionic cap, run iOS, y vamos a utilizar algunas de las funciones auxiliares de Ionic internamente para poner esto en nuestro simulador más rápido de lo que lo haríamos por nosotros mismos. Nuestro simulador va a continuar, va a ejecutar ese objetivo nativo. Lo va a implementar en nuestro dispositivo. Aquí estamos en nuestro dispositivo. Tenemos nuestras herramientas de desarrollo abiertas aquí en el navegador. Volvamos a nuestro simulador, y vamos a continuar y ejecutar esto. Esto nos está dando un valor de retorno muy diferente. Puedes ver aquí que tenemos, y de hecho, vamos a continuar y arreglar esto rápidamente. La P probablemente no sea el parámetro más fácil de leer aquí, y vamos a decir null dos, y mucho mejor, más fácil de leer. Ahora, donde vemos que tenemos esta URI, ¿qué tenemos aquí? Tenemos una ruta. Ahora, lo que esto hace es darnos un contexto diferente de dónde se lee esto y de dónde se carga. Aquí estamos leyendo desde el servicio de ubicación real de nuestro dispositivo. Entonces, a medida que construyes una aplicación y quieres almacenar data durante un período de tiempo más largo, esos data se pueden almacenar dentro del mecanismo de almacenamiento propio del dispositivo y no estar sujetos a que el navegador borre esa caché por cualquier motivo. El almacenamiento de IndexedDB podría ser eliminado, pero esto nunca se eliminará a menos que vayas y vayas a Configuración, y aún no aparece allí. Bueno, lo que sea. A menos que lo elimines manualmente, no hay forma de que esto desaparezca. Todos estos estarán perfectamente existentes en esta aplicación a menos que elimine la aplicación en sí. Ya hemos logrado mucho hasta ahora. Me siento bastante bien en este punto. Han pasado aproximadamente dos horas y ya hemos tenido a una persona que abandonó la masterclass. El API del Sistema de Archivos es una API bastante simple. Gran parte de esto, si miramos el código, se trata más de hacer alguna orquestación. Leer los archivos, obtener el directorio si no existe, crear los permisos, cosas bastante estándar. Entonces, esto es algo que cualquiera podría construir y tener su propia aplicación de toma de notas bastante agradable muy rápidamente. Lo que voy a hacer ahora es continuar y hacer un commit, veamos, segunda demo, y diremos hub creates, lo llamaremos jsnation-demo2, git push origin main, y luego hub browse. También voy a dejar esto aquí dentro de los chats, para que todos puedan echar un vistazo, y también tendré la otra demo preparada, pero lo que deberíamos hacer ahora es, ya que estamos en las dos horas, hacer un resumen rápido, porque sé que es un día largo para algunos de ustedes, considerando la zona horaria, para que no ocupe el resto de su tarde. Pero, el proceso de obtener Capacitor en un proyecto, bastante simple, bastante poco esfuerzo, instalamos estas dos dependencias, e inicializamos el proyecto. Si solo estás probando esto en tu aplicación existente, crea una nueva rama, pruébalo, y ve si es algo de lo que puedes beneficiarte. Si quieres aprender más, tenemos CapacitorJS.com como nuestra página principal, hay muchos buenos ejemplos y referencias en esa única página de inicio, y luego tenemos la documentación para obtener más ayuda sobre cómo implementar algunas características, obtener algunas guías o ver la documentación real del plugin. Para ese ejemplo de ubicación en segundo plano, tenemos que agradecer a la comunidad de Capacitor, estos son nuestros plugins de terceros autorizados de autores que se han comprometido a mantenerlos, puedes echar un vistazo a algunos de esos plugins allí, todos son de muy alta calidad y son mantenidos por nuestra encantadora comunidad, si volvemos atrás y echamos un vistazo a todo menos todas las consultas de búsqueda. Hay una buena cantidad de plugins aquí, el Photoviewer, Barcode Scanner, camera preview, Firebase analytics, hay muchas cosas aquí si quieres usar esto realmente. AdMob, incluso para obtener ingresos de los anuncios dentro de tu aplicación, algo que aparentemente mucha gente hace. Así que definitivamente revisa estos recursos si quieres comenzar a hacer cosas en Capacitor. Solo digo esto porque sé que a mucha gente le resulta extraño usar herramientas de código abierto, pero hay muchas empresas que están utilizando Capacitor en producción en este momento. Algunas empresas muy grandes aquí en Estados Unidos, algunas empresas muy grandes a nivel internacional. Todas están utilizando Capacitor, ya sea principalmente, ya sea aplicaciones internas o externas, aplicaciones internas o aplicaciones externas, están utilizando Capacitor. De hecho, algunas de estas marcas de comida lo están utilizando para toda su experiencia de pedidos de clientes, lo cual es realmente genial. Capacitor espero que al final de esto muestre que no tienes que escribir mucho código para obtener mucha funcionalidad. Puedes tener una aplicación nativa completa que aún es principalmente web y aún puede acceder a esas APIs a través de JavaScript lo cual es muy agradable. En caso de que necesites hacer algo con el proyecto nativo, no debería ser algo que se oculte y se esconda en un rincón, está ahí. Deberías poder acceder a él y luego proporcionar algunas personalizaciones si las necesitas. Pero eso es todo lo que tengo por hoy. Muchas gracias a todos por pasar tiempo conmigo durante las últimas dos horas. Espero que obtengan algún valor de esto. Si tienen alguna pregunta, estaré en el discord por un rato solo para pasar el rato. Dejaré todos los enlaces de las demos que tuvimos y algunos de los recursos. Pero todos ustedes han sido maravillosos. Muchas gracias. Y espero que tengan un excelente resto de su día.