Probablemente se encuentre en una de dos situaciones. O bien ha heredado una aplicación Cordova que todavía es importante para la empresa, o está manteniendo una aplicación híbrida estable mientras el equipo se desplaza lentamente hacia herramientas más nuevas. Luego, una solicitud de producto llega: escanee etiquetas de inventario, boletos, paquetes o etiquetas de estantería con la cámara del teléfono.
Eso es donde lector de códigos de barras Cordova comienza a trabajar. La demo básica es fácil. La integración de producción no lo es. Las partes difíciles son elegir un plugin que coincida con sus formatos de códigos de barras, configurar permisos nativos limpiamente y tratar con las peculiaridades de la plataforma que solo se muestran en dispositivos reales. Si su aplicación también toca operaciones de campo o flujos de inventario, la característica de escaneo suele conectarse a preocupaciones operativas más amplias como gestionar componentes de TI críticos, donde la aplicación móvil se convierte en parte de un flujo de activos y servicios más grande.
Cordova sigue siendo una pila real en el trabajo de mantenimiento empresarial. A mediados de la década de 2010, el escaneo de códigos de barras en Cordova ya había pasado de los ejemplos de juguete a aplicaciones híbridas empresariales construidas para Android y conectadas a servicios de backend, incluido un flujo documentado utilizando cordova create, cordova platform add android, y un generado barcodeScanner-debug.apk en un ejemplo práctico de construcción de aplicación de Paso a paso de SitePoint para escanear con CordovaSi su equipo también está ponderando elecciones de arquitectura a largo plazo, esta comparación de aplicaciones nativas vs aplicaciones web ayuda a comprender por qué las aplicaciones híbridas siguen aparecer en los flujos de entrega móvil serio.
Contenido de la página
- Why Add a Barcode Scanner to Your Cordova App
- Elige su plugin de escáner de códigos de barras de Cordova
- Instalación y configuración de plataforma
- Implementar el escáner en su aplicación Code
- Pruebas y depuración de errores comunes
- Consejos de rendimiento y migración a Capacitor
Why Add a Barcode Scanner to Your Cordova App
A un escáner cambia lo que una aplicación de Cordova puede hacer en el campo. En lugar de pedir a los usuarios que escriban números de serie, IDs de pedido o códigos de producto, permite que la cámara se convierta en dispositivo de entrada. Eso reduce la fricción, pero críticamente, reduce el número de formas en que un usuario puede ingresar un valor incorrecto.
En la práctica, el escaneo de códigos de barras aparece donde las aplicaciones móviles se encuentran con operaciones reales. La recepción de almacén, la búsqueda de retail, la validación de partes de servicio de campo, el registro de visitantes y el seguimiento de activos internos se benefician de ello. Un escáner también cambia las expectativas de los usuarios. Una vez que la cámara está disponible, los usuarios dejan de tolerar la entrada manual code a menos que haya un fallback claro.
Cordova sigue siendo útil en modo de mantenimiento
Muchas equipos hablan sobre Cordova como si hubiera desaparecido. No es así. Se ha vuelto un componente de mantenimiento pesado de los portafolios de empresas, donde reemplazar una aplicación funcionante es más difícil que extenderla. Si la aplicación ya maneja la autenticación, la sincronización, las formas y el almacenamiento en caché, agregar un escáner a menudo es más bajo riesgo que reconstruir el producto completo.
Regla práctica: No traten una solicitud de escaneo como un disparador de reescritura a menos que el resto de la aplicación ya esté fallando la operación de su equipo.
Cordova también ganó su lugar porque los plugins expusieron las capacidades de dispositivo nativo de una manera que el code web podía utilizar. Eso es por qué el escaneo de códigos de barras se volvió tan común en aplicaciones móviles híbridas. Se ajustaba al patrón exacto para el que Cordova fue diseñado: poner una capacidad nativa detrás de un API JavaScript y dejar que el flujo de la aplicación se mantenga principalmente web.
El valor está en el flujo de trabajo, no en la demostración
Un botón de escáner que devuelve texto es la parte fácil. El trabajo principal es todo lo que lo rodea:
- Elige las simbologías soportadas: Tu aplicación puede necesitar solo QR o también necesitar códigos de retail y logística.
- Administra las permisos de manera limpia: Si el acceso a la cámara falla una vez, los usuarios asumen que la característica está rota.
- Diseña la acción posterior a la escaneo: La búsqueda, la validación, la navegación y el manejo de duplicados importan más que la interfaz de la cámara.
- Planifica la modernización: Si tu equipo está migrando hacia Capacitor, necesitas un enfoque que no atrape la característica en suposiciones de Cordova únicamente.
Este último punto importa. Los equipos a menudo tienen éxito con la integración inicial de Cordova, pero luego encuentran problemas durante la migración porque el modelo de renderizado nativo cambia debajo del plugin. El escáner sigue funcionando. La vista previa simplemente no muestra donde esperas.
Elige su plugin de escáner de códigos de barras de Cordova
Antes de escribir cualquier aplicación code, decide qué estás optimizando. Algunos equipos necesitan un soporte de códigos de barras amplio. Otros solo necesitan una capa de cámara para flujos de QR. Seleccionar el plugin incorrecto al principio crea retrasos posteriores, especialmente cuando el producto solicita un formato de código de barras adicional después del lanzamiento.
The plugin que los desarrolladores reconocerán es cordova-plugin-barcodescanner. Su paquete npm documenta un scan(success, fail) API y soporte para símbolos comunes incluyendo QR_CODE, DATA_MATRIX, UPC_A, EAN_13, CODE_128, PDF_417, y AZTEC, por lo que se adapta tanto a escenarios de retail como de logística en lugar de solo casos de uso basados en QR, como se muestra en el documentación del paquete del plugin en npm.
Para equipos que evalúan estrategias de plugins de manera más amplia, esta visión general de qué saber sobre Capacitor plugins es útil porque destaca las diferencias entre las suposiciones de plugins Cordova antiguos y los modelos de puentes nativos más nuevos.

Lo que importa antes de instalar cualquier cosa
No comience con la popularidad sola. Comience con su trabajo de escaneo.
If el app debe leer varias familias de códigos de barras en diferentes contextos operativos, el soporte de símbolos amplios es más importante que un API mínimo. Si la app solo necesita verificar el check-in QR, puede aceptar una herramienta más estrecha si le da una experiencia de cámara más simple. Lo que a menudo se pasa por alto por los desarrolladores junior es que el trabajo del escáner es menos sobre '¿puede escanear' y más sobre '¿puede escanear los etiquetas exactas utilizadas por las operaciones sin soluciones de trabajo incómodas'.
Un buen checklist de selección debe parecerse a esto:
- Cobertura de códigos de barras: Confirme los formatos exactos utilizados en producción.
- Expectativas de plataforma: Verifique qué el equipo todavía apoya hoy, no qué el plugin apoyó históricamente.
- Model de interfaz Algunos plugins abren un flujo de escaneo nativo. Otros esperan un enfoque de vista previa incorporado.
- Tolerancia de migración: Pregúntese si este plugin se volverá doloroso si la app se mueve a Capacitor más tarde.
Un plugin que funciona en una demo pero lucha contra tu diseño de la aplicación, ciclo de vida o ruta de migración suele ser el plugin incorrecto.
Tabla de comparación de plugins
| Característica | phonegap-plugin-barcodescanner | cordova-plugin-qrscanner |
|---|---|---|
| Uso principal | Escaneo de códigos de barras amplio y variado | Flujos de escaneo enfocados en QR |
| API estilo | Patrón de llamada familiar en muchos proyectos Cordova legados | Frecuentemente elegido para casos de uso de vista previa de cámara en vivo |
| Formato de código de barras | Mejor ajuste cuando el producto necesita más que QR | Mejor ajuste cuando QR es el único requisito estricto |
| Riesgo de migración | Puede funcionar, pero pueden surgir suposiciones más antiguas durante las migraciones de puentes modernos | Preview-heavy approaches can expose rendering issues faster |
| Mejor ajuste | Flujos de trabajo de código de barras de retail, logística, activos y mixtos | Flujos de autenticación, URL, solo QR y de registro |
Esta tabla refleja la compatibilidad práctica, no una tarjeta de puntuación. Si necesita símbolos de retail y logística, la categoría de plugins más amplia es normalmente la elección más segura. Si solo escanea QR y quiere una experiencia de vista previa más controlada, un camino orientado a QR puede ser más ligero
El error que veo con más frecuencia es elegir una herramienta enfocada en QR porque la primera versión solo necesita QR, y luego forzarla a UPC o Code 128 más tarde. Si hay alguna posibilidad de que los usuarios de su negocio escanee etiquetas de impresoras, estantes, contenedores o documentos de envío, elija esa opción para el futuro ahora
Instalación y configuración de plataforma
La integración suele fallar antes de la primera escaneo, no después. La mayoría de los errores provienen de la desviación de configuración entre las expectativas de JavaScript y la configuración de la plataforma nativa. Trate esta parte como una lista de verificación, no como una instalación rápida
Un flujo de implementación sólido comienza agregando el plugin o SDK, creando el contexto de captura, limitando los símbolos a los códigos que se utilizan en producción, configurando la interfaz de usuario y solo entonces registrando un escuchador de escaneo. Esa secuencia se destaca en la guía de Cordova de Scandit para SparkScan, y coincide con cómo las integraciones de escáneres profesionales mantienen las aplicaciones híbridas mantenibles, como se describe en Guía del desarrollador de Scandit para escaneo de códigos de barras con CordovaSi su aplicación sigue siendo híbrida en el nivel de arquitectura, consulte esta guía Desarrollo de aplicaciones híbridas de Cordova Comience con el flujo de integración

