One Day at Alfa Bank: Mobile Development



    Alfa-Bank has become one of the pioneers of mobile banking: applications for iOS and Android appeared at him back in 2010, when the opportunity to "replenish the balance of the phone from the phone itself" was unusual. And what about mobile development in the bank now, after all these years?

    Previously, we published the text “One Day at Alfa Bank: Java Development,” and now it's finally time to continue, where we asked about working on iOS and Android applications. Ilya Tsarev and Anton Pukhonin answered us . If you write their names as iLya and Anton, it immediately becomes clear who is responsible for what in the company!

    - When in 2010 the habrauser reportedabout the appearance of an Android application at Alfa Bank, he wrote, "Market research on the need for such an application took more than six months." Since then, mobile banking has become such an integral part of life that today these words sound funny. And how does this change in the world affect mobile development? You have been working on Alfa-Bank applications not from the very beginning, but in recent years you have found out - what has changed over the years?

    Anton: Firstly, speed: now you need to quickly saw, release quickly, and drag a lot of functionality into the mobile phone.

    And the second is that now mobile first and even mobile only. The application should now have everything, even underutilized. About three years ago, my personal opinion was this: in a mobile application you need those functions that you use at least once a month. If less often - go to the site and go, and everything will be fine. Something is used every few years, for example, activation of a card. Before, I would definitely say: why is this needed in the application? Open the site.

    Ilya: Insert it into the ATM.

    Anton: It’s kind of like the bottom of an ATM! In general, now this doesn’t work anymore, you need to add it to the mobile application.

    In order to develop such rarely used features as quickly as possible and spend less time maintaining them, WebView is increasingly appearing in applications. In the “card activation” section, where a user visits once every five years, he doesn’t need beautiful animations and a perfect interface. He can poke a button once and forget about it. And if we develop this feature not in the native, but in WebView, we get accelerated development, because it is already implemented on the site, and update speed, because we can update something in just a few minutes. This has greatly influenced our work.

    The life of JavaScript developers, of course, was also affected. Before you make up the screen and don’t worry about the mobile phone, but now you know that the site will probably be opened on your smartphone, you need adaptive layout, and there is also a native application, if you please look like it inside the mobile. They tweaked the CSS for us.

    - The words “mobile only” were spoken - is it possible that a feature is added to Alfa-Mobile, but not on the site?

    Anton: There aren’t many, but there are. For example, in the case of affluent (5% of the richest customers of the bank), there are bonuses when certain conditions are met (to have more than X on the money account, to make transactions for more than Y per month), and certain related functionality is available only on mobile.

    - Again I recall the 2010 post about the advent of the Android application. I'm in the comments thenI was unpleasantly surprised at its size of 29 megabytes: in those days Android users had to count every megabyte, and a typical application weighed much less. Now it seems like different times, even in inexpensive smartphones, dozens of gigabytes, but still there are posts "why the Facebook application is so big, this is crazy." Therefore, it is interesting to compare: how much do your applications weigh now?

    Ilya: We have 66 megabytes on iOS.

    Anton: We have about 40, plus or minus five.

    - Is size a pressing issue for you now? Does it grow over time, does one have to make efforts to reduce it?

    Anton:The size of the Android application is not particularly increasing. The amount of code is growing, some libraries are being added, but over the past two years the application has only decreased. Google introduced VectorDrawable, the resources were not stored in PNG sizes in 4 sizes, but simply as a vector drawing that weighs a few kilobytes. No soap is visible in the application in the UI. Now, from the big pictures in the mobile application, in my opinion, there are only a couple of backgrounds. Everything else extends from the backend as needed.

    Ilya: I just opened the App Store - he writes that the application weighs 90 megabytes, but this is an unpacked version, it will take up so much space after installation. What is downloading, at the time of my arrival in Alpha weighed 60 megabytes, now 66. What is the reason for growing? Partly because of the Swift, which was not there before. Besides the resources, yes ...

    But, for example, I have 12 gigabytes of traffic per month on my iPhone. It seems to me that this is not a very urgent problem.

    Anton: For Moscow.

    Ilya: We have a distribution of users with a very large bias to Moscow.

    In general, we are not doing anything radical to reduce the application, and it is unlikely that you will particularly do something. All PNG's shook, and we constantly refactored the code, we removed excess. But even if you remove 100 code files, it will take a maximum of one megabyte, and that’s if you are lucky. That is, all simple things have already been done. We make new ones as needed.

    Now the App Store has a limit of 150 megabytes when downloading via a mobile network, we are passing through normally, there are no problems. Facebook really weighs about 200 megabytes, and 400 when unpacked. They have a lot of libraries, all kinds of libraries, and at the same time they are also released very often. I read one interesting post about sizes. There, a man wrote about application updates "why I have to download 300 megabytes every week, you're crazy." But it seems that we are all going into this story, all companies are trying to release more often, often to make some kind of value, and this is cool.

    Anton:In the meantime, I looked at the exact size of the Android version: now it weighs 42.26 megabytes. In principle, we strive to reduce the size to the extent possible. We clean all the resources that take up a lot of space, translate everything either into a vector, or into rendering in the code, or into loading from the backend.

    But it's like working on the overall quality of the code, the application. If the task was to “cut the application to a minimum”, we would take it and cut it even harder. But why look for yourself an extra job where there will be little result from it? In product metrics, it seems that even if we reduce the application from 40 megabytes to 10, this will bring the product a small value. It is better to spend time optimizing downloads, speed, beautiful animations - this will be better for the user. Well, this is my subjective opinion.

    - The support of Apple Pay and Google Pay is very noticeable for users, but this story is not about the bank’s mobile application. When their support is introduced, are mobile developers required at all, and how big is their role?

    Anton: If you just need to add Apple Pay / Google Pay payment for the bank, then you don’t need to attract mobile phones and generally the front. But if you want to do well, then they will be needed.

    Ilya: Well - this, for example, is about the fact that from our application you can pause the operation of any digital card. There is a list of devices where Apple Pay and Google Pay are running, you can pause or unlink them from the application.

    Anton:But in general, the work at the front is minimal. Even if you set the maximum goal and carefully read the documentation, it is done in 2-3 weeks. The main work falls on processing - make friends with the terminals, agree with Mastercard and Visa. Each map binding is essentially a new virtual card. A new identifier is allocated for her, and all the problems are somewhere in the gut. And we just need to make friends with the Apple Pay or Google Pay app.

    Ilya: Well, either Apple or Google should allow it.



    - The word “bank” is associated with “security”, but how does this affect mobile development? For example, doesn’t it turn out that all work should be carried out exclusively within the office?

    Ilya:For all developers, there is a VPN that connects to our internal network, so working on applications is possible from anywhere in the world, there is access. There are login passwords, certificates on laptops, if a device is lost, you can simply block everything. In general, since mobile developers do not have access to any battle servers, the risks are lower.

    Anton: Speaking about the security of the mobile application, most vulnerabilities are closed at the API level: all operations are confirmed by one-time passwords sent via SMS, filters are configured to block suspicious operations. With minimal suspicion of fraud, the operation is blocked and the call center operator calls the client. Interaction with the server is via an encrypted channel, certificate verification has been implemented.

    - More banks are associated with conservatism. How easy is it to use a new one in a mobile (for example, what does migration to Swift look like in your case) or non-standard?

    Ilya: We have been writing Swift for the last year and a half, we started with 2.3, now in the fourth. We look at new and unusual technologies openly, there are no bans. Of the curious, we can probably say that we work with the UI only through code and use SnapKit for this.

    Anton: Yes, there are no prohibitions, but there is a common internal community of developers. If you prove that your technology is promising, necessary and really useful, then everyone starts using it.

    But here you need to understand that the Alpha Mobile project is many years old, there is a large tail of functionality and legacy. Much has been rewritten, of course, but the old remains. And when a lot of people push the project forward, then ... When you say “your MVP is no longer fashionable today, let's introduce a stylish-fashionable-youth MVRx”, they ask a logical question: “Dude, now you’ll apply your new architecture, what will we do with to the rest? We will have to maintain two architectures independently. ” And if everyone continues to drag whatever he wants, then living with it will be more and more difficult.

    If you prove, roughly speaking, that the transition from AsyncTask to Rx is worth it, then we develop a plan, how we implement it, how we refactor the old one so as not to delay 2-3-4 approaches.

    Ilya:That is, everything works through the community. The community accepts - so let's go.

    - Does it happen that the community is divided into two camps?

    Ilya: It happens. Then the final decision is made by the lead.

    Anton: This happened to us too. For example, with writing unit tests. We have two applications, for individuals and for legal. When we thought about writing tests better, half said “let's write tests on Kotlin” (it was about a year ago), and half said “Kotlin is good, but writing Kotlin in pure JUnit is boring, too much code, let's we will drag Spock and Groovy. "

    We looked at Spock and Groovy, half said "great, let's write like that." And the other half said that closures in Groovy are something beyond reason, and let's write in Kotlin. As a result, now we have tests written in Kotlin in one application and Groovy in another.

    - How synchronized is your iOS and Android? New features appear simultaneously on both platforms?

    Ilya: We work on a scrum, so each team is a small startup with participants on all layers, and it also makes a new feature on all layers at once. Accordingly, usually the functionality is ready approximately the same. There may be a small out of sync version release: for example, release on Android earlier, and the feature will be released a little earlier. Of course, we make big changes like a redesign together.

    - Your applications are installed on millions of smartphones, what is the effect of such a scale? For example, do you have to bother with exotic things like strangely behaving little-known smartphones? Does it turn out that even very rare problems cause someone to react negatively and need to be fixed?

    Ilya:Yes, always, when you think “there will definitely not be such a case”, it will be 100%. When I just got a job, a month later there was such a case when we thought "there will be no one", and, of course, on a huge user base, it all got out, and I had to edit it. Yes, there are always such cases. Therefore, testing is especially important for us: both unit tests in the code that verify their business logic (including some boundary cases), and UI tests that automatically verify that the business scenarios work out, and acceptance testing, where the tester checks that the layout has not crawled out anywhere and everything is okay, and regression, when they check the application for impairment of functionality by hand.

    Anton:As for exotic smartphones: everything is clear in iOS, the base of devices is not very large, and Android is a zoo of devices. Despite the fact that the main bugs in the application are fixed, sometimes some inexplicable space occurs on the Chinese no-name devices, and the application crashes.

    Sometimes Android itself crashes, we can do little with it. Sometimes modified device manufacturers fail. We solve such problems trivially: we look for such a device and find out what is the cause of the defect. “Guys who have such and such a device in Moscow, let's test on it” - frequent messages in our corporate chats.

    A couple of years ago there was a case when from one device on the Play Store there were the same reviews “it doesn’t work”, nothing was clear, and then we went to the store - “Can we see this smartphone?” We got it, we pretended that within 30 minutes we decide whether to buy this device for a conditional thousand rubles, and in fact we installed a special assembly of the application, found the reason for the fall, came to the office, fixed it, reloaded it. There, the problem was related to the resolution: the device was large, and the resolution was somehow very small.

    - To “Android itself sometimes crashes”: do you feel any pain on his part? For example, Google can take Doze mode to restrict applications - does it hit you?

    Anton: Let's just say that it’s worth starting with the fact that Google presents everything in advance: it describes the changes, it talks about I / O, and releases new versions for developers in advance. And we try to close everything critical in advance.

    Sometimes it takes effort. When runtime permissions appeared, it was a lot of pain, I had to sit a week or more, catch all the cases in the application. But if you follow the news, then you will not have sudden problems at the time of release.

    And the problems with Android in general ... Well, for example, last year we were forced to abandon support for Android 4.0. Why? WebView fell on so many devices. AsyncTask was not stupid there, the system could not find such a class. We looked at what solutions are available, and nothing came of it for us; we had important functionality implemented using WebView.

    We had to do something, and we decided that it was better to leave users with a version lower than 4.1 (there were 2-2.5% then) on the current version, and further updates came out only for 98%.



    - In presentations of new versions of iOS / Android, you can see spectacular things like ARKit, but augmented reality is clearly not about you. When the new version comes out, how much does it affect you?

    Ilya:Well, just augmented reality actually about us! Now I’ll launch it on my iPhone and show you where you can search for an ATM in augmented reality by driving your smartphone around. This has long been done, not yet on ARKit, of course.

    In general, about iOS updates - that's when we switched from and completely redesigned the interface from iOS 6 to iOS 7, then everything that could have broken broke. I had not worked in Alpha then, but in another project we switched over for two months, it was horror. And after that, everything is easier. In iOS 11, it seems that nothing has changed dramatically for us, although Apple has done a lot inside, for example, its file system - this is generally cool. By the way, after updating, all the photos from my phone were erased. It’s good that the backups remained, then loaded.

    So, of the innovations of iOS 11, little is relevant for us. It’s clear that we are using technical things: we are switching to new versions of Swift, Xcode. This is a normal process, so that everything breaks down, it’s not there. Even with the release of the third Swift, when there were a lot of groans in the industry.

    Anton: Here’s the latest Android update that didn’t affect users very much, but really really affected users. They presented a lot of architectural things, we immediately began to look closely and think - for example, we decided to do new functionality on Room, this is the database that Google introduced. And Android Architecture Components were also immediately interested, although initially they were too crude for us to be ready to use safely.

    And from the new for the user - Instant Apps is a cool thing, which we also noticed, but did not rush to implement it. I want any section of the application to be launched through the Instant App, and this requires deep refactoring of the entire application. At the scale of the Alpha Mobile application, this is very complex and time consuming. I hope that in 2018 we will be able to implement this.

    - In iOS 11, CoreML was also added. How relevant is machine learning to you?

    Ilya: CoreML in the form in which it is now, it seems to me, is of little relevance. He does not know how to train models, only use ready-made ones. It would be cool if you could train the model for a specific user who uses this particular device. For example, everyone pays a mobile phone for 500 rubles, and he pays for 50. And now we give him suggest for 500, because everyone pays for 500. It would be better by 50.

    On the backend, this is more relevant for us. For example, to predict what transactions the user will have. If he has some regular expenses, for example, he pays for utility bills every month, it is possible to predict with a certain probability that they will also be in the next month, fill in the data, and send a notification. We are now developing this direction.

    - At our Mobius conference, we see that in the mobile world there is a lot of talk about architecture. What do you associate it with, and what do you have now?

    Ilya: It seems to me that mobile projects and startups that have survived and become successful have now grown. They have a lot of legacy and a lot of developers. Therefore, at some point it became clear to everyone that at MVC we would no longer survive. Something is going wrong. We cannot support this. Something needs to be redone. And therefore more and more often it began to flicker.

    We have a similar story. Of course, when we got a lot of legacy and a lot of developers on the project, we can no longer write in MVC, because we will be doing an elementary feature for a month. Of course, they started thinking about tests, about reusability, about how to make it all readable and supported.

    We went a long way when we first had MVC and two people, then we became three, and we came to MVVM. And they seemed to live well until ten. And after that, we realized that everyone sees MVVM in their own way, and began to argue over who is doing it. They understood that something else had to be done, but there really weren’t so many options on the market. And when they listened to reports on architecture on Mobius, it always sounded "not the fact that you need exactly this or that, think what you need and do something specifically for yourself, based on these requirements."

    We did just that. They took MVVM, took VIPER, found an article on Clean Swift, thought: "Also an interesting topic, let's try." They sat down and in a week wrote the same module on different architectures. Then they sat down and discussed together: look, we have a piece on MVVM. What do we like and dislike about him? Is there a piece on VIPER, what's in it? It was the same code, the same functionality.

    We decided that in our case it would be good to take Clean Architecture and adapt it for ourselves, but in the end we did what we called “Yet another architecture”. And he seems to be coming in well. Of course, we immediately went to tellabout him at the meeting, because hype, another architecture, all of them are "ohh, but VIPER will kill or not." About the "kill", of course, let's see, we did not set ourselves such a goal. Just offered an alternative.

    Anton: Yes, my opinion is similar. Android was introduced in 2008. Small applications began to be created. A sharp increase in development - probably the 2010th. And slowly, teams, applications, mobile-only trends began to grow. When a team grows to 5 people, it is necessary to introduce standards so that the application does not fall apart, it can be maintained and effectively developed.

    Google, it seems to me, was not a mistake, but a flaw: they did not pay attention to the lack of a pronounced architecture. There were all sorts of tools, IDE, SDK, but there was no architecture.

    In 2010, Google I / O Google employee Vergil Dobrzanski described three patterns, three approaches to the development of android applications. When for the first time in my life I was entrusted with development from scratch, I tried it this way, otherwise, something doesn’t work, you need to think about how to organize it. He began to google about architecture - then it was one, three approaches from Dobzhansky. Started to apply. Everything was fine, but it turned out to be a huge flap of code, a huge number of classes that very verbose solve some very small problem. Apparently, this was not the only problem I encountered, and smart people began to try to improve it, look at analogues: how it is developed in large Java in enterprise, how iOS does it with VIPER.

    Now the teams are becoming larger, so they take standard approaches or come up with something of their own. And the larger the team, the more rigorous architecture is needed. I liked the phrase from the last meeting of Alfa-Bank “Code must be anonymized”.

    Ilya: Reuse is also important. This is due to the fact that the business says “faster, faster, faster”, competition is growing and many companies are going to mobile development. If you don’t have a mobile application right now, this is strange. It needs to be fast and supported, and this leads to appropriate standards.

    - Our questions are over, do you want to add something else from yourself about mobile development in Alpha?

    Ilya:I want to talk a little about the team. We are completely independent. We configure CI ourselves, we can raise any server ourselves, connect Grafana and much more. We do not need five more teams of DevOps engineers to configure something. The maximum that we need from others is to get access, but this is quite formalized: sent a letter - issued access.

    Developers learn a lot. And architecture, and how you generally need to write code, if it's junior developers, and how to work as a team, take responsibility, and cut some extra stuff. We just got one android developer and redid the half-CI ...

    Anton: “With us” or “with you”?

    Ilya: Well ... in any case, these are mobile developers who can do CI! That's cool. Not everywhere like that.

    Anton: I’ll tell you a little differently. When an Android developer comes for an interview, I always ask him: “But will you be interested to work with us? What tasks do you want to solve? ”

    Someone says:“ I want to feature grocery features so I can log into the application and immediately see the result of my work. ” Someone says: "I want to cut something root, in C, under Android, so that everything is super optimal." And here we have to disappoint the second ones, that we have practically no such tasks. You are sent a sample JSON, which should come, you insert it in the right place, write tests, do the rest. Much depends on layout, sometimes complicated, sometimes simple. But all this on average takes a little time, and some non-trivial task rarely comes across.

    The most interesting and complex tasks we have now in another area - in the field of scaling. We have a growing number of mobile developers. And here's how to get 20 people to work so that the code does not degrade, is supported, the number of bugs does not increase, the development speed does not decrease? And a lot is being done for this.

    Suppose by CI. Previously, we had one Mac Pro, on which assemblies were made. After a while, we began to miss him. On Friday, everyone finishes sprints, a huge number of assemblies starts, and your assembly can stand in line for an hour, or even more. Therefore, we decided by the Android team to transfer all the assemblies to the servers in the cloud services. And to do this, wrap the infrastructure in a Docker container. And use the Jenkins pipelines. In the Android world, DevOps isn’t a lot of time. But we really need it, and a lot of energy was thrown there.

    There are also a lot of testing tasks. We have the principle "everyone covers his own code with tests." But there are people who work with tests a little deeper. They are engaged in the study and integration of new frameworks: Spock, Spek, Espresso. They automate the launch of tests and verification of code coverage by tests. In a word, they do everything so that others can write tests efficiently.

    We pay no less attention to architecture, we develop a library of visual components. What does such a library give us? The designer gives us not a completely finished layout, which is honed to a pixel, but simply a mockup of the screen - here is a blue button, here is a big title, here is the middle title, there is a yellow asterisk. Indentation is described in the component library, colors, fonts and all that. That is, the work of the designer is reduced, the work of the developer is reduced, the debugging time, the design review is also very much reduced, stupid errors in half a pixel can not be in principle.

    “Thank you both for the answers!”



    We are launching a new Mobius soon , and Alfa-Bank has become its sponsor. And this means that if you still have questions about mobile development in this company, then at the conference there will be someone to ask them!

    Also popular now: