MapConductorPor qué MapConductor
El código de las aplicaciones con funciones de mapa suele estar fuertemente vinculado a un SDK de mapa específico. Cuando se desea cambiar, la reescritura no se limita solo a lo relacionado con el mapa, sino que afecta también la lógica de la pantalla. MapConductor reemplaza ese vínculo con una sola API común.
01 · Cuál es el problema
Cambian las tarifas y los contratos
El modelo de facturación de la API de mapas cambia. Puede haber situaciones en las que quieres cambiar, pero el código de la aplicación no lo permite.
Escribir la misma función 3 veces
Si usas diferentes SDK de mapas para Android, iOS y Web, el manejo de marcadores y el significado de la cámara no coinciden. Tendrás que discutir las especificaciones 3 veces.
Los valores numéricos no coinciden
Si dejas en manos de las utilidades del SDK la escala a la que se refiere el zoom 14 y la distancia entre dos puntos, habrá variaciones según el entorno. En QA tendrás que decidir cada vez "cuál es el correcto".
Colapso cuando aumenta la cantidad
Cuando los marcadores superan los miles, las operaciones de la cámara se vuelven lentas con una implementación ingenua. Las contramedidas varían según el proveedor y tendrás que reescribir cada vez.
02 · La respuesta de MapConductor
La aplicación solo depende de una API unificada. Los controladores absorben las diferencias por proveedor, y el cambio consiste simplemente en reemplazar los módulos dependientes y los tipos de vista.
Coordenadas y estados en común
GeoPoint, MarkerState y MapCameraPosition tienen el mismo nombre y el mismo significado en las 3 plataformas. No aparecen tipos específicos del proveedor.
El zoom y la distancia coinciden
El zoom se normaliza a una escala común y la distancia, el rumbo y el área se calculan con la propia implementación del SDK. Con la misma entrada, cualquier proveedor devuelve el mismo valor.
Solo pasar el estado
Si pasa „la matriz de los estados que deberían existir ahora“, Core calcula la diferencia con la anterior y refleja en el mapa solo lo necesario. No necesita gestionar por su cuenta la adición, actualización o eliminación.
El problema de la cantidad lo resuelve el SDK
Cuando los marcadores superan los 2000, el motor de renderizado interno cambia automáticamente a teselas raster. Incluso con decenas de miles de elementos, la manipulación de la cámara sigue siendo fluida y el código de la aplicación no cambia ni una sola línea. El valor de referencia se puede cambiar en las opciones de la vista de mapa.
03 · No es un wrapper delgado
Si fuera un wrapper que simplemente llama a los métodos de cada SDK, las posibilidades se limitarían al "SDK con menos funciones". Dado que MapConductor implementa y complementa las funciones que faltan, la apariencia y el comportamiento se mantienen uniformes al cambiar de proveedor.
04 · Beneficios para el equipo
Al intercalar una API común, cambia la naturaleza del código que se puede escribir. El código en el que no aparece el nombre del SDK de mapa permanece tal cual, incluso si se cambia de proveedor o se migra a otra plataforma.
Solo hay que aprender una API
Dado que los conceptos y nombres de los SDK de mapas varían según el proveedor, cada vez que cambie de proveedor o de plataforma tendrá que volver a aprender. Con MapConductor solo hay que aprender una API, que se puede usar con el mismo nombre y significado en Android, iOS y React. Los conocimientos obtenidos en una plataforma son directamente aplicables en otra, y cuando se incorporan personas al equipo no aumenta la cantidad de material que deben leer según el número de proveedores.
Código que no depende del SDK de mapas
GeoPoint y MarkerState son tipos que no pertenecen a ningún SDK de mapas. Construir rutas, determinar si se encuentra dentro de un rango, decidir qué mostrar — esta lógica se puede escribir desacoplada de los tipos del SDK de mapas, por lo que no es necesario reescribirla al cambiar de proveedor. También se puede extraer como una biblioteca los componentes comunes alrededor del mapa, sin tener que crearlos por separado para cada proveedor.
05 · Desde la perspectiva de quien distribuye los datos
Hasta ahora, se ha tratado del lado que incorpora el mapa. El objetivo de MapConductor no es solo la liberación del bloqueo de proveedor, sino también permitir decidir de qué proveedor depender de manera separada de la selección del SDK de mapas.
Terminará usando un SDK comercial
A menos que use mapas completamente abiertos, en la producción terminará usando algún SDK de mapas comercial. Debido a contratos y adquisiciones, a veces solo hay una opción desde el principio. MapConductor es útil en esas situaciones porque no tiene que desechar sus recursos existentes.
Separar el SDK de mapas y los datos
Se asumía que los recursos como datos de mapas, geocodificación y mosaicos se usarían junto con el SDK de mapas del proveedor que los ofrece. Si ambos se pueden separar, por ejemplo, se puede usar el contenido acumulado en ArcGIS sobre la pantalla de otro SDK de mapas.
Solo geocodificación, solo datos
Los proveedores que solo tienen geocodificación o solo datos de campos específicos han tenido una utilización limitada porque no tienen su propio SDK de mapas. Si se pueden separar del lado de la visualización, podrán usarse en cualquier mapa.
06 · Desde la perspectiva de los proveedores de SDK de mapas
Una capa común puede parecer, para los proveedores de SDK de mapas, algo que diluye su propia presencia. MapConductor no está diseñado así. Solo se estandariza la parte que existe en todos los proveedores; las fortalezas de cada empresa se mantienen tal cual hacia afuera.
Clientes del exterior
Cuando varios proveedores pueden manejarse de la misma manera, también pueden ser considerados como candidatos desde aplicaciones creadas con el SDK de otra empresa. Que se baje la barrera para cambiar también actúa en la dirección de debilitar el poder para retener a los clientes existentes, pero a cambio, la razón para ser elegido se convierte en "precio, cobertura y calidad de renderizado" y no en "no se puede cambiar".
No ocultar las fortalezas
Lo que se ha estandarizado son solo las funciones básicas que existen en cada proveedor. Si llama a getMapViewHolder() del objeto de estado, puede obtener la vista de mapa nativa y la instancia de mapa tal cual, por lo que puede escribir directamente funciones que solo tiene ese proveedor con la API de cada empresa. Si fuera un contenedor que lo oculta todo por completo, los factores de diferenciación desaparecerían, pero no es así.
Competir sobre una base común
Después de que los browsers unificaron sus implementaciones en HTML5, comenzaron a competir no por la compatibilidad en sí, sino por la velocidad y las funcionalidades. Con los SDK de mapas ocurre lo mismo: una vez definida una interfaz común, la pregunta será qué tan rápido, preciso y en qué áreas más amplias se puede dibujar sobre ella. Creemos que la estandarización no detiene la evolución de cada SDK, sino que alinea la dirección de la evolución.
07 · Casos adecuados y no adecuados
- Ofrecer la misma experiencia de mapas en múltiples plataformas
- Dejar abierta la posibilidad de cambiar de proveedor en el futuro
- Las representaciones estándar de mapas como marcadores, formas y cámara son el foco principal
- Manejar desde miles hasta decenas de miles de marcadores
- Se requiere consistencia en la visualización de distancias y áreas
- Las representaciones avanzadas específicas de un proveedor en particular son el protagonismo (shaders personalizados, capas exclusivas del proveedor)
- Las funciones dedicadas del SDK en sí son el objetivo, como la navegación turno por turno
- 1 plataforma, 1 proveedor, todo completo, sin cambios previstos.
Sin embargo, se puede usar parcialmente de manera combinada. Como siempre se tiene acceso a las instancias nativas del mapa, es posible una configuración en la que solo las partes especiales se escriben con código específico del proveedor.