ICD Mobile Banking: Entwicklungsgeschichte

Oleg Ivanov, Leiter des Zentrums für die Kompetenz von Remote-Service-Kanälen, Abteilung für IT-Entwicklung, Direktion Informationstechnologien, Moskauer Kreditbank (ICD)

Für uns hat die Entwicklung einer mobilen Anwendung von vorne begonnen, daher werden wir in diesem Artikel von vorne beginnen: indem wir bestimmen, was es ist und welche Funktionen darin enthalten sein sollten. Und dann gehen wir den ganzen Weg - vom Kauf neuer Gadgets über das Testen der Anwendung bis zum Start. Wir werden die Geschichte der Entwicklung unserer Anwendung mit technologischen Einschnitten erzählen. Beschreiben wir, auf welche Probleme wir gestoßen sind. Leider werden wir nicht in der Lage sein, alle Ansätze, Prinzipien und technologischen Lösungen zu behandeln, die bei der Entwicklung in diesem Übersichtsartikel verwendet wurden, aber wir werden uns mit den interessantesten Punkten befassen.

Weiterhin wird der Schwerpunkt auf der Entwicklung für iOS liegen. Bevor Sie beginnen, entscheiden wir, was Mobile Bank ist.

Eine mobile Bank ist die Verwaltung von Bankkonten mithilfe der Bankanwendung auf einem Smartphone (iPhone usw.), einem Tablet-Computer (iPad, Samsung Galaxy Tab usw.). Für Bankgeschäfte ist eine Bestätigung in zwei Schritten unter Verwendung von Einmalcodes per SMS erforderlich.

Die wichtigsten Bankgeschäfte der Mobile Bank:

• Verwendung von Bankprodukten (Konten, Karten, Einlagen, Kredite, Servicepakete usw.)
• Kontostand anzeigen
• Aussage
• Zahlung von Rechnungen für mobile Dienste
• Zahlung von Wohnungsdienstleistungen
• Geld von Karte zu Karte überweisen
• regelmäßige Zahlungen
• Rückzahlung von Darlehen
• Überweisung von Geldern zur Einzahlung
• Zahlungskartensperre
• und andere.

Mobile-Banking-Anwendungen sind Internet-Banking-Anwendungen, die für kleine Bildschirme von Smartphones und für Betriebssysteme (Apples iOS, Googles Android) geeignet sind, die auf Mobilgeräten installiert sind. Es ist zu beachten, dass die Modellpalette der Geräte, auf denen das Android-Betriebssystem ausgeführt wird, sehr breit ist: Samsung, LG, Xiaomi, Huawei usw., was die Entwicklung und Unterstützung der Anwendung für Android erschwert.

Quelle - MKBMobile 1.0

Das Mobile Bank-Anwendungsprojekt wurde von einem Drittunternehmen an unser Team übertragen. Es wurde in Ziel C geschrieben.

So sah das Projekt mit den Augen des Benutzers aus:





Dieses Projekt ist ein Startup und ein Test unserer Fähigkeiten geworden. Unser Team hatte nur wenige Entwicklungserfahrungen für die mobile iOS-Plattform, aber wir haben das Projekt mutig aufgenommen.

Wo soll ich anfangen? Wenn wir über die Entwicklung für iOS nachdenken, brauchen wir als Erstes:

1. Benötigen Sie iMac

Apple ist berühmt für den hohen Preis seiner Produkte. Sparen lohnt sich aber nicht - das ist die Geschwindigkeit Ihrer Entwicklung!

Eine ungefähre, optimale Konfiguration, die zu uns passt:

• Intel Core i5-Prozessor der siebten Generation mit einer Taktrate von 3,8 GHz (Turbo Boost bis 4,2 GHz)
• 32 GB DDR4 2400 MHz
• 2 TB Fusion Drive
• Radeon Pro 580 GPU mit 8 GB VRAM

Die ungefähren Kosten einer solchen Maschine betragen 190.000 Rubel.

Es gibt eine Meinung - für Programmierer braucht iMac Pro. Das ist so :) Aber der Preis für sie beißt, und wenn Ihr Unternehmen bereit ist, sie zu kaufen, erhöht dies die Geschwindigkeit Ihrer Entwicklung und natürlich das ästhetische Niveau Ihres Büros.

2. Benötigen Sie iOS-Geräte

"Wie viel und welche?" - Die erste Frage stellt sich. Es hängt alles von Ihrer Anwendung ab.
Wenn Ihre Anwendung nur das iPhone unterstützt, sind mindestens 2 verschiedene Größen klein (z. B. iPhone SE) und groß (z. B. iPhone 8 Plus).

Wenn Ihre Anwendung auch das iPad unterstützt, benötigen Sie ein iPad.

Als nächstes kommt das Betriebssystem - seine Versionierung. Wenn Ihre Anwendung beispielsweise die Mindestversion unterstützt, beginnend mit iOS 8.0, müssen Sie das Gerät mit jeder iOS-Seriennummer auffüllen und daran denken, diese Version auf dem Gerät beizubehalten (nicht zu aktualisieren) und das Erscheinungsbild neuer iOS-Versionen zu überwachen, ohne zu vergessen, einen Satz dafür auszuwählen Geräte.

Natürlich können Sie zum ersten Mal mit Xcode-Simulatoren auskommen, aber physische Geräte verursachen ihre eigenen Kollisionen, die auf Simulatoren nicht auftreten.

Wenn Sie keine eigene Gerätefarm haben möchten, können Sie sich an die Parteien der Unternehmen wenden, die diesen Service anbieten: AWS Device Farm, Xamarin Test Cloud usw.

Wie bereits erwähnt, wird unsere Anwendung sowohl für das iPhone als auch für das iPad unterstützt. Zum Zeitpunkt des Schreibens umfasst unsere eigene (!) Farm etwa 30 Geräte verschiedener Typen und Versionen des Betriebssystems.

3. Sie müssen sich für den Entwicklungsansatz für iOS entscheiden (nativ oder alternativ).

Wir haben die folgenden alternativen Entwicklungsoptionen für iOS ausprobiert:

Phonegap / Cordova

PhoneGap wurde ursprünglich von Nitobi erstellt. Im Jahr 2011 erwarb Adobe Nitobi und die Marke PhoneGap. Adobe überträgt dann eine Version von PhoneGap, Cordova genannt, an die Apache Foundation, wobei die Marke PhoneGap und das Produkt selbst erhalten bleiben. Infolgedessen kann Cordova als Motor unter der Haube von PhoneGap (sowie einigen anderen Hybrid-Frameworks) angesehen werden. PhoneGap wiederum erweitert die Funktionen von Cordova um zusätzliche Funktionen.

PhoneGap ist Ionic in vielerlei Hinsicht sehr ähnlich. Es bietet Entwicklern auch die Möglichkeit, plattformübergreifende Anwendungen mithilfe von Webtechnologien zu erstellen, und basiert auf Apache Codova. PhoneGap ist jedoch nicht an ein bestimmtes Javascript-Framework gebunden, sodass Entwickler mehr Auswahlmöglichkeiten haben, was und wie sie ihre Anwendungen erstellen.

Leider verwendet PhoneGap WebView (was unter iOS ziemlich langsam ist), sodass die Geschwindigkeit von Anwendungen, die auf der Grundlage dieses Frameworks erstellt wurden, nicht immer brillant ist.

Xamarin

Xamarin, die Xamarin-Produktfamilie, wurde 2011 gegründet und nach fünfjährigem Bestehen von Microsoft übernommen. Heutzutage bieten Xamarin-Produkte einen sehr interessanten Ansatz für die Entwicklung plattformübergreifender mobiler Anwendungen auf dem Markt: Anwendungen werden in C # geschrieben, dann kompiliert Xamarin sie zu einer nativen Anwendung für iOS oder Android, während Xamarin Mono als zugrunde liegende Technologie und nicht plattformübergreifend verwendet und ist vorgesehen. Xamarin-Entwickler sagen, dass die resultierenden Anwendungen die native Plattform-API verwenden, für die die Anwendung kompiliert wurde, sodass sich das Verhalten der resultierenden Anwendung nicht vom Verhalten anderer Anwendungen auf derselben Plattform unterscheidet. Die Entwicklung kann übrigens mit Visual Studio erfolgen (was nicht überraschend ist).

Trotz der Tatsache, dass der größte Teil des Projektcodes ohne Änderungen auf jeder der unterstützten mobilen Plattformen verwendet werden kann, müssen einige Fragmente speziell für die Version der Anwendung für iOS und Android geschrieben werden.

Solche Ansätze ergeben jedoch die sogenannte "Hybrid" -Anwendung.

Pluspunkte alternativer Optionen:

• plattformübergreifend (nachdem eine Anwendung erstellt wurde, kann sie für jedes Betriebssystem exportiert werden);
• Entwicklungszeit ist weniger als native.

Nachteile von Alternativen:

• arbeitet langsamer als native Anwendungen;
• hat keinen vollständigen Zugriff auf die technischen Funktionen des Geräts;
• Oft sind vorhandene Plugins veraltet, daher müssen Sie manchmal Ihre eigenen schreiben.
• Die Benutzeroberfläche wird mithilfe des integrierten Browsers visualisiert. Dies führt im Vergleich zur nativen Anwendung zu Schwierigkeiten beim Abrufen von Feedback.
• Nicht alle Steuerelemente sind implementiert.

Und wir haben uns entschlossen, die "native" Entwicklung unseres Projekts fortzusetzen.

Apple's Native Way

4. Zunächst benötigen wir ein Tool zum Entwickeln und Schreiben von Code - wir benötigen einen IDE-Xcode

Xcode ist eine integrierte Softwareentwicklungsumgebung (IDE) für die von Apple entwickelten Plattformen macOS, iOS, watchOS und tvOS. Die erste Version wurde 2001 veröffentlicht. Stabile Versionen werden kostenlos über den Mac App Store vertrieben. Registrierte Entwickler haben auch über die Apple Developer-Website Zugriff auf Beta-Builds.

So sieht das Erstellen und Bearbeiten einer einfachen Anwendung wie der Single View App in Xcode aus:





Einige interessante Punkte zu Xcode:

Xcode bietet ein sehr praktisches Toolkit zum Erstellen einer Benutzeroberfläche (Storyboard) - Storyboard.





Die meisten Projekte (Anwendungen) für iOS werden jedoch nicht von einem Entwickler, sondern von mehreren (dem Entwicklungsteam) bereitgestellt. Wenn Sie ein Storyboard für alle Anwendungsbildschirme verwenden, wenn Sie verteilte Versionskontrollsysteme (SVN, Mercurial, GIT usw.) verwenden, wird das Zusammenführen von Entwicklungen zu echte Hölle.

Unser Team hat sich auf einen Ansatz geeinigt: ein Storyboard - ein ViewController .
Bei diesem Ansatz verschwindet das oben beschriebene Problem, da normalerweise ein Entwickler eine Funktion implementiert, dh alle Bildschirme dieser Funktion.

Um die Belastung des Storyboards bei Verwendung von Segue zu verringern, können Sie die Funktion "Refactor to Storyboard" verwenden. Durch dieses Refactoring des Storyboards wird eine Verknüpfung im übergeordneten Storyboard erstellt, die zu einem neuen, separaten Storyboard führt, in dem der gewünschte ViewController implementiert ist.

Erwähnenswert ist auch das Debugging-Tool von Xcode - Breakpoint .
Breakpoint ist ein Debugging-Tool, mit dem Sie die Programmausführung bis zu einem bestimmten Punkt anhalten können. Auf diese Weise können wir den Programmcode untersuchen (die Werte der Variablen in diesem Moment ermitteln, einige Berechnungen durchführen usw.), um herauszufinden, wo die Fehler auftreten.



Dieses Tool ist intelligent: Wir haben Zugriffssteuerungsschaltflächen (Step Over, Step Into), die manipulieren und durch unseren Code navigieren. Wir haben auch Zugriff auf die Analyse von Variablenwerten und arbeiten mit Protokollen in der Konsolenausgabe.
Wenn Sie bei gedrückter Ctrl-Taste auf den Anzeige-Haltepunkt klicken, wird ein Befehlsmenü angezeigt. Hier können Sie zusätzliche Bedingungen für das Auslösen eines Haltepunkts, das Hinzufügen von Aktionen usw. festlegen.
Zum Beispiel setzen wir eine Triggerbedingung für den Haltepunkt: Der Variablenschritt nimmt den Wert 4 an. Nach dem Start der Anwendung stoppt das Programm seine Ausführung an diesem Haltepunkt nur, wenn die Schrittvariable den Wert 4 und nicht früher annimmt.



Wir können zusätzlichen Ausdruck hinzufügen (Eigenschaften und sogar Berechnungen!).

5. Sie müssen sich für die Programmiersprache Objective-C oder den neuen Swift entscheiden

Das Projekt, das wir bekommen haben, wurde in Objective-C geschrieben, aber die neue Programmiersprache Swift war bereits am Horizont.

Was sind diese Programmiersprachen?

Objective-C ist eine kompilierte, objektorientierte Programmiersprache von Apple, die auf der C-Sprache und dem Smalltalk-Paradigma basiert. Insbesondere wird das Objektmodell im Smalltalk-Stil erstellt, dh Nachrichten werden an Objekte gesendet.

Die Objective-C-Sprache existiert seit 1989, das letzte Mal, dass sie 2006 aktualisiert wurde
Vor 10 Jahren. Die Popularität von iOS wächst ständig, was eine Verbesserung der Qualität der Anwendung erfordert. Für die Arbeit mit Objective-C ist ein hochqualifizierter Entwickler erforderlich.

All dies wurde zur Voraussetzung für die Erstellung der Programmiersprache Swift.

Apple begann 2010 mit der Entwicklung von Swift. Am 2. Juni 2014 wurde diese Sprache auf der Apple Worldwide Developer Conference (WWDC) offiziell vorgestellt. Eine kostenlose 500-seitige Anleitung zur Verwendung war im iBook Store erhältlich.

Swift 1.0 wurde am 9. September 2014 zusammen mit der Gold Master-Version von Xcode 6.0 für iOS veröffentlicht.
Am 8. Juni 2015 veröffentlichte Apple eine neue Version von Swift 2.0 mit verbesserter Leistung und einer neuen Fehlerbehandlungs-API. Die Sprachsyntax wurde verbessert. Es wurde eine Funktion zum Überprüfen der Verfügbarkeit von Swift-Funktionen für Zielbetriebssysteme angezeigt.

Am 3. Dezember 2015 wurde eine Beta-Version von Swift 3.0 mit Unterstützung für OS X, iOS und Linux veröffentlicht, die unter der Open Source-Lizenz Apache 2.0 lizenziert ist.

Am 19. September 2017 wurde Swift 4.0 veröffentlicht.

Im September 2018 wurde zusammen mit der neuen Version von iOS 12 eine neue stabile Version der Sprache Swift 4.2 veröffentlicht und eine Beta-Version von Swift 5.0 veröffentlicht. Version 5.0 kündigte schließlich den stabilen Betrieb des ABI mit Standardbibliotheken (Swift Dynamic Library), Unterstützung für reguläre Ausdrücke und eine erstklassige Lösung für die parallele Datenverarbeitung im asynchronen / wartenden Verarbeitungsmodus an.

Auf der Grundlage des Vorstehenden haben wir beschlossen, nur Swift in neuen Formularen zu verwenden, um alte Formulare zu unterstützen und sie schrittweise neu zu schreiben.

6. Als nächstes müssen Sie die Architektur des Projekts verstehen. Wir haben uns entschlossen, die MVC-Architektur von Apple zu verlassen

Model-View-Controller (MVC) weist Objekten in einer Anwendung eine von drei Rollen zu: Modell, Ansicht oder Controller. Die Architektur definiert nicht nur die Rollen, die Objekte in der Anwendung spielen, sondern auch die Art und Weise, wie die Objekte miteinander interagieren. Jeder der drei Objekttypen ist durch abstrakte Ränder von den anderen getrennt und interagiert über diese Ränder mit Objekten anderer Typen (https://developer.apple.com/library/archive/documentation/General/Conceptual/DevPedia-CocoaCore/MVC.html).



Bei Anwendung dieses Ansatzes stießen wir jedoch auf die folgenden Probleme, die wir nur durch den Wechsel zur neuen Architektur in MKBMobile 3.0 lösen konnten:

• MVC bietet keine klaren Anweisungen, welche Entitäten und Klassen Sie erstellen müssen und welche nicht. Die Struktur und Architektur des Modells sowie seine Interaktion mit dem Controller bleiben vollständig im Gewissen und in der Vorstellungskraft der Entwickler.
• Schlechtes Verständnis des Domainbereichs. Das heißt, Wenn ein Entwickler neue Funktionen hinzufügt, werden dem ViewController neue Funktionen hinzugefügt, anstatt neue Entitäten zu erstellen und die vorhandene Architektur neu zu gestalten. Was zu folgendem Problem führte: Massive View Controller - viel Code im ViewController.

7. Und das süßeste ist das iOS SDK (https://developer.apple.com/documentation/)

Das iOS SDK bietet eine große Anzahl von Frameworks.

Wir haben die folgende Liste von Frameworks mit besonderer Begeisterung in einer Bankanwendung verwendet:

• PushKit und UserNotifications für die Arbeit mit Push-Benachrichtigungen;
• PassKit für die Arbeit mit Apple Pay;
• CallKit (in Verbindung mit WebRTC) für die Arbeit mit VoIP-Diensten;
• AVFoundation für die Arbeit mit Audio-Ressourcen;
• Kontakte, um Zugriff auf Benutzerkontakte zu erhalten;
• CommonCrypto für die Arbeit mit kryptografischen Funktionen.

Also haben wir uns für das Notwendige entschieden, wir sind belastet und bereit für Erfolge ...

Für einige Zeit wurden neue Funktionen (Funktionen - neue Überweisungen, Zahlungen, Bankprodukte (Karten, Kredite usw.)) gut in die Anwendung integriert.

Aber dann wurde die Anwendung umständlich und unpraktisch .

So erschien das MKBMobile 2.0-Projekt mit einer mutigen Interface-Idee - Trello Pages.

Der Trello Pages-Ansatz besteht in der Tat aus Boards, die in unserer Version am oberen Bildschirmrand an der oberen Navigationsleiste angebracht sind. Der Ansatz ermöglicht Ihnen eine schnelle Navigation zwischen Boards (Seiten).




Die Vorteile dieses Ansatzes:

• Skalierbarkeit, unendlicher Raum links / rechts und unten;
• Trennbarkeit, jeder Funktionstyp wurde auf einer separaten Seite platziert;
• Perfekt für iPad und iPhone.

Diese Idee hatte jedoch einige Nachteile:

• Die wichtigsten Navigationsmenüelemente waren schwer zugänglich.
• Eingehende Push-Benachrichtigungen und SMS-Benachrichtigungen verursachten zusätzliche Schwierigkeiten bei der Arbeit mit dem oberen Navigationsmenü.
• Dieser Ansatz entsprach nicht den Richtlinien für die Benutzeroberfläche von Apple.

So wurde die aktuelle Version der ICD Mobile Bank, MKBMobile 3.0, geboren.

In dieser Version haben wir das klassische Navigationsmodell aus der unteren TabBar von Apple HIG (Human Interface Guidelines) übernommen.





Bei der Umstellung auf diese Version haben wir viele negative Erfahrungen mit der klassischen MVC-Architektur von Apple gesammelt.

Unser Team wuchs und wir brauchten eine niedrige Schwelle, damit neue Mitarbeiter in das Projekt eintreten konnten.
Ein weiterer Punkt hat uns nicht gestört: Unit-Tests des Verhaltens grafischer Elemente, für die Tests über den Xcode UI-Test durchgeführt wurden. Dies war ein langer Prozess zum Starten einer Anwendung auf einem Emulator (Gerät) mit Emulation von Benutzeraktionen.

All diese Anforderungen führten zur Verwendung eines neuen architektonischen Ansatzes - VIPER.
Klassisches VIPER-Modell:



Nachdem wir uns jedoch viele Ansätze bei der Implementierung von VIPER für iOS angesehen hatten, entschieden wir uns für die Rambler & Co-Lösung mit unseren Abschweifungen.

Als Basis haben wir ein Buch von Rambler & Co.



Die Hauptaufgaben, die VIPER uns bei der Lösung geholfen hat:

• Aufteilung großer Klassen (Massive View Controller) mit mehr oder weniger klar definierten Verantwortungsgrenzen;
• Anwendung der SOLID-Prinzipien in ihrer ganzen Pracht;
• niedrige Schwelle für neue Mitarbeiter, die in das Projekt eintreten;
• Testen von UI-Einheiten.

Es ist wichtig sofort zu beachten, dass VIPER keineswegs eine Reihe strenger Vorlagen und Regeln ist. Dies ist vielmehr eine Liste von Empfehlungen, anhand derer Sie eine flexible und wiederverwendbare Architektur für mobile Anwendungen erstellen können.

Wie unser Projekt aussah:



Die Struktur des VIPER-Moduls in unserer Implementierung:

1. Die wichtigste Klasse ist die Modulklasse, sie weiß alles über jeden, erstellt die Objekte der für Interactor erforderlichen Dienste, weiß, wie alle Teile untereinander verbunden werden. Ansicht, Router, Präsentator usw.



Es ermöglicht auch die Kommunikation mit anderen VIPER-Modulen über die Eingabe- und Ausgabeprotokolle ModuleInput und ModuleOutput.

Ähnliche Ein- und Ausgabeprotokolle haben alle Teile des VIPER-Moduls (Ansicht, Router, Presenter usw.).

Wir waren uns einig: Wenn keine Protokolle oder Teile des VIPER-Moduls benötigt werden, verwenden wir diese nicht und reservieren keine leeren Klassen für sie.

2. Interactors (Interactor) - Blendet die Geschäftslogik aus.

Wir haben eine zusätzliche Serviceebene eingeführt. Service - Ein Objekt, das für die Arbeit mit seinem spezifischen Datentyp verantwortlich ist. Beispielsweise ist ein Hilfesystemdienst für Verzeichnisse verantwortlich (Dateien mit Vereinbarungen, Details usw.).

3. Präsentator - empfängt Informationen aus der Ansicht zu Benutzeraktionen und konvertiert sie in Anforderungen für Router, Interactor. Außerdem empfängt er Daten von Interactor, bereitet sie vor und sendet die Ansicht zur Anzeige.

4. Router - ist für die Navigation zwischen den Modulen verantwortlich.

5. Ansicht - ist für die Anzeige von Daten auf dem Bildschirm verantwortlich und benachrichtigt den Präsentator über Benutzeraktionen. Passiv, es fordert niemals Daten an, sondern empfängt sie nur von Presenter.

Unsere Module können zusammengesetzt sein.

Das heißt, unabhängige VIPER-Module einschließen. Die Hauptproduktseite besteht beispielsweise aus einer Reihe unabhängiger Teile: Kontostand, Vorlagen-Widget, Abschnitte verschiedener Arten von Bankprodukten und Wechselkurse.

Alle diese Teile sind unabhängig und können ihr eigenes Leben führen - sie haben eine eigene API mit dem Bankserver, sie haben unabhängige Datenmodelle. Um sie auf der Hauptseite anzuzeigen, werden Container (übergeordnete Ansicht) vorbereitet, in die diese Widgets (Ansicht) eingefügt werden.





Unsere mobile Anwendung für iOS wächst und entwickelt sich ständig weiter. Es wird von immer mehr unserer Kunden genutzt.




Welche folgenden Tools möchten wir einführen:

• SwiftLint, ein Dienstprogramm von Realm-Entwicklern zur automatischen Überprüfung von Swift-Code;
• volles CI basierend auf Fastlane;
• Volle Nutzung der Instrumente von Xcode (Zuordnungen, Lecks, Zombies usw.)

Folgen Sie unseren Artikeln! Wir sehen uns und vielen Dank für Ihre Aufmerksamkeit!