Empezar por el sistema al otro lado
Para presupuestar con criterio necesitamos más que el nombre de la plataforma: su interfaz documentada, un entorno de pruebas, condiciones de acceso y operaciones que debe realizar la aplicación.
Integrarse con una API disponible es distinto de intentar conectar un sistema sin interfaz adecuada. La falta de documentación, permisos o funciones del servidor debe identificarse antes del desarrollo.
Trabajamos mediante acceso autorizado e interfaces admitidas. Una aplicación a medida no elimina las licencias ni las condiciones de uso de terceros.
Integraciones que podemos definir
Cuentas y solicitudes autenticadas
Implementar el acceso y la autorización adecuados. Definir qué sucede al caducar una sesión, revocarse un permiso o intentar una operación no autorizada.
Datos empresariales y sincronización
Conectar registros de clientes, tareas, inventario u otros datos acordados. Decidir qué sistema es responsable de cada registro y cómo tratar cambios en conflicto o incompletos.
SDK de terceros
Integrar una biblioteca documentada, revisar configuración y compatibilidad e identificar qué aporta a la aplicación. Un SDK también exige revisar permisos y tratamiento de datos.
Notificaciones, cargas y operaciones con cambios de datos
Definir el recorrido completo: inicio, progreso, confirmación y recuperación. Subir un archivo no es igual que consultar datos; una solicitud que modifica información no debe repetirse sin comprobar su resultado.
Integraciones nativas para Flutter
Si Flutter necesita un SDK exclusivo de Android, revisamos la implementación nativa y su comunicación con Dart. Consulta el desarrollo con Flutter para proyectos móviles compartidos.
Hacer comprensibles los fallos
Una integración útil explica qué pasó y qué puede hacer el usuario. No debería convertir todos los errores en una pantalla vacía.
| Situación | Comportamiento que debemos definir |
|---|---|
| No hay red. | Explicar qué acciones quedan bloqueadas y si se puede guardar trabajo localmente. |
| La sesión caducó. | Recuperar el acceso mediante el flujo admitido sin perder datos introducidos innecesariamente. |
| El servicio rechaza una solicitud. | Mostrar un mensaje adecuado y conservar contexto suficiente para investigar. |
| Una solicitud caduca después de modificar datos. | Comprobar el resultado antes de enviar una operación que podría duplicarse. |
| El proveedor modifica una respuesta o su SDK. | Identificar supuestos de compatibilidad y posibles tareas de mantenimiento. |
Estas decisiones forman parte de la especificación. La implementación depende de la API y del servidor, no solo de Android.
Aclarar credenciales y responsabilidades
Una aplicación móvil no es lugar adecuado para ocultar credenciales de administración del servidor. Las operaciones privilegiadas pueden necesitar un componente de servidor con acceso limitado.
Definimos qué configuración vive en la aplicación, qué operaciones pertenecen al servidor y quién administra las cuentas. La primera consulta debe incluir enlaces a documentación y el flujo requerido, sin contraseñas ni tokens de producción.
Los cambios del servidor, paneles y costes recurrentes son partidas aparte salvo que la propuesta los incluya expresamente.
Qué debe incluir una entrega útil
Según el proyecto, puede comprender cambios de código, instrucciones de configuración, correspondencia de campos, supuestos documentados y pruebas de los casos principales de éxito y error.
Si el proveedor ofrece un entorno de pruebas, lo usamos cuando corresponda. Registramos entorno y versión comprobados sin afirmar que esa prueba cubre cualquier cambio futuro.
Para construir una aplicación completa, consulta desarrollo Android a medida. Si se trata de conectar equipos físicos, visita integración con dispositivos Android.
Preguntas frecuentes
¿Pueden conectar una aplicación Android con nuestro CRM o sitio web?
Potencialmente. Envíanos el nombre de la plataforma, el flujo necesario y documentación pública de su API. Debemos confirmar que las operaciones y los permisos estén disponibles.
¿También necesitan acceso al servidor?
Depende. Algunos proyectos pueden usar una API existente; otros requieren cambios del servidor, credenciales o configuración a cargo de tu equipo.
¿Pueden trabajar con un SDK privado de un proveedor?
Sí, si contamos con acceso y licencia adecuados. Necesitamos su documentación, entornos admitidos y una forma de probar sin exponer información confidencial.
¿Puede funcionar una integración sin conexión?
Algunos datos y acciones pueden diseñarse para ello. Debemos definir qué se guarda localmente, qué queda en espera y cómo se concilian los cambios.
¿Pueden reparar una integración existente?
Sí. Describe la operación fallida y cuándo ocurre. Una revisión de depuración puede ser el mejor punto de partida.
Cuéntanos qué debe conectarse
Indica la aplicación, el servicio o SDK y la acción que necesita completar el usuario. Añade un enlace a la documentación si existe.