In this talk, we’ll show you our development process at Infinum. We'll talk about Continuous integration, MVP, Git flow, static code analysis, Unit tests, multi-environment support and a few more.

1. Developing Android apps
like Navy Seals
Ivan Kušt, Android team leader

2. Infinum Android team

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

10. Implementation
process

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

39. Static code checks

40. Findbugs
• http://findbugs.sourceforge.net/
• java.net.URL.hashCode()

41. Android Lint
• android related checks
• missing translations
• unused drawables

42. Checkstyle

43. Releasing
and analytics

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: