ICD Mobile Banking: História do Desenvolvimento

Oleg Ivanov, Chefe do Centro de Competência em Canais de Serviço Remoto, Departamento de Desenvolvimento de TI, Diretoria de Tecnologias da Informação, Moscow Credit Bank (ICD)

Para nós, o desenvolvimento de um aplicativo móvel começou do zero, portanto, neste artigo, começaremos do início: determinando o que é e quais funções ele deve ter. E então, percorreremos todo o caminho - desde a compra de novos gadgets até o teste do aplicativo e o lançamento. Contaremos a história do desenvolvimento de nossa aplicação com recuos tecnológicos. Vamos descrever quais problemas encontramos. Infelizmente, não seremos capazes de cobrir todas as abordagens, princípios e soluções tecnológicas que foram usadas no desenvolvimento deste artigo de revisão, mas nos concentraremos nos pontos mais interessantes.

Além disso, haverá ênfase no desenvolvimento para iOS. Antes de começar, vamos decidir o que é o Mobile Bank.

Um banco móvel é o gerenciamento de contas bancárias usando o aplicativo bancário em um smartphone (iPhone, etc.), um computador tablet (iPad, Samsung Galaxy Tab etc.). Para operações bancárias, é necessária uma confirmação em duas etapas, usando códigos únicos via mensagens SMS.

As principais operações bancárias do Mobile Bank:

• uso de produtos bancários (contas, cartões, depósitos, empréstimos, pacotes de serviços etc.)
• ver saldo da conta
• declaração
• pagamento de contas por serviços móveis
• pagamento de serviços de habitação
• transferir fundos de cartão para cartão
• pagamentos regulares
• reembolso de empréstimos
• transferência de fundos para depósito
• bloqueio de cartão de pagamento
• e outros

Aplicativos bancários móveis são aplicativos bancários na Internet adaptados para telas pequenas de smartphones e para sistemas operacionais (iOS da Apple, Android do Google) instalados em dispositivos móveis. Vale ressaltar que a gama de modelos de dispositivos executando o sistema operacional Android é muito ampla: Samsung, LG, Xiaomi, Huawei etc., o que complica o desenvolvimento e o suporte do aplicativo para Android.

Fonte - MKBMobile 1.0

O projeto de aplicação do Mobile Bank foi transferido para nossa equipe de uma empresa terceirizada, escrito no objetivo C.

É assim que o projeto olhou através dos olhos do usuário:





Este projeto tornou-se uma startup e um teste de nossas capacidades. Nossa equipe teve poucas experiências de desenvolvimento para a plataforma móvel iOS, mas assumimos o projeto com ousadia.

Por onde começar? Quando pensamos em desenvolver para iOS, a primeira coisa que precisamos:

1. Precisa do iMac

A Apple é famosa pelo alto preço de seus produtos. Mas economizar não vale a pena - esta é a velocidade do seu desenvolvimento!

Uma configuração aproximada e ideal que nos convém:

• Processador Intel Core i5 de sétima geração com velocidade de clock de 3,8 GHz (Turbo Boost de até 4,2 GHz)
• DDR4 de 32 GB 2400 MHz
• Unidade de fusão de 2 TB
• GPU Radeon Pro 580 com 8GB de VRAM

O custo aproximado dessa máquina é de 190.000 rublos.

Há uma opinião - para os programadores precisam do iMac Pro. É assim :) Mas o preço por eles é pequeno e, se sua empresa estiver pronta para comprá-los, isso aumentará a velocidade do seu desenvolvimento e, é claro, aumentará o nível estético do seu escritório.

2. Precisa de dispositivos iOS

"Quanto e qual?" - a primeira pergunta surge. Tudo depende da sua aplicação.
Se o seu aplicativo suportar apenas o iPhone, pelo menos 2 tamanhos diferentes serão pequenos (por exemplo, iPhone SE) e grandes (por exemplo, iPhone 8 Plus).

Se o seu aplicativo também suportar iPad, você precisará de um iPad.

Em seguida, vem o sistema operacional - seu versionamento. Se o seu aplicativo suportar a versão mínima, por exemplo, a partir do iOS 8.0, você precisará estocar no dispositivo cada número de série do iOS e lembre-se de "preservar" (não atualize) esta versão no dispositivo e monitorar a aparência de novas versões do iOS, sem esquecer de selecionar um conjunto para ele dispositivos.

Obviamente, pela primeira vez, você pode conviver com os simuladores do Xcode, mas os dispositivos físicos impõem suas próprias colisões que não aparecem nos simuladores.

Se você não deseja ter seu próprio farm de dispositivos, pode procurar as partes das empresas que oferecem este serviço: AWS Device Farm, Xamarin Test Cloud etc.

Como já mencionado, nosso aplicativo é suportado para iPhone e iPad. No momento da redação deste artigo, nosso próprio Farm (!) Possui cerca de 30 dispositivos de diferentes tipos e versões do sistema operacional.

3. Você precisa decidir sobre a abordagem de desenvolvimento para iOS (nativa ou alternativa).

Tentamos as seguintes opções alternativas de desenvolvimento para iOS:

Phonegap / Cordova

PhoneGap foi criado originalmente por Nitobi. Em 2011, a Adobe adquiriu a Nitobi e a marca PhoneGap. A Adobe então transfere uma versão do PhoneGap, denominada Cordova, para a Apache Foundation, deixando a marca PhoneGap e o próprio produto. Como resultado, o Cordova pode ser visto como um mecanismo sob o capô do PhoneGap (assim como outras estruturas híbridas). O PhoneGap, por sua vez, adiciona seus próprios recursos adicionais aos recursos do Cordova.

O PhoneGap é, de muitas maneiras, muito semelhante ao Ionic. Ele também oferece aos desenvolvedores a capacidade de criar aplicativos de plataforma cruzada usando tecnologias da Web e também é construído com base no Apache Codova. No entanto, o PhoneGap não está vinculado a nenhuma estrutura Javascript específica; portanto, os desenvolvedores têm mais opções sobre o que e como criarão seus aplicativos.

Infelizmente, o PhoneGap usa o WebView (que é bastante lento no iOS), então as coisas nem sempre são brilhantes com a velocidade dos aplicativos criados com base nessa estrutura.

Xamarin

Fundada em 2011, a Xamarin, a família de produtos Xamarin, foi adquirida pela Microsoft após cinco anos de existência. Hoje, os produtos Xamarin apresentam uma abordagem muito interessante para o desenvolvimento de aplicativos móveis de plataforma cruzada no mercado: os aplicativos são escritos em C # e, em seguida, o Xamarin o compila em um aplicativo nativo para iOS ou Android, enquanto o Xamarin usa o Mono como a tecnologia subjacente, em vez da plataforma cruzada. e é fornecido. Os desenvolvedores do Xamarin dizem que os aplicativos resultantes usam a API da plataforma nativa para a qual o aplicativo é compilado; portanto, o comportamento do aplicativo resultante não é diferente do comportamento de qualquer outro aplicativo na mesma plataforma. O desenvolvimento, a propósito, pode ser feito usando o Visual Studio (o que não é surpreendente).

Apesar do fato de que a maior parte do código do projeto pode ser usada sem alterações em cada uma das plataformas móveis suportadas, no entanto, alguns fragmentos precisam ser escritos especificamente para a versão do aplicativo para iOS e Android.

Mas essas abordagens fornecem a chamada aplicação "híbrida".

Vantagens de opções alternativas:

• multiplataforma (tendo feito um aplicativo, ele pode ser exportado para qualquer sistema operacional);
• o tempo de desenvolvimento é menor que o nativo.

Contras de alternativas:

• trabalha mais devagar que aplicativos nativos;
• não tem acesso total aos recursos técnicos do dispositivo;
• geralmente os plug-ins existentes são preteridos, então às vezes você precisa escrever seus próprios;
• a interface do usuário é visualizada usando o navegador interno, e isso cria dificuldades em obter feedback comparado ao aplicativo nativo;
• nem todos os controles são implementados.

E decidimos continuar o desenvolvimento "nativo" do nosso projeto.

Caminho nativo da Apple

4. Primeiro de tudo, precisamos de uma ferramenta para desenvolver e escrever código - precisamos de um IDE Xcode

O Xcode é um ambiente de desenvolvimento de software (IDE) integrado para plataformas macOS, iOS, watchOS e tvOS desenvolvido pela Apple. A primeira versão foi lançada em 2001. As versões estáveis ​​são distribuídas gratuitamente pela Mac App Store. Os desenvolvedores registrados também têm acesso às versões beta através do site da Apple Developer.

É assim que a criação e o trabalho em um aplicativo simples como o Single View App no ​​Xcode se parecem:





Alguns pontos interessantes sobre o Xcode:

O Xcode oferece um kit de ferramentas muito conveniente para criar uma UI (interface do usuário) - Storyboard.





Mas a maioria dos projetos (aplicativos) para iOS é atendida não por um desenvolvedor, mas por vários (a equipe de desenvolvimento), e ao usar um Storyboard para todas as telas de aplicativos ao usar sistemas de controle de versão distribuídos (SVN, Mercurial, GIT etc.), a fusão de desenvolvimentos se transforma em inferno real.

Nossa equipe concordou com uma abordagem: um Storyboard - um ViewController .
Com essa abordagem, o problema descrito acima desaparece, pois geralmente um desenvolvedor implementa um recurso, ou seja, todas as telas desse recurso.

Para reduzir a carga no Storyboard ao usar o Segue, você pode usar a função 'Refatorar no storyboard' . Essa refatoração do storyboard cria um link no Storyboard pai, o que leva a um novo Storyboard separado, onde o ViewController desejado é implementado.

Também digno de nota é a ferramenta de depuração do Xcode - Breakpoint .
O ponto de interrupção é uma ferramenta de depuração que permite pausar a execução do programa até um determinado ponto. Isso nos permitirá examinar o código do programa (descobrir os valores das variáveis ​​no momento, fazer alguns cálculos, etc.) para descobrir onde os erros ocorrem.



Essa ferramenta é inteligente: temos botões de controle de acesso (Step Over, Step Into), manipulando os quais navegamos pelo nosso código. Também temos acesso à análise dos valores das variáveis ​​e ao trabalho com logs na saída do console.
Quando a tecla Control pressionada no ponto de interrupção do indicador exibe um menu de comandos. Aqui você pode definir condições adicionais para acionar um ponto de interrupção, adicionar ações etc.
Por exemplo, definimos uma condição de acionamento para o ponto de interrupção: a variável step assumirá o valor 4. E depois que o aplicativo iniciar, o programa interromperá sua execução nesse ponto de interrupção somente quando a variável step aceitar o valor 4 e não antes.



Podemos adicionar Expressão adicional (propriedades e até cálculos!).

5. Você precisa decidir sobre a linguagem de programação Objective-C ou o novo Swift

O projeto que recebemos foi escrito em Objective-C, mas a nova linguagem de programação Swift já estava no horizonte.

Quais são essas linguagens de programação?

O Objective-C é uma linguagem de programação compilada e orientada a objetos usada pela Apple, construída com base na linguagem C e no paradigma Smalltalk. Em particular, o modelo de objeto é criado no estilo Smalltalk - ou seja, as mensagens são enviadas aos objetos.

A linguagem Objective-C existe desde 1989, a última vez que foi atualizada em 2006, mais
10 anos atrás. A popularidade do iOS está em constante crescimento, o que requer a melhoria da qualidade do aplicativo. Para trabalhar com o Objective-C, é necessário um desenvolvedor altamente qualificado.

Tudo isso se tornou pré-requisito para a criação da linguagem de programação Swift.

A Apple começou a desenvolver Swift em 2010. Em 2 de junho de 2014, esse idioma foi oficialmente apresentado na Apple Worldwide Developer Conference (WWDC). Um guia gratuito de 500 páginas para usá-lo estava disponível na iBook Store.

