¿Qué es un SDK móvil de todos modos?. Esta es una serie de blogs de varias partes sobre… | por alanb

Esta es una serie de blogs de varias partes sobre SDK móviles. Describiré los SDK móviles desde un punto de vista integral y responderé todas las preguntas candentes que pueda tener sobre los SDK móviles, que incluyen:

  • ¿Qué son los SDK móviles, cómo se usan, por qué las personas los crean y por qué son importantes para la economía móvil?
  • Casos de uso comunes para SDK en aplicaciones móviles
  • ¿Cómo se implementan los SDK en las aplicaciones móviles?
  • Limitaciones de la plataforma y el marco y otros desafíos que enfrentan los desarrolladores al implementar SDK móviles
  • Costos ocultos de implementar y actualizar manualmente los SDK móviles en las aplicaciones.
  • ¿Cuáles son las consideraciones de seguridad de implementar SDK?
  • Formas nuevas y automatizadas de acelerar las implementaciones a través de la automatización que aceleran su uso y eliminan el trabajo innecesario

Un kit de desarrollo de software móvil (SDK) es un conjunto de herramientas de desarrollo de software que los desarrolladores usan e implementan para ofrecer nuevas capacidades de terceros en una aplicación móvil utilizando las API publicadas por el proveedor de servicios. El método tradicional para implementar un SDK móvil requiere que los desarrolladores de dispositivos móviles modifiquen el código fuente de la aplicación de acuerdo con las instrucciones proporcionadas por un proveedor de servicios externo (también conocido como «proveedor de SDK»). Me referiré a este proceso como implementación SDK ‘manual’, porque para entregar con éxito el nuevo servicio en la aplicación, uno o más desarrolladores móviles deben modificar el código fuente de la aplicación línea por línea o ‘a mano’.

Los SDK son creados y publicados por empresas de todos los tamaños, desde empresas emergentes de Silicon Valley hasta empresas importantes como Facebook, Amazon, Google, Microsoft y Alibaba, para servicios que cubren infraestructura de back-end, publicidad móvil, pagos móviles, seguridad de aplicaciones móviles y todo en el medio.

En aras de la simplicidad, nos referiremos a todos ellos como «proveedores de SDK». Estas organizaciones crean SDK y los dirigen a desarrolladores móviles y editores de aplicaciones, quienes integran el SDK en el código fuente de una aplicación móvil existente durante el proceso de desarrollo de la aplicación.

Hay miles de SDK móviles (16.842 según Web programable).

Crecimiento SDK desde 20015. Fuente: Programable Web
Fuente: Web Programable

Todas las aplicaciones del planeta contienen SDK y desempeñan un papel fundamental en el funcionamiento de las aplicaciones. La empresa de análisis de SDK SafeDK publica un informe semestral sobre SDK y, durante los últimos años, la cantidad promedio de SDK para aplicaciones B2C (es decir, «aplicaciones de consumo») se ha mantenido alrededor 18.2 SDK por aplicación. Para aplicaciones B2E (es decir, aplicaciones «empresariales»), son alrededor de 12 SDK por aplicación. Para aquellos de ustedes que se preguntan por qué las aplicaciones de consumo tienen más SDK que las aplicaciones empresariales, simplemente sigan el camino del dinero. Las aplicaciones para el consumidor suelen descargarse y monetizarse de forma gratuita a través de anuncios y pagos dentro de la aplicación. Ambos requieren, ¡lo has adivinado! — SDK.

Decir que una ‘aplicación móvil’ es una colección de SDK y API de terceros empaquetados junto con la lógica comercial de la aplicación no es una exageración. Casi todas las tareas que ha completado en una aplicación móvil fueron habilitadas por un SDK, ya sea directa o indirectamente. hay ilimitadas Categorías SDKincluidos SDK para autenticación, inicio de sesión único (SSO), MFA, gestión y distribución de aplicaciones, rendimiento de aplicaciones, análisis, mensajería, chatbots conversacionales, cifrado de datos, automatización de marketing, participación, encuestas, anuncios móviles, pagos y mucho más.

Interactúas con los SDK todos los días, lo sepas o no. Los SDK están detrás de escena cuando pides un café con leche de Starbucks, depositas un cheque usando la aplicación móvil de tu banco, pagas a un amigo usando Venmo, buscas un restaurante en Yelp, creas un emoji con cara de perro en Snapchat o pagas de más por un par. de zapatillas rojas de Prada en Ebay, y recibe un anuncio de zapatillas extrañamente similar de Balenciaga al día siguiente.

En todos los casos (y millones más), los SDK móviles hicieron posible la transacción, la experiencia o la interacción.

Los SDK móviles son necesarios porque los desarrolladores de aplicaciones móviles no pueden crear todos los servicios que la aplicación o sus clientes requieren de manera inmediata. No existe una capa estándar o de middleware predefinida en la pila de herramientas de desarrollo móvil que permita que una aplicación descubra, se conecte y consuma nuevos servicios o API por sí misma. Si un desarrollador no creó explícitamente la capacidad de interactuar con un servicio de terceros en el código fuente de la aplicación, entonces ese servicio simplemente no existe (en lo que respecta a la aplicación).

