Infinum Android Talks #13 - Developing Android Apps Like Navy Seals by Ivan Kušt
3 likes•680 views
This document outlines the development process of Android applications at Infinum, highlighting the challenges faced and the improvements made in implementation, testing, and release processes. It discusses the adoption of the MVP architecture, dependency injection, and various testing frameworks, emphasizing the importance of continuous integration and code quality checks. Additionally, it notes the establishment of internal analytics and app store solutions to enhance the overall development workflow.
Infinum Android Talks #13 - Developing Android Apps Like Navy Seals by Ivan Kušt
- 1. Developing Android apps like Navy Seals Ivan Kušt, Android team leader
- 3. How it all began?
- 4. How it all began
- 6. First steps • Android plugin for Eclipse • tests? who needs them • Activities with > 1k lines
- 7. First steps • no segregation of duties • no code review • poor code structure
- 8. Aint nobody got time for that Regression testing?
- 9. So what did we do? • Improved implementation process • Included testing to development process • Improved release process and analytics
- 11. Working in a team • git conflicts • different code styles • environment switching (test, production)
- 12. Working in a team • bugfixing while developing a new feature • weekly meetings and progress reports
- 14. branching / merging process
- 15. Pull Requests
- 16. debug staging release obfuscated no yes yes logs yes yes no crash reporting no yes in most cases Build types
- 17. Gradle • Build types - debug, staging, release • Product flavors - test API server, production API server
- 18. Product flavors • number of flavours = number of API environments
- 19. Build variants • flavor x buildType • example productionDebug • production API • debuggable, unobfuscated, logs enabled
- 20. Model Presenter View Code architecture
- 21. MVP • a derivative from MVC • Models and Views never communicate directly Model Presenter View
- 22. View • Activity, Fragment, View • propagates UI events to presenter • exposes methods that control presentation of data Model Presenter View
- 23. Presenter • middle man between View and Model • updates the UI - difference to MVC Presenter ViewModel Presenter • Activity, Fragment, View • propagates UI events to presenter • exposes methods that control presentation of data View
- 24. View Model • gateway towards the business logic • methods for data retrieval Model Presenter
- 25. Example showLoading() hideLoading() setUsernameError() setPasswordError() LoginPresenter login(username, pass) LoginView LoginModel login(username, pass, listener) showLoading() hideLoading() setUsernameError() setPasswordError() LoginActivity loginPresenter login(username, pass) LoginPresenterImpl loginView loginModel LoginModelImpl login(username, pass, listener)
- 26. Testing
- 27. Instrument testing • Robotium, Espresso • runs on emulator or real device
- 28. Unit testing • Robolectric • write mock View and Interactor • unit test Presenter
- 29. Dependency injection • Dagger 2 • https://github.com/reisub/Dagger-2-Example • simplifies writing tests • Model / View / Presenter can easily be replaced
- 30. Without DI @Override protected void onCreate(Bundle savedInstanceState) { //... //dependencies loginPresenter = new LoginPresenterImpl(this, new LoginModelImpl()); } LoginView LoginPresenter LoginModel LoginActivity LoginPresenterImpl LoginModelImpl
- 31. With DI @Override protected void onCreate(Bundle savedInstanceState) { //... //dependencies DaggerLoginComponent.builder() .loginModule(new LoginModule(this)) .build() .inject(this); }
- 32. With DI • decoupling dependencies from implementation • easier to replace dependencies • more about Dagger: http://google.github.io/dagger/
- 33. Robolectric • mock Android VM (tests run on desktop machine) • View doesn’t have to be mocked • full control of Activity / Fragment lifecycle • http://robolectric.org/
- 34. MockWebServer • part of OkHttp library • server that runs on localhost • responses can be enqueued • https://github.com/square/okhttp/tree/master/ mockwebserver
- 35. Mocking network layer • network layer can be replaced with MockWebServer • no additional mock classes
- 36. Continuous integration • if not forced, you won’t run tests
- 37. Idea • commit to a branch starts test execution • CI server clones the repo, compiles and runs tests • test results are archived and notified via mail / chat
- 38. CI servers • Jenkins • Travis • Circle CI • https://circleci.com/ • works only with GitHub
- 41. Android Lint • android related checks • missing translations • unused drawables
- 42. Checkstyle
- 44. Infinum Labs
- 45. Infinum Labs • internal app store • gradle task increments version name • upload app via web, CLI tool or AS plugin • library that notifies when new version is available
- 47. Analytics
- 48. Recap • Improved implementation process • Included testing to development process • Improved release process and analytics
- 49. Implementation process • organise teamwork - git flow • monitor code quality - pull requests • one click build - build variants • code structuring - MVP
- 50. Testing • Unit testing • Continuous integration • Static code checks
- 51. Releasing and analytics • internal store for clients • automatic notification when new version is up • analytics / crashlytics
- 52. • initial project setup takes more time • steeper learning and onboarding curve • developing new features initially takes more time to cover the code with unit test Cons
- 53. • confidence in builds (so much that we believe we’re Navy Seals) • more maintainable code • regression testing Pros
- 54. Implementation Testing Release Post Release Architecture Build Types MVP Dependency injection Unit Tests Robolectric MockWebServer Manual tests Human tester Infinum Notifier lib Analytics Google analytics Crashlytics Play Store
- 55. Ivan Kušt ivan@infinum.co • if you have any questions: