Mobile Architecture - A Brief guide

Transcript

1. Android, Kotlin… what is next? (a brief guide to mobile architecture) Kotlin Lviv User Group 25/04/2019 Senior Android SE at Vakoms, Taras Teslyuk
2. Who am I? • Android Maintainer at PLLUG Community • Assistant at Lviv Polytechnic National University • Senior Android SE at Vakoms • 5 years experience in Android development Interested in Music, Travelling, Science fiction.
3. Agenda • No Architecture • MVC • MVP • Repository + DataSource • Use Cases • Clean Architecture • MVVM • DI • Metrics • Conclusions • What is Next?
4. No Architecture
5. No Architecture at all May cause several problems: • Hard to read • High maintenance costs • Difficulties with code testing and debug • Undetected errors and crashes • No guidelines (How to work in a team?)
6. Single Class (Activity) • Idea: ◦ Store all in a single class. • Pluses: ◦ Works great for small screens. • Minuses: ◦ Logic is highly coupled ◦ code looks like a mess • Do you keep app logic in a single class?
7. Choose Architecture Wisely
8. MVC (Passive View) • Idea: ◦ Stateless View, Controller manage View. • Pluses: ◦ Separation of business and presentation logic. ◦ Separation of data layer. • Minuses: ◦ Require 3 classes instead of 1. ◦ Strong connection between elements
9. Weather app as a sample • Android application which displays information about: ◦ current weather ◦ 24 hour weather ◦ 5 day weather • Get information from server. • Store information locally. • Allow to change city.
10. MVC (Weather Sample)
11. MVP
12. MVP • Idea: ◦ View is hidden from Presenter via Interface. ◦ Presenter is independent from View. • Pluses: ◦ High testability of presenter. ◦ Higher presenter reusability. ◦ Presenter can be used in common modules. • Minuses: ◦ Add and maintain Interface for View. ◦ Additional code with little logic behind.
13. MVP (Weather Sample)
14. Model (Repository + DataSource) • Idea: ◦ Separate Data sources. ◦ Hide data sources via Interface. ◦ Repository class manage data sources. • Pluses: ◦ Separation of different data. ◦ No direct link to model classes. • Minuses: ◦ Require 3 classes instead of 1 and 2 additional interfaces. ◦ Maintain interfaces and implementation. • When IRepository & IDataSource may be the same?
15. Model Transformation
16. MVP (Repository) (Weather Sample)
17. Use Case • Idea: ◦ Single Object responsibility to business rules • Pluses: ◦ Extract business logic into separate class. ◦ Use cases may be shared between several screens. • Minuses: ◦ Require additional class for any business rule.
18. Do you need Use Cases?
19. Use Case Transformation
20. Clean Architecture Image from: https://habr.com/ru/company/mobileup/blog/335382/
21. Clean Architecture • What is Entity? Image from: https://habr.com/ru/company/mobileup/blog/335382/
22. MVP (Clean like) (Weather Sample)
23. Architecture Overthinking
24. MVP vs MVVM
25. MVVM • Idea: ◦ Use Data binding to automates communication between the view and viewModel properties. • Pluses: ◦ Direct connection between properties and view representation. • Minuses: ◦ Rely on additional libraries.
26. Observer Pattern https://commons.wikimedia.org/wiki/File:Observer_w_update.svg Libraries for Android: • RxJava • LiveData • etc
27. MVVM (Data Binding) • The Data Binding Library is a support library that allows you to bind UI components in your layouts to data sources in your app using a declarative format rather than programmatically. • <TextView android:text="@{viewmodel.userName}" /> Sample from: https://developer.android.com/topic/libraries/data-binding
28. MVVM (Weather Sample)
29. Dependency Injection (Dagger 2) Dagger 2 provides following elements: • @Module and @Provides: ◦ - define classes and methods which provide dependencies • @Inject: request dependencies. ◦ Can be used on a constructor, a field, or a method • @Component: enable selected modules ◦ used for performing dependency injection • How many files required to integrate DI for weather sample?
30. Metrics • Let's compare different architectures and extensions by the next criterias: ◦ Class count ◦ Lines of code ◦ Layers count
31. Metrics Classes C Lines Interfaces I Lines Base classes B Lines total No Architecture 1 232 0 0 0 0 232 MVC 3 254 0 0 0 0 254 MVP 3 290 1 22 0 0 312 MVP Repository 5 342 2 30 0 0 372 MVP Clean like 9 389 2 30 1 23 442 MVVM Clean like 9 379 2 27 1 23 429
32. Metrics
33. Metrics
34. Metrics
35. Conclusions • Use any architecture • Think how to maintain your project • Think about tests implementation • Use Repository when you have several data sources • Implement Use cases wisely • Do you need Reactive components? • MVP OR MVVM -> Try to use MVVM for a new project -> MVP for an old project • Use Dependency Injection libraries
36. What is Next? • Fragments vs Activity • MVI • VIPER • Do you use MVI or VIPER? Share your thoughts.
37. Credits • MVC ◦ https://developer.apple.com/library/archive/documentation/General/Conceptual/DevPedia-Cocoa Core/MVC.html • MVC vs MVP vs MVVM ◦ https://academy.realm.io/posts/mvc-vs-mvp-vs-mvvm-vs-mvi-mobilization-moskala/ ◦ https://habr.com/ru/post/215605/ ◦ https://academy.realm.io/posts/eric-maxwell-mvc-mvp-and-mvvm-on-android/ ◦ https://medium.com/@ankit.sinhal/mvc-mvp-and-mvvm-design-pattern-6e169567bbad ◦ https://www.evenidontknow.com/diffrence-between-mvp-mvc-mvvm.html ◦ https://www.linkedin.com/pulse/understanding-difference-between-mvc-mvp-mvvm-design-rishab h-software ◦ https://habr.com/en/company/mobileup/blog/313538/ • Architecture ◦ https://blog.heliossolutions.in/mobile-app-architecture-vital-mobile-app-development/
38. Credits (2) • Clean Architecture ◦ https://proandroiddev.com/clean-architecture-data-flow-dependency-rule-615ffdd79e29 ◦ https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html ◦ https://fernandocejas.com/2014/09/03/architecting-android-the-clean-way/ ◦ https://www.toptal.com/android/android-apps-mvvm-with-clean-architecture
39. Thank you for attention! Any Questions? • Weather app Sample: https://github.com/TeslyukTaras/AndroidTutorial_Architecture • Email: taras.teslyuk@gmail.com