This is the app that follows all principles of Android Development Culture described here.
What does it have:
- CI (Travis)
- Unit tests (some under Robolectric, some are under plain JUnit runner with mocked
android.jar). - Integration tests to see that Http, REST, JSON parsing and RxJava work well in composition.
- Functional (UI) tests (Espresso with custom rules, mocked server and Screen-architecture) to check that app works according to the expectations from the user's point of view.
- Static code analysis (FindBugs, PMD, Android Lint, Checkstyle) (see root
build.gradle). - Code coverage (currently in process of fighting with jacoco-coverage plugin to fail the build if coverage is not big enough).
- Developer Settings Menu where you can enable/disable Stetho, LeakCanary, etc. See full list below (feel free to add more tools!).
- MVP, RxJava, Dagger 2, Retrofit 2 and so on.
Made with ❤️ by Artem Zinnatullin https://twitter.com/artem_zin.
To build the project run sh ci.sh (yep, that easy, because it should be easy).
Screenshots:
###Developer Settings
Tools:
- Stetho — inspect the app via Chromium Developer Tools (network requests, db, preferences and so on). Must have for developers.
- LeakCanary — detect memory leaks without IDE! Must have for QAs and developers.
- TinyDancer — see frame rate right on your screen. Must have for QAs and developers.
Details of implementation
Developer Settings presented only in debug build type, libraries and resources used for Developer Settings compiled only into debug build and main source set knows only little abstractions over Developer Settings just to initialize real implementation in the debug build code. In release build type DeveloperSettingsModule (Dagger) just returns no-op implementation of DeveloperSettingsModel.
Why only debug builds?
The Answer is simple — dex limit. LeakCanary brings about 3k of methods, Stetho brings about 2k and so on. The more tools you add to Developer Settings — the bigger apk you receive. Situation is even worse if your main code is near to 65k methods. In our production app we had to turn on multidex for debug builds.
###Packages structure
Many people ask why app has component-based structure of the packages: presenters, models, etc. instead of feature-based structure: itemslist, developersettings, etc.
With component-based structure of packages new persons on the project (like those who read the code of this app) can easily find what presenters does the app have, what views, models and so on. If you read the code and you want to quickly move to some class related to current one you can simply press t right on the GitHub and search for the required file!