Comience con el flujo de integración
Una característica de escáner se ve mejor cuando decides estos items primero:
- ¿Qué debe hacer la aplicación después de una lectura exitosa?
- ¿Qué existe como fallback cuando la cámara no puede ser utilizada?
- ¿Qué debe hacer la aplicación después de una lectura exitosa.
- ¿Qué tipos de códigos de barras debe aceptar la aplicación?
¿Se trata de una acción de pantalla completa o parte de un flujo de trabajo incorporado?
Pasos de instalación de Cordova
Para una configuración tradicional de Cordova utilizando el plugin de escáner de códigos de barras común, el punto de partida es el comando de instalación estándar documentado por el paquete:
cordova plugin add cordova-plugin-barcodescanner
Una secuencia típica de configuración del proyecto se ve así:
cordova create barcodeScannerApp
cd barcodeScannerApp
cordova platform add android
cordova platform add ios
cordova plugin add cordova-plugin-barcodescanner
cordova build android
cordova build ios
Esa secuencia es simple, pero no te detengas allí. Construye inmediatamente después de la instalación del plugin para detectar problemas de dependencias nativas antes de conectar la interfaz de usuario code. Si la construcción falla, resuelve eso primero.
Configuración nativa que suele romperse primero
En iOS, el acceso a la cámara debe declararse correctamente en las configuraciones de proyecto nativo. Si la descripción de uso de la permiso falta o es vaga, el escáner no se comportará como una característica funcional para los usuarios. Agrega una descripción de privacidad de cámara clara en Info.plist que explique por qué la aplicación necesita la cámara.
En En, review manifest entries and plugin-related permissions after install. The plugin may add what it needs, but older projects often contain accumulated config changes, custom Gradle settings, or plugin overlap that causes build warnings or runtime confusion. Don’t assume the manifest is clean just because the plugin installed successfully.
Utilice esta lista de verificación rápida:
- Verifique las versiones de la plataforma: Proyectos Cordova más antiguos a menudo llevan paquetes de plataforma desactualizados.
- Revisa las solicitudes de permiso: La redacción y el momento importan para la confianza del usuario.
- Prueba en un dispositivo real temprano: Los emuladores no te dirán suficiente sobre el comportamiento de la cámara.
- Mantén el alcance del escáner estrecho: Habilita solo los tipos code que tu flujo de trabajo admite.
Si su escáner necesita solo uno o dos formatos, configure para esos primero. La escaneación amplia parece flexible, pero a menudo hace que el depurado sea más lento porque cada etiqueta ininteligible se vuelve ambigua.
Para los desarrolladores junior, la lección clave es esta: la instalación no es solo una instrucción de terminal. Es la alineación del proyecto nativo. Si Android e iOS no se configuran intencionalmente, la capa de JavaScript no te salvará.
Implementar el Escáner en su aplicación Code
Una vez instalado el plugin y compilado la aplicación, mantenga la primera implementación básica. Coloque la acción de escaneo detrás de un botón, registre el resultado completo y pruebe el flujo de llamada de retorno antes de diseñar una interfaz de usuario pulida alrededor de él.
El patrón de escaneo Cordova común utiliza el método del plugin. scan(success, fail) El estilo de llamada es antiguo, pero es confiable en código legado y fácil de envolver más tarde si su aplicación ha pasado a promesas o abstracciones de TypeScript. Si desea un modelo mental más claro de cómo las llamadas web code invocan nativas code en estos proyectos, esta explicación de cómo code conecta web y nativas code le ayudará, incluso si todavía está codificando en Cordova hoy. cómo Capacitor conecta la web y la code nativa ayuda, incluso si todavía estás codificando en Cordova hoy.

Ejemplo de JavaScript puro
Aquí hay una implementación mínima para una aplicación Cordova más antigua:
<button id="scan-button">Scan barcode</button>
<div id="scan-result"></div>
document.addEventListener('deviceready', function () {
var button = document.getElementById('scan-button');
var resultEl = document.getElementById('scan-result');
button.addEventListener('click', function () {
cordova.plugins.barcodeScanner.scan(
function (result) {
if (result.cancelled) {
resultEl.textContent = 'Scan cancelled';
return;
}
resultEl.textContent =
'Text: ' + result.text +
' | Format: ' + result.format;
},
function (error) {
resultEl.textContent = 'Scan failed: ' + error;
}
);
});
});
This does three useful things. It waits for devicereadySi su proyecto utiliza TypeScript, defina la forma del resultado usted mismo para que el resto de la aplicación pueda consumirlo de manera limpia:
Ejemplo de JavaScript plano
Si su proyecto utiliza TypeScript, defina la forma del resultado usted mismo para que el resto de la aplicación lo consuma limpiamente:
interface BarcodeScanResult {
text: string;
format: string;
cancelled: boolean;
}
function scanBarcode(): void {
cordova.plugins.barcodeScanner.scan(
(result: BarcodeScanResult) => {
if (result.cancelled) {
renderStatus('Scan cancelled');
return;
}
handleScannedCode(result);
},
(error: unknown) => {
renderStatus(`Scan failed: ${String(error)}`);
}
);
}
function handleScannedCode(result: BarcodeScanResult): void {
renderStatus(`Scanned ${result.format}: ${result.text}`);
if (!result.text) {
renderStatus('Empty scan result');
return;
}
lookupItemByCode(result.text);
}
function renderStatus(message: string): void {
const el = document.getElementById('scan-result');
if (el) el.textContent = message;
}
function lookupItemByCode(code: string): void {
console.log('Lookup code:', code);
}
Esta versión separa la escaneación de la lógica empresarial. Eso importa porque el plugin de escáner debe capturar solo la entrada. La validación, la búsqueda y la navegación pertenecen a otro lugar.
¿Qué hacer con el resultado de la escaneo?
Un buen flujo posterior a la escaneo es normalmente uno de estos:
- Flujo de búsqueda: Usar el texto escaneado para recuperar un registro de producto, orden o activo.
- Flujo de validación: Comparar el valor escaneado con un valor esperado code ya en pantalla.
- Flujo de navegación: Ruta al usuario en una tarea relacionada con el elemento escaneado.
- Flujo de captura: Guardar el valor localmente para sincronizarlo más tarde.
No dejes que el callback del escáner se convierta en un vertedero para llamadas a API, actualizaciones del DOM, análisis y navegación. Pasadle el valor rápido.
Además, registre el resultado bruto durante la prueba inicial. Incluso si su interfaz de usuario de producción solo necesita textel valor devuelto format es útil para depurar etiquetas no coincidentes. Si operaciones dice “el escáner no puede leer este code,” el formato de datos a menudo le dice si el problema es el tipo de código de barras, no la calidad del código de barras.
Pruebas y depuración de errores comunes
La mayoría de los problemas con escáneres de código de barras de Cordova no provienen del escaneo API en sí. Proviene de la frontera entre la interfaz de usuario web, las vistas nativas y los permisos del dispositivo. Aquí, las demostraciones limpias se convierten en informes de errores confusos.
El problema más difícil de diagnosticar es el error de renderizado de Android que aparece durante Capacitor las migraciones o los conjuntos mixtos Cordova-Capacitor. Un desarrollador en el problema #1213 de Capacitor describió simplemente: “Probé este plugin en mi capacitor aplicación pero parece que el escáner está detrás de la aplicación”, y la solución requiere hacer el fondo del visor web nativo transparente junto con los cambios de transparencia de DOM, que los tutoriales de Cordova estándar normalmente no cubren, como se documenta en la discusión del problema de renderizado de Android CapacitorSi está depurando una migración híbrida, este manual le ayudará depurando aplicaciones Capacitor Pruebas y depuración de errores comunes
La vista previa de Android detrás del bug del app
Síntoma
Comienza a escanear. Los permisos parecen estar bien. No hay un crash obvio. Pero la vista previa de la cámara aparece invisible, bloqueada o "detrás" de la interfaz de usuario de la aplicación.
Causa
La vista de escaneo nativa y la vista web se superponen de manera diferente a lo que esperaba el plugin original de Cordova. En Android en configuraciones de estilo Capacitor, el fondo de la vista web puede permanecer opaco, por lo que la vista previa nativa existe pero se mantiene oculta debajo de ella.
Solución
Aplica un conjunto de vistas transparentes en ambos lados:
- Lado nativo: Establece el fondo de la vista web en transparente.
- Lado web: Quitar fondos opacos de los elementos del contenedor que se encuentran sobre la vista previa del escáner.
- Lado de la disposición: Verifique los contenedores de página de marcos por defecto para colores de fondo predeterminados.
- Prueba de lado: Valida en un dispositivo Android físico ya que el comportamiento de la interfaz puede ser engañoso en entornos de desarrollo.
Esta es la falla que hace que los desarrolladores crean que el plugin está roto cuando en realidad es un problema de composición de vistas.
Fallas de permisos y falsos negativos
Los permisos fallan de maneras que parecen ser errores del escáner.
Si el usuario deniega el acceso a la cámara, su llamada de retorno puede mostrar un error genérico o el escáner no se puede presentar como se espera. Maneja la denegación de permisos como una rama normal en la interfaz. Informa al usuario sobre lo que sucedió y cómo volver a intentarlo después de habilitar el acceso. En iOS, especialmente, el texto de permisos poco claro crea desconfianza antes de que el usuario vea el escáner.
Unos pocos hábitos ayudan:
- Desencadena la escaneo desde una acción de usuario clara: Las solicitudes de permisos se sienten menos sospechosas.
- Muestra una entrada de respaldo: La entrada manual mantiene el flujo en marcha.
- Pruebas denegadas luego reintenta rutas: Muchas veces solo se prueba el camino feliz una vez.
Problemas de construcción y pruebas de dispositivo
Algunas fallas solo se muestran en ciertos entornos.
| Problema | Causa probable | Solución práctica |
|---|---|---|
| El escáner se abre pero no devuelve resultados útiles | Formato de código de barras no soportado o inesperado | Prueba con etiquetas conocidas que coincidan con tu caso de uso configurado |
| Build breaks after plugin install | Desplazamiento de plataforma o dependencia en un proyecto más antiguo | Reconcilie los paquetes de plataforma antes de cambiar la aplicación code |
| Funciona en una caja de app pero no en otra | Ver interferencia de CSS o capas | Resta la pantalla a un diseño mínimo y agrega estilos de regreso gradualmente |
| El comportamiento del emulador es engañoso | La simulación de cámara no refleja la realidad del dispositivo | Prueba en hardware de Android y iPhone físico temprano |
Resta la página a un botón y un elemento de resultado cuando se depure. Si el escáner funciona allí, tu problema es usualmente la disposición o la caja de app code, no el plugin.
Consejos de rendimiento y migración a Capacitor
Un escáner de códigos de barras puede decodificar correctamente y fallar al usuario en la práctica. El problema suele aparecer como retraso, parpadeo, interferencias en la vista de la cámara, o una pantalla de Android que se comporta de manera diferente en dispositivos del mismo conjunto de pruebas.
Incidentes antiguos de Cordova, el decodificador a menudo no es el punto débil. La vista de la web, la capa de capas y la code que reacciona a los resultados de escaneo suelen causar más problemas que la reconocimiento de códigos de barras en sí mismo.
Comienza manteniendo la pantalla de escaneo estrecha en alcance. Si la pantalla está destinada a escanear etiquetas de inventario, deja que escanee etiquetas de inventario. Los filtros adicionales, paneles animados y actualizaciones de estado amplias agregan trabajo de redibujo justo donde la renderización de Android webview ya es frágil.
A unos cambios pueden dar resultados rápidos:
- Limitar formatos de códigos de barras aceptados si su plugin lo soporta. Esto reduce los falsos lectores y facilita la cobertura de pruebas de razonamiento.
- Mantenga la lógica de escaneo posterior corta. Analice, valide y actualice la parte más pequeña posible de la interfaz de usuario.
- Bloquee lecturas duplicadas durante un momento. Algunos dispositivos dispararán el mismo resultado varias veces antes de que el usuario mueva la cámara.
- Diseñe la entrada manual en el flujo. Etiquetas dañadas, iluminación deficiente y empaquetado reflectante aún ocurren en entornos en vivo.
- Mantenga de cerca el costo de repintar Android. La cámara previa puede verse afectada por sobrecargas de elementos, transiciones CSS y componentes superpuestos dentro de un navegador web de Cordova.

A un camino de migración práctico a Capacitor
La migración más limpia de Cordova a Capacitor se realiza en etapas, no de manera heroica. Los equipos se meten en problemas cuando intercambian el contenedor de la aplicación, el plugin de escáner, el flujo de permisos y las capas de interfaz de usuario en una sola pasada, y luego no pueden determinar qué cambio causó el error.
Use este orden en su lugar:
-
Verificar plugins actuales
Liste todos los plugins de Cordova y marquéalos como activos, reemplazables o de riesgo, ya que dependen del comportamiento de plataforma más antiguo. -
Desplace la caja de la aplicación primero
Ejecuta la aplicación web existente dentro Capacitor antes de reemplazar el escáner code. Eso separa problemas del contenedor de problemas del plugin. -
Conservar plugins de Cordova durante una transición corta si es necesario
La compatibilidad temporal a menudo es más segura que reescribir el escáner, el acceso a archivos y el manejo de permisos al mismo tiempo. -
Sustituya piezas de escáner frágiles temprano
Antiguos plugins que dependen de capas personalizadas, comportamiento Android no documentado o manejo de cámara desactualizado deben estar cerca de la parte superior de la cola.
El bug de la vista previa de la cámara de Android merece una atención especial porque desperdicia mucho tiempo de depuración. He visto pantallas de escáner fallar porque la vista previa nativa se encuentra detrás del webview, se recorta en los bordes o se renderiza negro en dispositivos Android específicos. En ese punto, el plugin de código de barras se culpa primero, incluso cuando la composición de vistas es el problema subyacente.
Trátalo como una investigación de renderizado, no solo una investigación de escáner. Elimina las capas de sobreimpresión decorativa. Reduce la página a la vista previa, un trigger y un campo de resultado. Si la vista previa se vuelve estable después de eso, el problema suele ser la estructura de la pantalla o el CSS, no la decodificación.
Esto es también donde una migración a Capacitor comienza a justificarse. Capacitor no elimina todos los errores de cámara, pero suele darte una frontera más limpia entre el manejo de vistas nativas y la interfaz de usuario web code. Para el escaneo de códigos de barras, @capgo/preview-de-cámara muestra una alimentación de cámara en vivo como una capa de sobreimpresión nativa con controles personalizables, por lo que puedes decodificar frames en JavaScript sin que la vista previa esté detrás del webview. Para el escaneo empresarial en dispositivos Zebra, @capgo/capacitor-zebra-datawedge gestiona perfiles de DataWedge y triggers de escaneo. Para flujos de trabajo de etiquetas NFC, @capgo/capacitor-NFC maneja la descubierta, lectura y escritura de etiquetas nativas en iOS y Android.
Cordova proyectos tienden a romperse debido a la edad de los plugins, el desplazamiento de plataforma y suposiciones ocultas dentro de integraciones más antiguas. Los proyectos Capacitor exponen diferentes problemas, principalmente alrededor del manejo de ciclo de vida y capas nativas, pero esas fallas son más fáciles de rastrear porque el lado nativo es más explícito.
If sucede que su escáner de Cordova actual solo funciona después de una pila de arreglos específicos del dispositivo, detenga la adición de parches. Estabilice la pantalla de escaneo, confirme si el problema de visor de Android realmente es un problema de capas de visor web y luego migre en pasos controlados. Ese camino es más lento durante una semana y más rápido para el resto del proyecto.