ICD Mobile Banking: historique du développement

Oleg Ivanov, chef du Centre de compétence des canaux de service à distance, Département du développement informatique, Direction des technologies de l'information, Banque de crédit de Moscou (ICD)

Pour nous, le développement d'une application mobile a commencé à partir de zéro, donc dans cet article, nous partirons du tout début: en déterminant ce qu'elle est et quelles fonctions devraient y figurer. Et ensuite, nous irons jusqu'au bout - de l’achat de nouveaux gadgets pour tester l’application au lancement. Nous raconterons l'histoire du développement de notre application avec des indentations technologiques. Décrivons les problèmes que nous avons rencontrés. Malheureusement, nous ne pourrons pas couvrir toutes les approches, les principes et les solutions technologiques qui ont été utilisés dans le développement de cet article de revue, mais nous nous attarderons sur les points les plus intéressants.

De plus, l'accent sera mis sur le développement pour iOS. Avant de commencer, décidons de ce qu'est Mobile Bank.

Une banque mobile est la gestion de comptes bancaires à l'aide de l'application bancaire sur un smartphone (iPhone, etc.), une tablette (iPad, Samsung Galaxy Tab, etc.). Pour les opérations bancaires, une confirmation en deux étapes est requise en utilisant des codes à usage unique via des messages SMS.

Les principales opérations bancaires de la Mobile Bank:

• utilisation de produits bancaires (comptes, cartes, dépôts, prêts, packages de services, etc.)
• afficher le solde du compte
• déclaration
• paiement des factures pour les services mobiles
• paiement des services de logement
• transférer des fonds de carte en carte
• paiements réguliers
• remboursement de prêts
• transfert de fonds à déposer
• serrure de carte de paiement
• et d'autres.

Les applications bancaires mobiles sont des applications bancaires sur Internet adaptées aux petits écrans de smartphones et aux systèmes d'exploitation (iOS d'Apple, Android de Google) installés sur les appareils mobiles. Il convient de noter que la gamme de modèles d'appareils exécutant le système d'exploitation Android est très large: Samsung, LG, Xiaomi, Huawei, etc., ce qui complique le développement et le support de l'application pour Android.

Source - MKBMobile 1.0

Le projet d'application Mobile Bank a été transféré à notre équipe par une société tierce, il a été écrit en Objectif C.

Voici à quoi ressemblait le projet aux yeux de l'utilisateur:





Ce projet est devenu une startup et un test de nos capacités. Notre équipe a eu peu d'expériences de développement pour la plate-forme mobile iOS, mais nous avons audacieusement repris le projet.

Par où commencer? Lorsque nous pensons à développer pour iOS, la première chose dont nous avons besoin:

1. Besoin d'iMac

Apple est célèbre pour le prix élevé de ses produits. Mais économiser ne vaut pas la peine - c'est la vitesse de votre développement!

Une configuration approximative et optimale qui nous convient:

• Processeur Intel Core i5 de septième génération avec une vitesse d'horloge de 3,8 GHz (Turbo Boost jusqu'à 4,2 GHz)
• 32 Go DDR4 2400 MHz
• 2 To Fusion Drive
• GPU Radeon Pro 580 avec 8 Go de VRAM

Le coût approximatif d'une telle machine est de 190 000 roubles.

Il y a une opinion - pour les programmeurs ont besoin d'iMac Pro. C'est ainsi :) Mais le prix de ces piqûres, et si votre entreprise est prête à les acheter, cela augmentera la vitesse de votre développement, et bien sûr, augmentera le niveau esthétique de votre bureau.

2. Besoin d'appareils iOS

"Combien et lequel?" - la première question se pose. Tout dépend de votre application.
Si votre application ne prend en charge que l'iPhone, au moins 2 tailles différentes sont petites (par exemple iPhone SE) et grandes (par exemple iPhone 8 Plus).

Si votre application prend également en charge l'iPad, vous avez besoin d'un iPad.

Vient ensuite le système d'exploitation - sa version. Si votre application prend en charge la version minimale, par exemple, à partir d'iOS 8.0, vous devez stocker sur l'appareil avec chaque numéro de série iOS et n'oubliez pas de «conserver» (ne pas mettre à jour) cette version sur l'appareil et de surveiller l'apparence des nouvelles versions d'iOS, sans oublier de sélectionner un ensemble pour cela appareils.

Bien sûr, pour la première fois, vous pouvez vous en tirer avec les simulateurs Xcode, mais les appareils physiques imposent leurs propres collisions qui n'apparaissent pas sur les simulateurs.

Si vous ne souhaitez pas avoir votre propre batterie de périphériques, vous pouvez vous adresser aux parties des entreprises offrant ce service: AWS Device Farm, Xamarin Test Cloud, etc.

Comme déjà mentionné, notre application est prise en charge à la fois pour iPhone et iPad. Au moment d'écrire ces lignes, notre (()) ferme comprend environ 30 appareils de différents types et versions du système d'exploitation.

3. Vous devez décider de l'approche de développement pour iOS (native ou alternative).

Nous avons essayé les options de développement alternatives suivantes pour iOS:

Phonegap / Cordova

PhoneGap a été créé à l'origine par Nitobi. En 2011, Adobe a acquis Nitobi et la marque PhoneGap. Adobe transfère ensuite une version de PhoneGap, appelée Cordova, à la Fondation Apache, laissant la marque PhoneGap et le produit lui-même. En conséquence, Cordova peut être considéré comme un moteur sous le capot de PhoneGap (ainsi que certains autres cadres hybrides). PhoneGap, à son tour, ajoute ses propres fonctionnalités supplémentaires aux capacités de Cordova.

PhoneGap est à bien des égards très similaire à Ionic. Il donne également aux développeurs la possibilité de créer des applications multiplateformes à l'aide des technologies Web, et est également construit sur la base d'Apache Codova. Cependant, PhoneGap n'est lié à aucun framework Javascript spécifique, donc les développeurs ont plus de choix sur quoi et comment ils vont créer leurs applications.

Hélas, PhoneGap utilise WebView (qui est assez lent sur iOS), donc les choses ne sont pas toujours géniales avec la vitesse des applications construites sur la base de ce cadre.

Xamarin

Fondée en 2011, Xamarin, la famille de produits Xamarin, a été acquise par Microsoft après cinq ans d'existence. Aujourd'hui, les produits Xamarin présentent une approche très intéressante pour développer des applications mobiles multiplateformes sur le marché: les applications sont écrites en C #, puis Xamarin les compile dans une application native pour iOS ou Android, tandis que Xamarin utilise Mono comme technologie sous-jacente, plutôt que multiplateforme. et est fourni. Les développeurs de Xamarin disent que les applications résultantes utilisent l'API de plateforme native pour laquelle l'application est compilée, donc le comportement de l'application résultante n'est pas différent du comportement de toute autre application sur la même plateforme. Le développement, soit dit en passant, peut être fait à l'aide de Visual Studio (ce qui n'est pas surprenant).

Malgré le fait que la plupart du code du projet peut être utilisé sans modifications sur chacune des plates-formes mobiles prises en charge, cependant, certains fragments devront être écrits spécifiquement pour la version de l'application pour iOS et Android.

Mais de telles approches donnent l'application dite "hybride".

Avantages des options alternatives:

• multiplateforme (ayant fait une seule application, elle peut être exportée pour n'importe quel OS);
• le temps de développement est moins que natif.

Inconvénients des alternatives:

• fonctionne plus lentement que les applications natives;
• n'a pas un accès complet aux capacités techniques de l'appareil;
• souvent les plugins existants sont obsolètes, donc parfois vous devez écrire les vôtres;
• l'interface utilisateur est visualisée à l'aide du navigateur intégré, ce qui crée des difficultés pour obtenir des commentaires par rapport à l'application native;
• tous les contrôles ne sont pas mis en œuvre.

Et nous avons décidé de poursuivre le développement "natif" de notre projet.

Native Way d'Apple

4. Tout d'abord, nous avons besoin d'un outil pour développer et écrire du code - nous avons besoin d'un IDcode Xcode

Xcode est un environnement de développement logiciel intégré (IDE) pour les plates-formes macOS, iOS, watchOS et tvOS développé par Apple. La première version a été lancée en 2001. Les versions stables sont distribuées gratuitement via le Mac App Store. Les développeurs enregistrés ont également accès aux versions bêta via le site Web des développeurs Apple.

Voici à quoi ressemble la création et le travail sur une application simple comme Single View App dans Xcode:





Quelques points intéressants sur Xcode:

Xcode offre une boîte à outils très pratique pour créer une interface utilisateur (interface utilisateur) - Storyboard.





Mais la plupart des projets (applications) pour iOS ne sont pas servis par un développeur, mais par plusieurs (l'équipe de développement), et lors de l'utilisation d'un Storyboard pour tous les écrans d'application lors de l'utilisation de systèmes de contrôle de version distribués (SVN, Mercurial, GIT, etc.), la fusion des développements se transforme en vrai enfer.

Notre équipe s'est mise d'accord sur une approche: un Storyboard - un ViewController .
Avec cette approche, le problème décrit ci-dessus disparaît, car généralement un développeur implémente une fonctionnalité, c'est-à-dire tous les écrans de cette fonctionnalité.

Pour réduire la charge dans le Storyboard lors de l'utilisation de Segue, vous pouvez utiliser la fonction «Refactor to storyboard» . Cette refactorisation du storyboard crée un lien dans le storyboard parent, ce qui conduit à un nouveau storyboard séparé, où le ViewController souhaité est implémenté.

Il convient également de noter l'outil de débogage de Xcode - Breakpoint .
Breakpoint est un outil de débogage qui vous permet de suspendre l'exécution du programme jusqu'à un certain point. Cela nous permettra d'examiner le code du programme (trouver les valeurs des variables à ce moment, faire des calculs, etc.) pour savoir où les erreurs se produisent.



Cet outil est intelligent: nous avons des boutons de contrôle d'accès (Step Over, Step Into), qui nous permettent de naviguer dans notre code. Nous avons également accès à l'analyse des valeurs des variables et à l'utilisation des journaux dans la sortie de la console.
Lorsque Ctrl-clic sur le point d'arrêt de l'indicateur affiche un menu de commandes. Ici, vous pouvez définir des conditions supplémentaires pour déclencher un point d'arrêt, ajouter des actions, etc.
Par exemple, nous définissons une condition de déclenchement pour le point d'arrêt: l'étape variable prendra la valeur 4. Et après le démarrage de l'application, le programme arrêtera son exécution à ce point d'arrêt uniquement lorsque la variable d'étape prendra la valeur 4 et pas plus tôt.



Nous pouvons ajouter des expressions supplémentaires (propriétés et même calculs!).

5. Vous devez choisir le langage de programmation Objective-C ou le nouveau Swift

Le projet que nous avons obtenu a été écrit en Objective-C, mais le nouveau langage de programmation Swift était déjà à l'horizon.

Quels sont ces langages de programmation?

Objective-C est un langage de programmation compilé et orienté objet utilisé par Apple, construit sur la base du langage C et du paradigme Smalltalk. En particulier, le modèle d'objet est construit dans le style Smalltalk - c'est-à-dire que les messages sont envoyés aux objets.

Le langage Objective-C existe depuis 1989, la dernière fois qu'il a été mis à jour en 2006, suite
Il y a 10 ans. La popularité d'iOS ne cesse de croître, ce qui nécessite d'améliorer la qualité de l'application. Pour travailler avec Objective-C, un développeur hautement qualifié est requis.

Tout cela est devenu une condition préalable à la création du langage de programmation Swift.

Apple a commencé à développer Swift en 2010. Le 2 juin 2014, ce langage a été officiellement dévoilé lors de la Conférence mondiale des développeurs Apple (WWDC). Un guide gratuit de 500 pages sur son utilisation était disponible sur l'iBook Store.

Swift 1.0 est sorti le 9 septembre 2014 avec la version Gold Master de Xcode 6.0 pour iOS.
Le 8 juin 2015, Apple a publié une nouvelle version de Swift 2.0 avec des performances améliorées et une nouvelle API de gestion des erreurs. La syntaxe du langage s'est améliorée, une fonction de vérification de la disponibilité des fonctions Swift pour les OS cibles est apparue.

Le 3 décembre 2015, une version bêta de Swift 3.0 a été publiée avec prise en charge d'OS X, iOS et Linux, sous licence open source Apache 2.0.

Le 19 septembre 2017, Swift 4.0 a été publié.

En septembre 2018, avec la nouvelle version d'iOS 12, une nouvelle version stable du langage Swift 4.2 est sortie et une version bêta de Swift 5.0 est apparue. La version 5.0 a finalement annoncé le fonctionnement stable de l'ABI avec les bibliothèques standard (Swift Dynamic Library), la prise en charge des expressions régulières et une solution de première classe pour le traitement parallèle des données avec le mode de traitement asynchrone / attente.

Sur la base de ce qui précède, nous avons décidé d'utiliser uniquement Swift dans les nouveaux formulaires, pour prendre en charge les anciens formulaires, en les réécrivant progressivement.

6. Ensuite, vous devez comprendre l'architecture du projet - nous avons décidé de quitter l'architecture MVC d'Apple

Model-View-Controller (MVC) attribue l'un des trois rôles aux objets d'une application: modèle, vue ou contrôleur. L'architecture définit non seulement les rôles que les objets jouent dans l'application, mais également la façon dont les objets interagissent les uns avec les autres. Chacun des trois types d'objets est séparé des autres par des bordures abstraites et interagit avec des objets d'autres types à travers ces bordures (https://developer.apple.com/library/archive/documentation/General/Conceptual/DevPedia-CocoaCore/MVC.html).



Mais, en appliquant cette approche, nous avons rencontré les problèmes suivants, que nous n'avons pu résoudre qu'en passant à la nouvelle architecture de MKBMobile 3.0:

• MVC ne fournit pas d'instructions claires sur les entités et les classes que vous devez créer et celles qui ne le sont pas. La structure et l'architecture du modèle, ainsi que son interaction avec le contrôleur, restent entièrement sur la conscience et l'imagination du ou des développeurs.
• Mauvaise compréhension de la zone du domaine. C'est-à-dire lorsqu'un développeur ajoute de nouvelles fonctionnalités, au lieu de créer de nouvelles entités et de refactoriser l'architecture existante, de nouvelles fonctionnalités sont ajoutées au ViewController. Ce qui a conduit au problème suivant: Massive View Controller - beaucoup de code à l'intérieur du ViewController.

7. Et la chose la plus douce est le SDK iOS (https://developer.apple.com/documentation/)

Le SDK iOS fournit un grand nombre de cadres.

Nous avons utilisé la liste suivante de frameworks avec un enthousiasme particulier dans une application bancaire:

• PushKit et UserNotifications pour travailler avec les notifications push;
• PassKit pour avoir travaillé avec Apple Pay;
• CallKit (en collaboration avec WebRTC) pour travailler avec les services VoIP;
• AVFoundation pour travailler avec des ressources audio;
• Contacts pour accéder aux contacts des utilisateurs;
• CommonCrypto pour travailler avec des fonctions cryptographiques.

Donc, nous avons décidé du nécessaire, nous sommes facturés et prêts pour les réalisations ...

Pendant un certain temps, de nouvelles fonctionnalités (fonctionnalité - nouveaux virements, paiements, produits bancaires (cartes, prêts, etc.) ont été bien intégrées dans l'application.

Mais ensuite, la demande est devenue lourde et peu pratique .

Le projet MKBMobile 2.0 est donc apparu avec une idée d'interface audacieuse - Trello Pages.

L'approche Trello Pages, en fait, est constituée de panneaux attachés en haut de l'écran, dans notre version, à la barre de navigation supérieure. L'approche vous permet de faire une navigation rapide entre les tableaux (pages).




Les avantages de cette approche:

• évolutivité, espace infini gauche / droite et bas;
• séparabilité, chaque type de fonctionnalité a été placé sur une page distincte;
• Parfait pour iPad et iPhone.

Mais il y avait quelques inconvénients à cette idée:

• Les éléments du menu de navigation supérieur étaient difficiles d'accès;
• les notifications push entrantes et les notifications SMS ont créé des difficultés supplémentaires pour travailler avec le menu de navigation supérieur;
• cette approche n'était pas conforme aux directives d'interface humaine d'Apple.

La version actuelle de la banque mobile ICD, MKBMobile 3.0, est donc née.

Dans cette version, nous avons adopté le modèle de navigation classique d'Apple HIG (Human Interface Guidelines) TabBar inférieur.





En passant à cette version, nous avons acquis beaucoup d'expérience négative en utilisant l'architecture MVC classique d'Apple.

Notre équipe s'est agrandie et nous avions besoin d'un seuil bas pour que de nouveaux employés entrent dans le projet.
De plus, un autre point ne nous a pas dérangé: le test unitaire du comportement des éléments graphiques, pour lequel le test a été utilisé via le test Xcode UI, qui était un long processus de lancement d'une application sur un émulateur (appareil) avec émulation des actions de l'utilisateur.

Toutes ces exigences ont abouti à l'utilisation d'une nouvelle approche architecturale - VIPER.
Modèle VIPER classique:



Mais, après avoir examiné de nombreuses approches dans la mise en œuvre de VIPER pour iOS, nous avons opté pour la solution Rambler & Co avec nos digressions.

Comme base, nous avons mis un livre de Rambler & Co.



Les principales tâches que VIPER nous a aidées à résoudre:

• partition de grandes classes (Massive View Controllers) avec des limites de responsabilité plus ou moins clairement définies;
• application des principes SOLIDES dans toute leur splendeur;
• seuil bas pour les nouveaux employés entrant dans le projet;
• Tests unitaires de l'interface utilisateur.

Il est important de noter tout de suite que VIPER n'est en aucun cas un ensemble de modèles et de règles stricts. Il s'agit plutôt d'une liste de recommandations, à la suite de laquelle vous pouvez créer une architecture d'application mobile flexible et réutilisable.

À quoi ressemblait notre projet:



La structure du module VIPER dans notre implémentation:

1. La plus «principale» est la classe Module, elle sait tout sur tout le monde, crée les objets de services nécessaires pour Interactor, sait connecter toutes les parties les unes des autres avec View, Router, Presenter, etc.



Il assure également la communication avec d'autres modules VIPER via les protocoles d'entrée et de sortie ModuleInput et ModuleOutput.

Des protocoles d'entrée et de sortie similaires ont toutes les parties du module VIPER (View, Router, Presenter, etc.).

Nous avons convenu: s'il n'y a pas besoin de protocoles ou de parties du module VIPER, nous ne les utilisons pas et ne leur réservons pas de classes vides.

2. Interacteurs (Interactor) - masquer la logique métier.

Nous avons introduit une couche supplémentaire de services. Service - un objet chargé de travailler avec son type de données spécifique. Par exemple, un service de système d'aide est responsable des répertoires (fichiers d'accords, détails, etc.)

3. Présentateur - reçoit de View des informations sur les actions de l'utilisateur et les convertit en demandes de routeur, d'interacteur, et reçoit également des données d'Interactor, les prépare et envoie la vue pour affichage.

4. Routeur - est responsable de la navigation entre les modules.

5. Affichage - est responsable de l'affichage des données à l'écran et informe le présentateur des actions de l'utilisateur. Passif, il ne demande jamais de données, il ne les reçoit que de Presenter.

Nos modules peuvent être composites.

C'est-à-dire, inclure des modules VIPER indépendants. Par exemple, la page principale du produit se compose d'un ensemble de parties indépendantes: solde, widget de modèle, sections de différents types de produits bancaires et taux de change.

Toutes ces parties sont indépendantes et peuvent vivre leur propre vie - elles ont leur propre API avec le serveur bancaire, elles ont des modèles de données indépendants. Pour les afficher sur la page principale, des conteneurs (vue parent) sont préparés, où ces widgets (vue) sont insérés.





Notre application mobile pour iOS ne cesse de croître et de se développer. Il est utilisé par de plus en plus de nos clients.




Quels sont les outils suivants que nous prévoyons d'introduire:

• SwiftLint, un utilitaire des développeurs Realm pour la vérification automatique du code Swift;
• CI complet basé sur fastlane;
• Utilisation complète des instruments de Xcode (allocations, fuites, zombies, etc.)

Suivez nos articles! A bientôt et merci de votre attention!