ICD Mobile Banking: Historia de desarrollo

Oleg Ivanov, Jefe del Centro de Competencia de Canales de Servicio Remoto, Departamento de Desarrollo de TI, Dirección de Tecnologías de la Información, Banco de Crédito de Moscú (ICD)

Para nosotros, el desarrollo de una aplicación móvil comenzó desde cero, por lo que en este artículo comenzaremos desde el principio: determinando qué es y qué funciones debe tener. Y luego vamos todo el camino, desde comprar nuevos gadgets hasta probar la aplicación para iniciarla. Contaremos la historia del desarrollo de nuestra aplicación con sangrías tecnológicas. Describamos qué problemas encontramos. Desafortunadamente, no podremos cubrir todos los enfoques, principios y soluciones tecnológicas que se utilizaron en el desarrollo de este artículo de revisión, pero nos detendremos en los puntos más interesantes.

Además habrá un énfasis en el desarrollo para iOS. Antes de comenzar, decidamos qué es Mobile Bank.

Un banco móvil es la administración de cuentas bancarias utilizando la aplicación bancaria en un teléfono inteligente (iPhone, etc.), una tableta (iPad, Samsung Galaxy Tab, etc.). Para las operaciones bancarias, se requiere una confirmación de dos pasos utilizando códigos únicos a través de mensajes SMS.

Las principales operaciones bancarias del Mobile Bank:

• uso de productos bancarios (cuentas, tarjetas, depósitos, préstamos, paquetes de servicios, etc.)
• ver saldo de cuenta
• declaración
• pago de facturas por servicios móviles
• pago de servicios de vivienda
• transferir fondos de una tarjeta a otra
• pagos regulares
• reembolso de préstamos
• transferencia de fondos para depositar
• bloqueo de tarjeta de pago
• y otros

Las aplicaciones de banca móvil son aplicaciones de banca por Internet adaptadas para pantallas pequeñas de teléfonos inteligentes y para sistemas operativos (iOS de Apple, Android de Google) instalados en dispositivos móviles. Vale la pena señalar que la gama de modelos de dispositivos que ejecutan el sistema operativo Android es muy amplia: Samsung, LG, Xiaomi, Huawei, etc., lo que complica el desarrollo y el soporte de la aplicación para Android.

Fuente - MKBMobile 1.0

El proyecto de aplicación de Mobile Bank fue transferido a nuestro equipo desde una compañía externa, fue escrito en el Objetivo C.

Así es como se veía el proyecto a través de los ojos del usuario:





Este proyecto se ha convertido en una startup y una prueba de nuestras capacidades. Nuestro equipo tuvo pocas experiencias de desarrollo para la plataforma móvil iOS, pero decididamente emprendimos el proyecto.

Por donde empezar Cuando pensamos en desarrollar para iOS, lo primero que necesitamos:

1. Necesita iMac

Apple es famosa por el alto precio de sus productos. Pero ahorrar no vale la pena: ¡esta es la velocidad de su desarrollo!

Una configuración aproximada y óptima que nos conviene:

• Procesador Intel Core i5 de séptima generación con velocidad de reloj de 3.8 GHz (Turbo Boost de hasta 4.2 GHz)
• 32 GB DDR4 2400 MHz
• Fusion Drive de 2 TB
• GPU Radeon Pro 580 con 8 GB de VRAM

El costo aproximado de tal máquina es de 190,000 rublos.

Existe una opinión: los programadores necesitan iMac Pro. Esto es así :) Pero el precio por ellos muerde, y si su empresa está lista para comprarlos, esto aumentará la velocidad de su desarrollo y, por supuesto, aumentará el nivel estético de su oficina.

2. Necesita dispositivos iOS

"¿Cuánto y cuál?" - surge la primera pregunta. Todo depende de tu aplicación.
Si su aplicación solo es compatible con iPhone, al menos 2 tamaños diferentes son pequeños (por ejemplo, iPhone SE) y grandes (por ejemplo, iPhone 8 Plus).

Si su aplicación también es compatible con iPad, necesita un iPad.

Luego viene el sistema operativo: sus versiones. Si su aplicación admite la versión mínima, por ejemplo, comenzando con iOS 8.0, debe abastecerse en el dispositivo con cada número de serie de iOS y recordar "preservar" (no actualizar) esta versión en el dispositivo y controlar la aparición de nuevas versiones de iOS, sin olvidar seleccionar un conjunto para él dispositivos.

Por supuesto, por primera vez puedes sobrevivir con los simuladores de Xcode, pero los dispositivos físicos imponen sus propias colisiones que no aparecen en los simuladores.

Si no desea tener su propia granja de dispositivos, puede mirar hacia las partes de las empresas que ofrecen este servicio: AWS Device Farm, Xamarin Test Cloud, etc.

Como ya se mencionó, nuestra aplicación es compatible tanto para iPhone como para iPad. Al momento de escribir, nuestra propia (!) Granja es de unos 30 dispositivos de diferentes tipos y versiones del sistema operativo.

3. Debe decidir el enfoque de desarrollo para iOS (nativo o alternativo).

Probamos las siguientes opciones de desarrollo alternativas para iOS:

Interfono / Cordova

PhoneGap fue creado originalmente por Nitobi. En 2011, Adobe adquirió Nitobi y la marca PhoneGap. Adobe luego transfiere una versión de PhoneGap, llamándola Cordova, a la Fundación Apache, dejando la marca PhoneGap y el producto en sí. Como resultado, Cordova puede verse como un motor bajo el capó de PhoneGap (así como algunos otros marcos híbridos). PhoneGap, a su vez, agrega sus propias características adicionales a las capacidades de Cordova.

PhoneGap es en muchos aspectos muy similar a Ionic. También ofrece a los desarrolladores la capacidad de crear aplicaciones multiplataforma utilizando tecnologías web, y también se basa en Apache Codova. Sin embargo, PhoneGap no está vinculado a ningún marco Javascript específico, por lo que los desarrolladores tienen más opciones sobre qué y cómo crearán sus aplicaciones.

Por desgracia, PhoneGap usa WebView (que es bastante lento en iOS), por lo que las cosas no siempre son brillantes con la velocidad de las aplicaciones creadas sobre la base de este marco.

Xamarin

Fundada en 2011, Xamarin, la familia de productos Xamarin, fue adquirida por Microsoft después de cinco años de existencia. Hoy en día, los productos Xamarin presentan un enfoque muy interesante para desarrollar aplicaciones móviles multiplataforma en el mercado: las aplicaciones están escritas en C #, luego Xamarin las compila en una aplicación nativa para iOS o Android, mientras que Xamarin usa Mono como tecnología subyacente, en lugar de multiplataforma. y se proporciona Los desarrolladores de Xamarin dicen que las aplicaciones resultantes usan la API de plataforma nativa para la cual se compila la aplicación, por lo que el comportamiento de la aplicación resultante no es diferente del comportamiento de cualquier otra aplicación en la misma plataforma. El desarrollo, por cierto, se puede hacer usando Visual Studio (lo cual no es sorprendente).

A pesar del hecho de que la mayoría del código del proyecto se puede usar sin cambios en cada una de las plataformas móviles compatibles, sin embargo, algunos fragmentos deberán escribirse específicamente para la versión de la aplicación para iOS y Android.

Pero tales enfoques dan la llamada aplicación "híbrida".

Ventajas de opciones alternativas:

• multiplataforma (después de haber creado una aplicación, se puede exportar para cualquier sistema operativo);
• El tiempo de desarrollo es menor que el nativo.

Contras de alternativas:

• funciona más lento que las aplicaciones nativas;
• no tiene acceso completo a las capacidades técnicas del dispositivo;
• a menudo, los complementos existentes están en desuso, por lo que a veces tiene que escribir el suyo propio;
• la interfaz de usuario se visualiza utilizando el navegador incorporado, y esto crea dificultades para obtener comentarios en comparación con la aplicación nativa;
• No todos los controles están implementados.

Y decidimos continuar con el desarrollo "nativo" de nuestro proyecto.

La forma nativa de Apple

4. En primer lugar, necesitamos una herramienta para desarrollar y escribir código: necesitamos un código X IDE