O Swift 1.0 foi lançado em 9 de setembro de 2014, juntamente com a versão Gold Master do Xcode 6.0 para iOS.
Em 8 de junho de 2015, a Apple lançou uma nova versão do Swift 2.0 com melhor desempenho e uma nova API de tratamento de erros. A sintaxe do idioma foi aprimorada; uma função para verificar a disponibilidade das funções Swift nos sistemas operacionais de destino foi exibida.

Em 3 de dezembro de 2015, uma versão beta do Swift 3.0 foi lançada com suporte para OS X, iOS e Linux, licenciado sob a licença Apache 2.0 de código aberto.

Em 19 de setembro de 2017, o Swift 4.0 foi lançado.

Em setembro de 2018, juntamente com a nova versão do iOS 12, uma nova versão estável do idioma Swift 4.2 foi lançada e uma versão beta do Swift 5.0 apareceu. A versão 5.0 finalmente anunciou a operação estável da ABI com bibliotecas padrão (Swift Dynamic Library), suporte para expressões regulares e uma solução de primeira classe para processamento de dados paralelos com o modo de processamento assíncrono / aguardado.

Com base no exposto, decidimos usar apenas o Swift em novas formas, para suportar formas antigas, reescrevendo-as gradualmente.

6. Em seguida, você precisa entender a arquitetura do projeto - decidimos deixar a arquitetura MVC da Apple

O Model-View-Controller (MVC) atribui uma das três funções aos objetos em um aplicativo: modelo, exibição ou controlador. A arquitetura define não apenas as funções que os objetos desempenham no aplicativo, mas também a maneira como os objetos interagem entre si. Cada um dos três tipos de objetos é separado dos outros por bordas abstratas e interage com objetos de outros tipos por essas bordas (https://developer.apple.com/library/archive/documentation/General/Conceptual/DevPedia-CocoaCore/MVC.html).



Mas, aplicando essa abordagem, encontramos os seguintes problemas, que pudemos resolver apenas mudando para a nova arquitetura no MKBMobile 3.0:

• O MVC não fornece instruções claras sobre quais entidades e classes você precisa criar e quais não. A estrutura e a arquitetura do modelo, bem como sua interação com o controlador, permanecem inteiramente na consciência e imaginação do (s) desenvolvedor (es).
• Má compreensão da área de domínio. I.e. quando um desenvolvedor adiciona novas funcionalidades, em vez de criar novas entidades e refatorar a arquitetura existente, novas funcionalidades são adicionadas ao ViewController. O que levou ao seguinte problema: Massive View Controller - muito código no ViewController.

7. E o mais legal é o SDK do iOS (https://developer.apple.com/documentation/)

O iOS SDK fornece um grande número de Frameworks.

Usamos a seguinte lista de estruturas com entusiasmo especial em um aplicativo bancário:

• PushKit e UserNotifications para trabalhar com notificações push;
• PassKit por trabalhar com o Apple Pay;
• CallKit (em conjunto com WebRTC) por trabalhar com serviços de VoIP;
• AVFoundation para trabalhar com recursos de áudio;
• Contatos para obter acesso aos contatos do usuário;
• CommonCrypto para trabalhar com funções criptográficas.

Então, decidimos o necessário, somos cobrados e prontos para realizações ...

Por algum tempo, novos recursos (funcionalidade - novas transferências, pagamentos, produtos bancários (cartões, empréstimos etc.) foram incorporados ao aplicativo.

Mas então o aplicativo se tornou complicado e inconveniente .

Então, o projeto MKBMobile 2.0 apareceu com uma ideia ousada de interface - Trello Pages.

A abordagem das páginas do Trello, na verdade, são quadros anexados à parte superior da tela, em nossa versão, à barra de navegação superior. A abordagem permite que você faça uma navegação rápida entre painéis (páginas).




As vantagens desta abordagem:

• escalabilidade, espaço infinito esquerdo / direito e baixo;
• separabilidade, cada tipo de funcionalidade foi colocada em uma página separada;
• Perfeito para iPad e iPhone.

Mas havia algumas desvantagens nessa idéia:

• Os itens principais do menu de navegação estavam com acesso difícil;
• as notificações push recebidas e as notificações SMS criaram dificuldades adicionais ao trabalhar com o menu de navegação superior;
• essa abordagem não estava em conformidade com as Diretrizes de interface humana da Apple.

Assim, a versão atual do banco móvel ICD, MKBMobile 3.0, nasceu.

Nesta versão, adotamos o modelo de navegação clássico do TabBar inferior da Apple HIG (Human Interface Guidelines).





Passando para esta versão, adquirimos muita experiência negativa usando a arquitetura MVC clássica da Apple.

Nossa equipe cresceu e precisávamos de um limiar baixo para novos funcionários entrarem no projeto.
Além disso, mais um ponto não nos incomodou: o teste unitário do comportamento dos elementos gráficos, para o qual o teste foi usado por meio do Xcode UI Test, que foi um longo processo de iniciar um aplicativo em um emulador (dispositivo) com emulação de ações do usuário.

Todos esses requisitos resultaram no uso de uma nova abordagem arquitetônica - VIPER.
Modelo VIPER clássico:



Mas, tendo analisado muitas abordagens na implementação do VIPER para iOS, decidimos pela solução Rambler & Co com nossas digressões.

Como base, colocamos um livro da Rambler & Co.



As principais tarefas que o VIPER nos ajudou a resolver:

• partição de grandes classes (Massive View Controllers) com limites de responsabilidade mais ou menos claramente definidos;
• aplicação dos princípios do SOLID em toda a sua glória;
• baixo limiar para novos funcionários entrando no projeto;
• Teste de unidade de interface do usuário.

É importante observar imediatamente que o VIPER não é de forma alguma um conjunto de modelos e regras estritos. Em vez disso, esta é uma lista de recomendações, após as quais é possível criar uma arquitetura de aplicativo móvel flexível e reutilizável.

Como nosso projeto começou a se parecer:



A estrutura do módulo VIPER em nossa implementação:

1. A mais "principal" é a classe Module, sabe tudo sobre todos, cria os objetos dos serviços necessários para o Interactor, sabe como conectar todas as partes entre si, View, Router, Presenter, etc.



Ele também fornece comunicação com outros módulos VIPER por meio dos protocolos de entrada e saída ModuleInput e ModuleOutput.

Protocolos de entrada e saída semelhantes têm todas as partes do módulo VIPER (View, Router, Presenter, etc.).

Concordamos: se não há necessidade de protocolos ou partes do módulo VIPER, não os usamos e não reservamos classes vazias para eles.

2. Interatores (Interator) - oculte a lógica de negócios.

Introduzimos uma camada adicional de serviços. Serviço - um objeto que é responsável por trabalhar com seu tipo de dados específico. Por exemplo, um serviço do sistema de ajuda é responsável por diretórios (arquivos de contratos, detalhes etc.)

3. Presenter - recebe da View informações sobre ações do usuário e as converte em solicitações para o Roteador, o Interactor, e também recebe dados do Interactor, as prepara e envia a View para exibição.

4. Roteador - é responsável pela navegação entre os módulos.

5. Exibir - é responsável por exibir dados na tela e notifica o Presenter sobre as ações do usuário. Passivo, nunca solicita dados, apenas os recebe do Presenter.

Nossos módulos podem ser compostos.

Ou seja, inclua módulos VIPER independentes. Por exemplo, a página principal do produto consiste em um conjunto de partes independentes: saldo, widget de modelo, seções de diferentes tipos de produtos bancários e taxas de câmbio.

Todas essas partes são independentes e podem viver suas próprias vidas - elas têm sua própria API no servidor do banco, modelos de dados independentes. Para exibi-los na página principal, os contêineres (Visualização pai) são preparados, onde esses widgets (Visualização) são inseridos.





Nosso aplicativo móvel para iOS está em constante crescimento e desenvolvimento. É usado por mais e mais de nossos clientes.




Quais são as seguintes ferramentas que planejamos introduzir:

• SwiftLint, um utilitário dos desenvolvedores do Realm para verificação automática do código Swift;
• IC completo baseado em fastlane;
• Uso total dos instrumentos do Xcode (alocações, vazamentos, zumbis etc.)

Siga nossos artigos! Vejo você e obrigado por sua atenção!