Cómo construir una aplicación de criptografía móvil y asegurar su estabilidad Los comerciantes de criptomonedas modernos cada vez más eligen los teléfonos inteligentes como su principal herramienta - de acuerdo con los datos de la industria, más del 60% de las transacciones se realizan a través de dispositivos móviles. Esto requiere que los desarrolladores creen no solo aplicaciones visualmente atractivas, sino plataformas de negociación totalmente funcionales, seguras y de alta velocidad, donde incluso los errores menores pueden conducir a consecuencias graves (desde la visualización incorrecta del saldo hasta la pérdida de fondos). La construcción de una aplicación de comercio de criptografía móvil no se trata sólo de portar una interfaz web a una aplicación.Es un desafío de ingeniería independiente con muchos matices.Los usuarios esperan comerciar de forma rápida, conveniente y segura, sin tener que entender los detalles técnicos. Las principales tendencias que forman el mercado de comercio de criptomonedas móviles incluyen: y y y Un cambio de la web a la móvil: las interfaces están adoptando el diseño móvil primero, y las demandas de rendimiento están aumentando. La demanda de experiencias nativas: las aplicaciones deben ser rápidas, seguras y sentirse "nativas" para el sistema operativo. En este artículo, compartimos cómo el equipo de EVEDEX y los desarrolladores de CleverPumpkin integraron un SDK TypeScript (originalmente construido para la web) en aplicaciones nativas para mantener una lógica de negocio unificada en todas las plataformas. Why We Chose SDK and the Challenges We Faced La versión web de EVEDEX ya utilizó un SDK de Exchange personalizado, una biblioteca TypeScript que conecta la API de intercambio en el lado del cliente.A lo largo del tiempo, ha desarrollado una lógica empresarial completa, incluyendo la agregación de datos de mercado, la firma de pedidos y la validación. El objetivo principal era garantizar un comportamiento consistente en todas las plataformas. Nuestro objetivo era evitar la duplicación de la lógica, reducir el número de errores y acelerar el desarrollo. Esto significó: integrar el SDK web existente en aplicaciones móviles nativas. Sin embargo, el SDK fue escrito en TypeScript y no fue diseñado originalmente para usar fuera de un navegador. y y “Hemos discutido todas las opciones de implementación posibles en detalle.Teniendo en cuenta el contexto completo, decidimos intentar integrar el SDK TypeScript completo en las aplicaciones nativas.Este era un nuevo territorio para nosotros, pero estábamos listos para hacer frente a esta tarea no convencional”. Alexander Kiaykin, CTO de CleverPumpkin “Hemos discutido todas las opciones de implementación posibles en detalle.Teniendo en cuenta el contexto completo, decidimos intentar integrar el SDK TypeScript completo en las aplicaciones nativas.Este era un nuevo territorio para nosotros, pero estábamos listos para hacer frente a esta tarea no convencional”. - El Alexander Kiaykin, CTO of CleverPumpkin The first step was embedding a fully-fledged JavaScript engine into the app. On iOS, we had access to the built-in JavaScriptCore, but for Android, we had to look for an alternative. We chose , un motor JS independiente y de código abierto. LiquidCore To ensure smooth interaction with the SDK from the native code, we developed a cross-platform wrapper that facilitated communication between the SDK and the app's business logic. Challenges We Faced: Los retos a los que nos enfrentamos: y y No todos los motores de JS soportan la última sintaxis de ECMAScript: tuvimos que reducir el objetivo de transpilación de TypeScript a una versión de JavaScript compatible con el motor. y y Los motores JS no tienen acceso directo a las capacidades del sistema: cosas como solicitudes HTTP, WebSockets y comunicación de red tuvieron que implementarse en el código nativo. Como resultado, el SDK fue modificado. Ahora utiliza interfaces externas para la lógica de red, las interacciones HTTP y WebSocket se manejan en el lado Swift/Kotlin, mientras que la lógica de procesamiento permanece en JavaScript. Al final, la lógica de negocio permaneció dentro del SDK, y las operaciones de red de bajo nivel fueron delegadas al código nativo. Esto nos permitió preservar la coherencia arquitectónica y acelerar el desarrollo sin comprometer el rendimiento. Wallet Integration: Implementing Deposits and Withdrawals Ningún intercambio de criptomonedas puede operar sin la funcionalidad de depósito y retiro. Nuestro objetivo era hacer este proceso intuitivo y seguro. Para mejorar la comodidad del usuario, añadimos soporte para transferencias de activos flexibles entre redes utilizando el Servicio que permite a los usuarios: LI.FI y y y y Transferencia de activos de una red a otra. Hazlo con solo unos pocos clics, sin buscar puentes manualmente o entender la compleja lógica de las interacciones en cadena. Seleccione la mejor opción en función de las preferencias de precio/velocidad. Decidimos usar intencionalmente Aunque la aplicación está construida utilizando tecnologías nativas, y se utiliza un motor JavaScript separado para las operaciones de SDK, WebView nos permitió integrar rápidamente la interfaz LI.FI sin tener que reimplantar su UI nativamente. WebView Al mismo tiempo, tuvimos que considerar las especificidades de trabajar con carteras criptográficas en un entorno móvil. y , que es el estándar que define cómo las aplicaciones pueden integrarse con las carteras de Ethereum. EIP-1193 (Ethereum Provider JavaScript API) La aplicación móvil soporta varios métodos de conexión: y y y y A través de MetaMask Importar una cartera externa usando una frase de semilla o clave privada. Crear una nueva cartera directamente dentro de la aplicación. Independientemente del método elegido, la aplicación puede servir como proveedor de cartera para la página de depósito. Esto nos permitió reutilizar la interfaz web existente sin necesidad de construir un sistema separado para la aplicación móvil. *: En la fase actual, EVEDEX solo opera con redes compatibles con Ethereum, por lo que no se consideraron estándares alternativos.* nb nb Conclusion and Key Takeaways La integración de un SDK TypeScript en una aplicación móvil nativa resultó ser una tarea no convencional y a veces desafiante, pero nos permitió asegurar un comportamiento consistente en todas las plataformas, eliminar la duplicación lógica, reducir el número de errores y acelerar significativamente el proceso de desarrollo: y y Un SDK web puede ser adaptado para entornos móviles, pero requiere una reconsideración arquitectónica y una correcta descomposición lógica. y y Desconectar la lógica de negocio de las operaciones a nivel del sistema es esencial para una arquitectura sostenible. En nuestro caso, el código nativo gestiona las operaciones de red y la comunicación de WebSocket, mientras que el SDK se centra únicamente en la lógica de negocio. y y El uso de estándares como EIP-1193 ayuda a mantener la compatibilidad de la cartera y simplifica la implementación. y y La combinación de código nativo, un motor JavaScript y WebView nos dio el equilibrio correcto entre la velocidad de desarrollo, la flexibilidad y la experiencia del usuario. y y “No fue fácil, pero ahora sabemos exactamente cómo incorporar un SDK TypeScript en una aplicación criptográfica nativa. Esto no solo aceleró el desarrollo sino que también nos dio una base arquitectónica para el futuro”. — Vlad Komissarov, CTO de EVEDEX “No fue fácil, pero ahora sabemos exactamente cómo incorporar un SDK TypeScript en una aplicación criptográfica nativa. Esto no solo aceleró el desarrollo sino que también nos dio una base arquitectónica para el futuro”. — Vlad Komissarov, CTO at EVEDEX El desarrollo de la aplicación móvil EVEDEX no fue sólo otro lanzamiento de producto, fue un verdadero experimento tecnológico que ahora puede servir como punto de partida para otros equipos que buscan soluciones no convencionales en el mundo de la criptografía. Escrito por: Escrito por: Vlad Komissarov, CTO de EVEDEX Alexander Kiaykin, CTO de CleverPumpkin