Xcode es un entorno de desarrollo de software integrado (IDE) para plataformas macOS, iOS, watchOS y tvOS desarrollado por Apple. La primera versión se lanzó en 2001. Las versiones estables se distribuyen de forma gratuita a través de Mac App Store. Los desarrolladores registrados también tienen acceso a las versiones beta a través del sitio web de desarrolladores de Apple.

Así es como se ve crear y trabajar en una aplicación simple como la aplicación Single View en Xcode:





Algunos puntos interesantes sobre Xcode:

Xcode ofrece un kit de herramientas muy conveniente para crear una interfaz de usuario (interfaz de usuario): Storyboard.





Pero la mayoría de los proyectos (aplicaciones) para iOS no son atendidos por un desarrollador, sino por varios (el equipo de desarrollo), y cuando se usa un Storyboard para todas las pantallas de aplicaciones cuando se usan sistemas de control de versiones distribuidas (SVN, Mercurial, GIT, etc.), la fusión de desarrollos se convierte en verdadero infierno

Nuestro equipo acordó un enfoque: un Storyboard - un ViewController .
Con este enfoque, el problema descrito anteriormente desaparece, ya que generalmente un desarrollador implementa una característica, es decir, todas las pantallas de esta característica.

Para reducir la carga en el Guión gráfico al usar Segue, puede usar la función 'Refactorizar al guión gráfico' . Esta refactorización del guión gráfico crea un enlace en el Guión gráfico principal, que conduce a un Guión gráfico nuevo e independiente, donde se implementa el ViewController deseado.

También vale la pena señalar la herramienta de depuración de Xcode - Breakpoint .
Breakpoint es una herramienta de depuración que le permite pausar la ejecución del programa hasta cierto punto. Eso nos permitirá examinar el código del programa (averiguar los valores de las variables en este momento, hacer algunos cálculos, etc.) para averiguar dónde se producen los errores.



Esta herramienta es inteligente: tenemos botones de control de acceso (Step Over, Step Into), que manipulan lo que navegamos a través de nuestro código. También tenemos acceso para analizar los valores de las variables y trabajar con registros en la salida de la consola.
Cuando Control-clic en el punto de interrupción del indicador muestra un menú de comandos. Aquí puede establecer condiciones adicionales para activar un punto de interrupción, agregar acciones, etc.
Por ejemplo, establecemos una condición de activación para el punto de interrupción: el paso variable tomará el valor 4. Y después de que se inicie la aplicación, el programa detendrá su ejecución en este punto de interrupción solo cuando la variable de paso tome el valor 4 y no antes.



Podemos agregar expresiones adicionales (¡propiedades e incluso cálculos!).

5. Debe decidir sobre el lenguaje de programación Objective-C o el nuevo Swift

El proyecto que obtuvimos fue escrito en Objective-C, pero el nuevo lenguaje de programación Swift ya estaba en el horizonte.

¿Qué son estos lenguajes de programación?

Objective-C es un lenguaje de programación compilado y orientado a objetos utilizado por Apple, construido sobre la base del lenguaje C y el paradigma Smalltalk. En particular, el modelo de objetos está construido en el estilo Smalltalk, es decir, los mensajes se envían a los objetos.

El lenguaje Objective-C existe desde 1989, la última vez que se actualizó en 2006, más
Hace 10 años La popularidad de iOS está en constante crecimiento, lo que requiere mejorar la calidad de la aplicación. Para trabajar con Objective-C, se requiere un desarrollador altamente calificado.

Todo esto se convirtió en requisitos previos para la creación del lenguaje de programación Swift.

Apple comenzó a desarrollar Swift en 2010. El 2 de junio de 2014, este idioma fue presentado oficialmente en la Conferencia Mundial de Desarrolladores de Apple (WWDC). Una guía gratuita de 500 páginas para usarlo estaba disponible en la iBook Store.

Swift 1.0 fue lanzado el 9 de septiembre de 2014 junto con la versión Gold Master de Xcode 6.0 para iOS.
El 8 de junio de 2015, Apple lanzó una nueva versión de Swift 2.0 con un rendimiento mejorado y una nueva API de manejo de errores. La sintaxis del idioma ha mejorado, ha aparecido una función para verificar la disponibilidad de las funciones de Swift para los sistemas operativos de destino.

El 3 de diciembre de 2015, se lanzó una versión beta de Swift 3.0 con soporte para OS X, iOS y Linux, bajo licencia de código abierto Apache 2.0.

El 19 de septiembre de 2017, se lanzó Swift 4.0.

En septiembre de 2018, junto con la nueva versión de iOS 12, se lanzó una nueva versión estable del lenguaje Swift 4.2 y apareció una versión beta de Swift 5.0. La versión 5.0 finalmente anunció el funcionamiento estable de ABI con bibliotecas estándar (Swift Dynamic Library), soporte para expresiones regulares y una solución de primera clase para procesamiento de datos en paralelo con modo de procesamiento asíncrono / espera.

En base a lo anterior, decidimos usar solo Swift en formularios nuevos, para admitir formularios antiguos, reescribiéndolos gradualmente.

6. A continuación, debe comprender la arquitectura del proyecto: decidimos dejar la arquitectura MVC de Apple

Model-View-Controller (MVC) asigna uno de los tres roles a los objetos en una aplicación: modelo, vista o controlador. La arquitectura define no solo los roles que juegan los objetos en la aplicación, sino también la forma en que los objetos interactúan entre sí. Cada uno de los tres tipos de objetos está separado de los demás por bordes abstractos e interactúa con objetos de otros tipos a través de estos bordes (https://developer.apple.com/library/archive/documentation/General/Conceptual/DevPedia-CocoaCore/MVC.html).



Pero, aplicando este enfoque, encontramos los siguientes problemas, que solo pudimos resolver cambiando a la nueva arquitectura en MKBMobile 3.0:

• MVC no proporciona instrucciones claras sobre qué entidades y clases necesita crear y cuáles no. La estructura y arquitectura del modelo, así como su interacción con el controlador, permanecen enteramente en la conciencia y la imaginación de los desarrolladores.
• Mala comprensión del área de dominio. Es decir cuando un desarrollador agrega nueva funcionalidad, en lugar de crear nuevas entidades y refactorizar la arquitectura existente, se agrega nueva funcionalidad al ViewController. Lo que condujo al siguiente problema: Massive View Controller: mucho código dentro de ViewController.

7. Y lo más dulce es el SDK de iOS (https://developer.apple.com/documentation/)

El SDK de iOS proporciona una gran cantidad de Frameworks.

Usamos la siguiente lista de marcos con particular entusiasmo en una aplicación bancaria:

• PushKit y UserNotifications para trabajar con notificaciones push;
• PassKit para trabajar con Apple Pay;
• CallKit (junto con WebRTC) para trabajar con servicios de VoIP;
• Fundación AV para trabajar con recursos de audio;
• Contactos para obtener acceso a los contactos del usuario;
• CommonCrypto para trabajar con funciones criptográficas.

Entonces, hemos decidido lo necesario, estamos cargados y listos para los logros ...

Durante algún tiempo, las nuevas características (funcionalidad: nuevas transferencias, pagos, productos bancarios (tarjetas, préstamos, etc.) estaban bien integradas en la aplicación.

Pero luego la aplicación se volvió engorrosa e inconveniente .

Entonces, el proyecto MKBMobile 2.0 apareció con una idea de interfaz audaz: Trello Pages.

El enfoque de Trello Pages, de hecho, es tableros unidos a la parte superior de la pantalla, en nuestra versión, a la barra de navegación superior. El enfoque le permite hacer una navegación rápida entre tableros (páginas).




Las ventajas de este enfoque:

• escalabilidad, espacio infinito izquierda / derecha y abajo;
• separabilidad, cada tipo de funcionalidad se colocó en una página separada;
• Perfecto para iPad y iPhone.

Pero había algunas desventajas en esta idea:

• Los principales elementos del menú de navegación tenían un acceso difícil;
• las notificaciones push entrantes y las notificaciones por SMS crearon dificultades adicionales para trabajar con el menú de navegación superior;
• Este enfoque no cumplía con las Directrices de interfaz humana de Apple.

Así nació la versión actual del banco móvil ICD, MKBMobile 3.0.

En esta versión, hemos adoptado el modelo de navegación clásico de Apple HIG (Human Interface Guidelines) TabBar inferior.





Pasando a esta versión, hemos adquirido mucha experiencia negativa usando la arquitectura MVC clásica de Apple.

Nuestro equipo creció y necesitábamos un umbral bajo para que nuevos empleados ingresaran al proyecto.
Además, un punto más no nos molestó: las pruebas unitarias del comportamiento de los elementos gráficos, para las cuales se usaron las pruebas a través de la Prueba de IU Xcode, que fue un largo proceso de lanzamiento de una aplicación en un emulador (dispositivo) con emulación de las acciones del usuario.

Todos estos requisitos dieron como resultado el uso de un nuevo enfoque arquitectónico: VIPER.
Modelo VIPER clásico:



Pero, después de analizar muchos enfoques en la implementación de VIPER para iOS, nos decidimos por la solución Rambler & Co con nuestras digresiones.

Como base ponemos un libro de Rambler & Co.



Las principales tareas que VIPER nos ayudó a resolver:

• partición de clases grandes (controladores de vista masiva) con límites de responsabilidad más o menos claramente definidos;
• aplicación de principios SÓLIDOS en todo su esplendor;
• umbral bajo para nuevos empleados que ingresan al proyecto;
• Prueba de unidad de IU.

Es importante tener en cuenta de inmediato que VIPER no es en absoluto un conjunto de plantillas y reglas estrictas. Más bien, esta es una lista de recomendaciones, después de las cuales puede construir una arquitectura de aplicación móvil flexible y reutilizable.

Cómo comenzó a verse nuestro proyecto:



La estructura del módulo VIPER en nuestra implementación:

1. La más "principal" es la clase Módulo, sabe todo sobre todos, crea los objetos de los servicios necesarios para Interactor, sabe cómo conectar todas las partes entre sí Vista, Enrutador, Presentador, etc.



También proporciona comunicación con otros módulos VIPER a través de los protocolos de entrada y salida ModuleInput y ModuleOutput.

Protocolos de entrada y salida similares tienen todas las partes del módulo VIPER (Ver, Enrutador, Presentador, etc.).

Acordamos: si no hay necesidad de protocolos o partes del módulo VIPER, no los usamos y no reservamos clases vacías para ellos.

2. Interactores (Interactor): oculta la lógica empresarial.

Hemos introducido una capa adicional de servicios. Servicio: un objeto que es responsable de trabajar con su tipo de datos específico. Por ejemplo, un servicio del sistema de ayuda es responsable de los directorios (archivos de acuerdos, detalles, etc.)

3. Presentador: recibe información de la Vista sobre las acciones del usuario y la convierte en solicitudes de Enrutador, Interactor, y también recibe datos de Interactor, los prepara y envía la Vista para su visualización.

4. Enrutador: es responsable de la navegación entre módulos.

5. Ver: es responsable de mostrar los datos en la pantalla y notifica al presentador sobre las acciones del usuario. Pasiva, nunca solicita datos, solo los recibe de Presenter.

Nuestros módulos pueden ser compuestos.

Es decir, incluir módulos VIPER independientes. Por ejemplo, la página principal del producto consta de un conjunto de partes independientes: saldo, widget de plantilla, secciones de diferentes tipos de productos bancarios y tasas de cambio.

Todas estas partes son independientes y pueden vivir sus propias vidas: tienen su propia API con el servidor del banco, tienen modelos de datos independientes. Para mostrarlos en la página principal, se preparan contenedores (Vista principal), donde se insertan estos widgets (Vista).





Nuestra aplicación móvil para iOS está en constante crecimiento y desarrollo. Es utilizado por más y más de nuestros clientes.




¿Cuáles son las siguientes herramientas que planeamos presentar?

• SwiftLint, una utilidad de los desarrolladores de Realm para la verificación automática del código Swift;
• CI completo basado en fastlane;
• Uso completo de instrumentos de Xcode (asignaciones, fugas, zombis, etc.)

Sigue nuestros artículos! ¡Nos vemos y gracias por su atención!