Imagínese si fuera el desarrollador de una aplicación para compartir viajes. Cuando se sentó por primera vez para crear la aplicación, podría esbozar los componentes principales:

  • Una forma de iniciar sesión a través de cuentas de redes sociales;
  • Una forma de pagar el viaje;
  • Un sistema de mapeo para mostrar los autos cercanos;
  • Un rastreador de errores para recibir alertas si la aplicación falla.

Y eso es solo el comienzo de la lista. No tendríamos Uber y Lyft hoy si los equipos de desarrollo tuvieran que escribir su propio software de autenticación, pagos y ubicación. Afortunadamente, otras compañías (los llamamos «proveedores de SDK», ¿recuerdas?) ¡hacen eso por ellos!

Entonces, volviendo a nuestra pequeña lluvia de ideas, podría investigar un poco y descubrir que:

  • Facebook proporciona un excelente SDK de autenticación;
  • Stripe tiene un increíble SDK de pagos;
  • Google tiene un buen SDK de mapeo, y
  • Bugsnag tiene un excelente SDK de informes de fallas.

Los SDK son específicos para cada plataforma o sistema operativo, y existen variantes del SDK para cada sistema operativo y/o marco al que pretende llegar el servicio. El contenido del paquete del SDK puede variar según factores como: el tipo de servicio, las capacidades nativas del sistema operativo, el marco utilizado para desarrollar la aplicación, así como el nivel de madurez del SDK.

En términos generales, los SDK suelen incluir alguna combinación de los siguientes elementos (no todos los SDK incluyen todos los elementos siguientes):

  • Las API del proveedor de SDK.
  • Guía de referencia de la API: un documento o sitio web que contiene la información necesaria para trabajar con la API de los proveedores de SDK, como las funciones, los métodos, las clases, los tipos de retorno, la sintaxis, las convenciones de nomenclatura, los argumentos y los requisitos de pedido; a veces incluye ejemplos hipotéticos. .
  • Requisitos de autenticación: incluidas las claves API y los tokens o cookies de autenticación, así como la secuencia de autenticación, la validación, las URL de redireccionamiento, los requisitos de autorización, los códigos de error, los requisitos de seguridad (p. ej., MFA, cifrado, secretos).
    Esta parte es absolutamente crucial para cualquier implementación de SDK porque se debe establecer una relación de confianza entre la aplicación móvil y el servicio (para garantizar que las máquinas o las personas que realizan las solicitudes de conexión sean legítimas, no maliciosas y que los niveles de acceso, controles y privilegios están establecidos)
  • Bibliotecas nativas y/o no nativas
  • «Complementos» para llegar a marcos no nativos o bibliotecas no nativas (a veces)
  • Código de ejemplo (a veces)
  • Información de depuración (a veces)
  • Elementos de la interfaz de usuario o lógica comercial adicional (a veces)

Hay dos lados en cada implementación de SDK: el aplicación movil y el Servicio que la aplicación móvil desea conectarse o consumir. Pero no importa de qué lado se siente, un SDK es un medio para lograr un fin.

El proveedor de SDK ve el SDK como un mecanismo de distribución de costo relativamente bajo para integrar su servicio dentro de aplicaciones que no son de su propiedad (pero que usan sus clientes objetivo). Es una forma sencilla de llegar a un gran número de suscriptores con un esfuerzo relativamente bajo. Gran parte del trabajo corre a cargo de los desarrolladores de aplicaciones móviles que implementan el SDK.

En la otra cara de la moneda, los desarrolladores de aplicaciones móviles ven los SDK como formas de ofrecer nuevas capacidades o funciones en su aplicación móvil sin crear la funcionalidad desde cero. Nuevamente, ¿por qué crear sus propios algoritmos de mapeo patentados cuando puede implementar los SDK de mapeo de Google para usar los suyos?

Los SDK son una forma clave en que los desarrolladores móviles crean nuevas capacidades en sus aplicaciones, y antes de que apareciera Appdome, la ÚNICA forma de implementar un SDK móvil era modificar el código fuente de la aplicación, línea por línea. Es un proceso laborioso y lento que involucra muchas tareas repetitivas y desarrollo de prueba y error. Y este proceso debe repetirse a lo largo de los ciclos de vida de la aplicación para cada SDK dentro de la aplicación.

Para implementar cualquier servicio nuevo en una aplicación, los desarrolladores móviles deben formular su propio modelo mental sobre cómo modificar el código fuente de la aplicación para consumir el nuevo servicio a través de sus API. Para hacer esto, deben comprender todos los componentes de la aplicación móvil (la lógica, la estructura, las funciones de la aplicación y las complejas relaciones entre todo lo anterior). Y también deben entender cómo funciona el servicio del proveedor de SDK. Este proceso conlleva bastante subjetividad e interpretación. También manténgase en Tenga en cuenta que muchas aplicaciones son creadas por equipos de desarrolladores, cada uno de los cuales escribe una parte del código, lo que significa que no todos los desarrolladores conocen cada parte de la aplicación por dentro y por fuera.

Estén atentos a la próxima entrega de esta serie de blogs, donde analizaré los detalles de lo que realmente es un SDK y describiré los pasos necesarios para implementar un SDK en una aplicación móvil. También hablaré de los principales desafÃos y peligros (cosas que el proveedor de SDK probablemente no le dirá), y cómo puede solucionarlos o evitarlos por completo. O, como mínimo, estará más informado sobre en qué se está metiendo cuando emprenda un nuevo proyecto de SDK.

¡Paz!

Alan

¿Que te ha parecido?

Deja un comentario