Aspects of a successful mobile application architecture
Very often, when starting to develop an application, we, under the pressure of a manager, take one of the most common development patterns and quickly code to get a living prototype in a day or two. It seems everything works, goes to the prod, and everyone is happy.
Only then, when there is a question about support, refactoring and the introduction of new features, it turns out that in the controllers we have tons of code, the number of boilerplate is covered with 4k screen, and inserting new chips is more difficult than rewriting everything again. And here you are again sawing everything in the style of * yak- * yak and in production ...
But maybe it was worth taking the time and choosing not just a fashionable architecture, but an architecture suitable for your task?
')
Under the cat answers to common questions and some tips to help create a quality product.
Meet
Yevgeny Matsyuk . Leading developer of Kaspersky Lab. He has extensive experience in introducing new approaches and tools.
Alexander Blinov . In REDMADROBOT, he is engaged in Android architecture, team engineering issues and application development directly.
Anton Rutkevich . Working in Yandex, I developed applications, was engaged in non-trivial cases of their assembly and continuous integration processes. Now in Juno he is developing Android applications on Kotlin.
- How does successful architecture differ from unsuccessful?
Evgeny Matsyuk: Successful architecture gives developers a chance to never conduct a global refactoring of the entire application. Maximum - to isolate in isolation some modules without a long fix of the appeared bugs.
In fact, it is worth a lot, as you can continuously “wash down new features” without slowing down the pace. The application will grow, the feature set will increase, and you will still have a sense of joy from the fact that "everything, damn it, is logical and simple."
Alexander Blinov: Architectural errors are very insidious. For the first few months of development, they hide behind your back and sometimes remind themselves of crutches and suspicious code. As the code base grows, they begin to figure more and more, increasing the entropy of your code. Over time, the introduction of new features brings changes in the most unexpected places of the program. Such situations adversely affect the team spirit and significantly hit the business.
- What, in your opinion, the optimal composition of the team to develop an application? How many designers can be engaged in the development of architecture? How to build their interaction to achieve maximum effect?
Evgeny Matsyuk: If we are talking about developing an application for a specific platform, then usually it all comes down to the following scheme. The team - 3-5 developers of different levels and timlid, on which hang the tasks of planning and interaction with the outside world. Directly architectural tasks can deal with the team, as well as, for example, the most powerful developer of the team. That is, the architecture is responsible for one, maximum two people. All key decisions on the project - only through them. No one, of course, cancels the holivars within the team, but someone must always bear the responsibility.
Alexander Blinov: Teams with a larger number should be divided into departments working on different parts of the application. The division into parts can be both horizontal and vertical. The order of interaction between application logical units must be determined by the architect. His responsibility also includes general system design. Compliance with these practices is monitored by the lead of each department.
Anton Rutkevich: In my opinion, this is a balanced team, where there are people with different roles. Of course, everyone should have a good understanding of language, platform, architecture, but excellent teams are obtained when everyone has some favorite area in the development in which he understands especially well, “specialization” of something, and these specializations do not have much overlap in the team (although some, of course, they have). Specializations can be, for example, high-level architecture, working with UI or other platform frameworks, CI, testing, design. This does not mean that only “specialists” are engaged in these areas, but usually they are the ones who move forward, bring improved approaches, develop their areas. Therefore, the more areas covered, the greater will be order in large aspects of the project. If the whole team is a fan of architecture and does not like to dig into the UI framework, there is a big chance to have frequent architectural holivars and layers of the “UI” made.
It is also very important that there be one, and preferably several people who are engaged in integration with the outside world. And this, too, should like them. To coordinate the API with neighboring teams, to check the business requirements from a technical point of view, to conduct any correspondence, which inevitably arise.
And further. If the team does not have a person without whom the development will arise, then it is very easy to go on vacation, take a day-off if necessary. You have no idea how pleasant it is to work in a team, where you always know that colleagues will pick up your tasks if necessary, and this will not be a problem.
- How much time should be allocated to the planning and architecture of the application in comparison with the other stages of development?
Alexander Blinov: The main thing is not to forget to single out it at all. Often, managers push the team to release the first release as early as possible in order to earn customer / stakeholder loyalty, and promise a subsequent redesign. But as you call a boat, so it will float: an application in which the architecture is not thought out, slows down the development and subsequently causes great damage to the company.
It is important to consider a flexible architecture common to the whole company, under the auspices of which all new applications will be launched. A unified approach to the code allows you to quickly launch new projects, as well as safely increase the composition or rotate the team.
Evgeny Matsyuk: It is also important to note that if you are developing prototypes, experimental applications, the amount of time spent on architecture should be zero. But in this case, you must inform the manager that this product is only a prototype and is not subject to expansion.
- Is it possible to explain the problems in the mobile application architecture with a low-quality server API? Or is it an independent thing?
Evgeny Matsyuk: The correct architecture will be able to encapsulate poor-quality server APIs.
In my practice there was such a case. I was involved in the implementation of the chat module in the banking application. Work chat was carried out through a third-party service. I implemented the module on the concept of "Pure Architecture", covering all the unit tests. Made and forgotten.
And in nine months the introductory arrives, that we have nothing to use for the Basurman services, we will use our own, relatives. We received a new service with a completely different slightly damp API and a different concept. And you need to switch to this service right now. Yes, and it was also necessary to support the work of the previous service, so that in case of which we could switch the chat to it.
And then I experienced that invaluable feeling when the architecture laid down “just drags”. This is an invaluable moment. I wish everyone to experience this. Steeper than the first kiss.
At the Repository level, the substitution did not work out, as the concept of the new service is just different. Therefore, the substitution was carried out at the level of the Interactor. Yes, I had to implement a new repository and a new implementation of Interactor. But I did not touch the view and the presenter at all, but there was also a lot of code there. The substitution of chat services was easily carried out through the Daguer module (they simply substituted the necessary implementation of the Interactor).
I implemented the repository and interactor via TDD. To implement complex business logic, TDD is very good, by the way. Actually, I launched the application for verification at the very end, when everything was ready to just make sure that everything works. No additional bugs and other things appeared. All evil is encapsulated. Well, great?
- How do you feel about the TDD methodology? What development approach do you use most often and why?
Anton Rutkevich: TDD is an excellent methodology. If you follow it, the problem of covering the code with tests disappears as a class, since There is no code without tests.
On the other hand, when solving a voluminous task that requires writing a large amount of new code, it can be difficult to sketch out the correct architecture from the first time and, especially, to think out exactly the interaction API between the modules. In such cases, again, in my opinion, the TDD approach unnecessarily increases the development time, since before rewriting the code, you need to rewrite the tests as well.
Therefore, we use TDD mainly when we need to expand the existing functionality and the interfaces are less clear.
- When is the transfer of execution logic from the application to the server justified?
Alexander Blinov: The mobile application is a thin client and is not intended to perform serious logic. If the customer is not ready to provide the mobile client with an API corresponding to this approach, we build in the client-server middleware interaction chain. Middleware is our proxy backend, which assumes integration with complex customer services and bringing the API for the client application to a convenient form. As a rule, it speeds up development, since complex logic is written once in the middle and not twice: on Android and iOS. In some cases, integration into the chain of middleware is not possible, for example, mobile banks have increased security requirements and want to minimize the surface of a possible attack. In these cases, we integrate our middleware into the customer's server.
- What is the place of MVP, MVC and MVVM in the architecture of mobile applications?
Evgeny Matsyuk: The term MVC sounds already somehow not fashionable among android developers. Immediately, the associative series with the Activity, which used to be considered the Controller, reached an unreal size and complexity, triggered. Remember? Shuddered from horror? Do not say this abbreviation out loud again, otherwise you will be anathematized.
MVP, MVVM is more about the Presentation layer. Moreover, MVVM is gaining popularity lately, but implemented not through DataBinding, but "hands" through RxJava. The result is less boilerplate code than with MVP. I am pleased to hear the report of Denis Neklyudov and Stepan Goncharov about this approach.
And “Clean architecture” is about the application as a whole.
- What are the features of the development of application architecture for android?
Yevgeny Matsyuk: A question about which you can talk forever. For me, the most important feature is that at first they did not even think about architecture as such. Google at one time provided the SDK and told the developers: "Good luck, guys." And the guys went, but not quite on the good path. As a result, a large number of applications appeared that have to be maintained and reworked. But we are never bored.
Alexander Blinov: Android developers have made many rather strange decisions, such as: the life cycle, the way of providing permisens. In the first versions of the system, such solutions were dictated by the low power of iron. Currently, smartphones have become much more powerful, but we have become hostages of the slogan: “We wrote once - we always suffer!”. This spawns the creation of frameworks that encapsulate the fight against the system, such as ours with Senneco Moxy. I advise you to listen to the story of Jura on Mobius how Moxy works under the hood
- Is it possible not to write too much? Which core layers are required to be in an application with a good architecture, and which ones can be excluded in some cases?
Alexander Blinov : This is a rather holivarny question. The five logical layers that we distinguish in the "Pure Architecture" have their own specific area of ​​responsibility. We adhere to consistency in architecture and, even if there is no need for a logical layer, it will act as a proxy. This makes the code predictable and easily extensible.
- What technology stack is usually used to design an Android application?
Evgeny Matsyuk: In my last speech, I talked about the next stack: RxJava, Dagger, Unit tests. Now would add Moxy - for handling the life cycle, Cicerone - for navigation. In general, you can still start writing on Kotlin.
Alexander Blinov: REDMADROBOT has a similar technology stack. Kotlin has been in production for over a year. All new code is written only on Kotlin.
- What would be the main advice you would give to developers in terms of building architecture?
Anton Rutkevich : I would say that you need to remember about SOLID and consciously apply the approach of Clean Architecture. This does not mean that one should paranoidly follow it everywhere, but a departure from Clean Architecture in some places must always be a conscious and balanced decision.
Evgeny Matsyuk: Think. Try it. And think again. And try again.
Obligatory study the basic design patterns and get into, why and in what situations they are really needed.
Creating a successful architecture is the most difficult and responsible task. But here the saying is really pertinent - “patience and work - everything will change.”
Alexander Blinov: Do not forget to devote time to architecture. Feel free to lay it in the evaluation of the project and inform managers that the lack of a properly built architecture will subsequently hurt the business.
- What are you going to talk about on Mobius?
Yevgeny Matsyuk: We want to dive into the “Clean Architecture”. Consider the main questions asked by developers, consider the cases that are often found in our lives, and show how to solve them in the "Pure Architecture".
Unfortunately, we only have 50 minutes, and we will not tell even a small fraction of what we have accumulated interesting. But we are working on a document (it will be either a series of articles, or a CookBook), in which we will try to reveal the "Pure Architecture" from basic theoretical points to the most sophisticated practical situations. Therefore, we will be glad to any help, any advice, any interesting task. Since January, we have launched a chat in Telegram dedicated to architecture in Android. We are already more than 500 people. Join and ask your questions!
Anton Rutkevich: On Mobius I will talk about how to consciously write code so that after writing it is guaranteed to be covered with tests. Despite the fact that the report will have examples on Kotlin (so that the code fits into the slide) and Android, the focus will be on ideas that lie outside platforms and languages, and on the practical ability to apply them in any context. Therefore, I invite everyone.
Alexander Blinov: Many technologies work fine on Helloword, but when faced with real code, they fail. In our report we will analyze the most complex cases on which the "Clean Architecture" has proved its worth!
Therefore, I would like to invite everyone to our report with Eugene in the framework of Mobius 2017 . We promise to dive into the Pure Architecture and glorious holivar with fellow shop workers! We also wish each of you to leave the conference inspired, with burning eyes and cool ideas!
See you at the forum!
Only then, when there is a question about support, refactoring and the introduction of new features, it turns out that in the controllers we have tons of code, the number of boilerplate is covered with 4k screen, and inserting new chips is more difficult than rewriting everything again. And here you are again sawing everything in the style of * yak- * yak and in production ...
But maybe it was worth taking the time and choosing not just a fashionable architecture, but an architecture suitable for your task?
')
Under the cat answers to common questions and some tips to help create a quality product.
Meet
Yevgeny Matsyuk . Leading developer of Kaspersky Lab. He has extensive experience in introducing new approaches and tools. Alexander Blinov . In REDMADROBOT, he is engaged in Android architecture, team engineering issues and application development directly. Anton Rutkevich . Working in Yandex, I developed applications, was engaged in non-trivial cases of their assembly and continuous integration processes. Now in Juno he is developing Android applications on Kotlin.About architecture, planning and team
- How does successful architecture differ from unsuccessful?
Evgeny Matsyuk: Successful architecture gives developers a chance to never conduct a global refactoring of the entire application. Maximum - to isolate in isolation some modules without a long fix of the appeared bugs.
In fact, it is worth a lot, as you can continuously “wash down new features” without slowing down the pace. The application will grow, the feature set will increase, and you will still have a sense of joy from the fact that "everything, damn it, is logical and simple."
Alexander Blinov: Architectural errors are very insidious. For the first few months of development, they hide behind your back and sometimes remind themselves of crutches and suspicious code. As the code base grows, they begin to figure more and more, increasing the entropy of your code. Over time, the introduction of new features brings changes in the most unexpected places of the program. Such situations adversely affect the team spirit and significantly hit the business.
- What, in your opinion, the optimal composition of the team to develop an application? How many designers can be engaged in the development of architecture? How to build their interaction to achieve maximum effect?
Evgeny Matsyuk: If we are talking about developing an application for a specific platform, then usually it all comes down to the following scheme. The team - 3-5 developers of different levels and timlid, on which hang the tasks of planning and interaction with the outside world. Directly architectural tasks can deal with the team, as well as, for example, the most powerful developer of the team. That is, the architecture is responsible for one, maximum two people. All key decisions on the project - only through them. No one, of course, cancels the holivars within the team, but someone must always bear the responsibility.
Alexander Blinov: Teams with a larger number should be divided into departments working on different parts of the application. The division into parts can be both horizontal and vertical. The order of interaction between application logical units must be determined by the architect. His responsibility also includes general system design. Compliance with these practices is monitored by the lead of each department.
Anton Rutkevich: In my opinion, this is a balanced team, where there are people with different roles. Of course, everyone should have a good understanding of language, platform, architecture, but excellent teams are obtained when everyone has some favorite area in the development in which he understands especially well, “specialization” of something, and these specializations do not have much overlap in the team (although some, of course, they have). Specializations can be, for example, high-level architecture, working with UI or other platform frameworks, CI, testing, design. This does not mean that only “specialists” are engaged in these areas, but usually they are the ones who move forward, bring improved approaches, develop their areas. Therefore, the more areas covered, the greater will be order in large aspects of the project. If the whole team is a fan of architecture and does not like to dig into the UI framework, there is a big chance to have frequent architectural holivars and layers of the “UI” made.
It is also very important that there be one, and preferably several people who are engaged in integration with the outside world. And this, too, should like them. To coordinate the API with neighboring teams, to check the business requirements from a technical point of view, to conduct any correspondence, which inevitably arise.
And further. If the team does not have a person without whom the development will arise, then it is very easy to go on vacation, take a day-off if necessary. You have no idea how pleasant it is to work in a team, where you always know that colleagues will pick up your tasks if necessary, and this will not be a problem.
- How much time should be allocated to the planning and architecture of the application in comparison with the other stages of development?
Alexander Blinov: The main thing is not to forget to single out it at all. Often, managers push the team to release the first release as early as possible in order to earn customer / stakeholder loyalty, and promise a subsequent redesign. But as you call a boat, so it will float: an application in which the architecture is not thought out, slows down the development and subsequently causes great damage to the company.
It is important to consider a flexible architecture common to the whole company, under the auspices of which all new applications will be launched. A unified approach to the code allows you to quickly launch new projects, as well as safely increase the composition or rotate the team.
Evgeny Matsyuk: It is also important to note that if you are developing prototypes, experimental applications, the amount of time spent on architecture should be zero. But in this case, you must inform the manager that this product is only a prototype and is not subject to expansion.
Server role
- Is it possible to explain the problems in the mobile application architecture with a low-quality server API? Or is it an independent thing?
Evgeny Matsyuk: The correct architecture will be able to encapsulate poor-quality server APIs.
In my practice there was such a case. I was involved in the implementation of the chat module in the banking application. Work chat was carried out through a third-party service. I implemented the module on the concept of "Pure Architecture", covering all the unit tests. Made and forgotten.
And in nine months the introductory arrives, that we have nothing to use for the Basurman services, we will use our own, relatives. We received a new service with a completely different slightly damp API and a different concept. And you need to switch to this service right now. Yes, and it was also necessary to support the work of the previous service, so that in case of which we could switch the chat to it.
And then I experienced that invaluable feeling when the architecture laid down “just drags”. This is an invaluable moment. I wish everyone to experience this. Steeper than the first kiss.
At the Repository level, the substitution did not work out, as the concept of the new service is just different. Therefore, the substitution was carried out at the level of the Interactor. Yes, I had to implement a new repository and a new implementation of Interactor. But I did not touch the view and the presenter at all, but there was also a lot of code there. The substitution of chat services was easily carried out through the Daguer module (they simply substituted the necessary implementation of the Interactor).
I implemented the repository and interactor via TDD. To implement complex business logic, TDD is very good, by the way. Actually, I launched the application for verification at the very end, when everything was ready to just make sure that everything works. No additional bugs and other things appeared. All evil is encapsulated. Well, great?
- How do you feel about the TDD methodology? What development approach do you use most often and why?
Anton Rutkevich: TDD is an excellent methodology. If you follow it, the problem of covering the code with tests disappears as a class, since There is no code without tests.
On the other hand, when solving a voluminous task that requires writing a large amount of new code, it can be difficult to sketch out the correct architecture from the first time and, especially, to think out exactly the interaction API between the modules. In such cases, again, in my opinion, the TDD approach unnecessarily increases the development time, since before rewriting the code, you need to rewrite the tests as well.
Therefore, we use TDD mainly when we need to expand the existing functionality and the interfaces are less clear.
- When is the transfer of execution logic from the application to the server justified?
Alexander Blinov: The mobile application is a thin client and is not intended to perform serious logic. If the customer is not ready to provide the mobile client with an API corresponding to this approach, we build in the client-server middleware interaction chain. Middleware is our proxy backend, which assumes integration with complex customer services and bringing the API for the client application to a convenient form. As a rule, it speeds up development, since complex logic is written once in the middle and not twice: on Android and iOS. In some cases, integration into the chain of middleware is not possible, for example, mobile banks have increased security requirements and want to minimize the surface of a possible attack. In these cases, we integrate our middleware into the customer's server.
- What is the place of MVP, MVC and MVVM in the architecture of mobile applications?
Evgeny Matsyuk: The term MVC sounds already somehow not fashionable among android developers. Immediately, the associative series with the Activity, which used to be considered the Controller, reached an unreal size and complexity, triggered. Remember? Shuddered from horror? Do not say this abbreviation out loud again, otherwise you will be anathematized.
MVP, MVVM is more about the Presentation layer. Moreover, MVVM is gaining popularity lately, but implemented not through DataBinding, but "hands" through RxJava. The result is less boilerplate code than with MVP. I am pleased to hear the report of Denis Neklyudov and Stepan Goncharov about this approach.
And “Clean architecture” is about the application as a whole.
About the structure of Android applications
- What are the features of the development of application architecture for android?
Yevgeny Matsyuk: A question about which you can talk forever. For me, the most important feature is that at first they did not even think about architecture as such. Google at one time provided the SDK and told the developers: "Good luck, guys." And the guys went, but not quite on the good path. As a result, a large number of applications appeared that have to be maintained and reworked. But we are never bored.
Alexander Blinov: Android developers have made many rather strange decisions, such as: the life cycle, the way of providing permisens. In the first versions of the system, such solutions were dictated by the low power of iron. Currently, smartphones have become much more powerful, but we have become hostages of the slogan: “We wrote once - we always suffer!”. This spawns the creation of frameworks that encapsulate the fight against the system, such as ours with Senneco Moxy. I advise you to listen to the story of Jura on Mobius how Moxy works under the hood
- Is it possible not to write too much? Which core layers are required to be in an application with a good architecture, and which ones can be excluded in some cases?
Alexander Blinov : This is a rather holivarny question. The five logical layers that we distinguish in the "Pure Architecture" have their own specific area of ​​responsibility. We adhere to consistency in architecture and, even if there is no need for a logical layer, it will act as a proxy. This makes the code predictable and easily extensible.
- What technology stack is usually used to design an Android application?
Evgeny Matsyuk: In my last speech, I talked about the next stack: RxJava, Dagger, Unit tests. Now would add Moxy - for handling the life cycle, Cicerone - for navigation. In general, you can still start writing on Kotlin.
Alexander Blinov: REDMADROBOT has a similar technology stack. Kotlin has been in production for over a year. All new code is written only on Kotlin.
- What would be the main advice you would give to developers in terms of building architecture?
Anton Rutkevich : I would say that you need to remember about SOLID and consciously apply the approach of Clean Architecture. This does not mean that one should paranoidly follow it everywhere, but a departure from Clean Architecture in some places must always be a conscious and balanced decision.
Evgeny Matsyuk: Think. Try it. And think again. And try again.
Obligatory study the basic design patterns and get into, why and in what situations they are really needed.
Creating a successful architecture is the most difficult and responsible task. But here the saying is really pertinent - “patience and work - everything will change.”
Alexander Blinov: Do not forget to devote time to architecture. Feel free to lay it in the evaluation of the project and inform managers that the lack of a properly built architecture will subsequently hurt the business.
- What are you going to talk about on Mobius?
Yevgeny Matsyuk: We want to dive into the “Clean Architecture”. Consider the main questions asked by developers, consider the cases that are often found in our lives, and show how to solve them in the "Pure Architecture".
Unfortunately, we only have 50 minutes, and we will not tell even a small fraction of what we have accumulated interesting. But we are working on a document (it will be either a series of articles, or a CookBook), in which we will try to reveal the "Pure Architecture" from basic theoretical points to the most sophisticated practical situations. Therefore, we will be glad to any help, any advice, any interesting task. Since January, we have launched a chat in Telegram dedicated to architecture in Android. We are already more than 500 people. Join and ask your questions!
Anton Rutkevich: On Mobius I will talk about how to consciously write code so that after writing it is guaranteed to be covered with tests. Despite the fact that the report will have examples on Kotlin (so that the code fits into the slide) and Android, the focus will be on ideas that lie outside platforms and languages, and on the practical ability to apply them in any context. Therefore, I invite everyone.
Alexander Blinov: Many technologies work fine on Helloword, but when faced with real code, they fail. In our report we will analyze the most complex cases on which the "Clean Architecture" has proved its worth!
Therefore, I would like to invite everyone to our report with Eugene in the framework of Mobius 2017 . We promise to dive into the Pure Architecture and glorious holivar with fellow shop workers! We also wish each of you to leave the conference inspired, with burning eyes and cool ideas!
See you at the forum!
Source: https://habr.com/ru/post/326694/
All Articles