This would appear in the version control system. Here is what you should avoid:ĭon't do this. In your app's adle you will need to define the signingConfigs for the release build. Google also provides some helpful Gradle recipes, specific to Android. Just follow Gradle's documentation for more details. Instead of (shell, Python, Perl, etc) scripts, you can make tasks in Gradle. And also, from API 21, the multidex support library is not needed anymore.
It is worth mentioning that some material design features are only available on Android 5.0 (API level 21) and above. Remember that the statistics given are global statistics and may differ when targeting a specific regional/demographic market. MinSdkVersion: 21 We recommend to have a look at the Android version usage chart before defining the minimum API required. Follow Google's guide on Gradle for Android. Project structureĪlthough Gradle offers a large degree of flexibility in your project structure, unless you have a compelling reason to do otherwise, you should accept its default structure as this simplify your build scripts. This allows for consistent builds between tools and better support for continuous integration systems. It is important that your application's build process is defined by your Gradle files, rather than being reliant on IDE specific configurations.
Your default option should be Gradle using the Android Gradle plugin.
This can be bad when you need to upgrade (or reinstall) the IDE, as you may lose your SDK installation, forcing a long and tedious redownload.Īlso avoid putting the SDK in a system-level directory that might need root permissions, to avoid permissions issues.
Some distributions of IDEs include the SDK when installed, and may place it under the same directory as the IDE. Place your Android SDK somewhere in your home directory or some other application-independent location. Summary Use Gradle and its default project structure Put passwords and sensitive data in gradle.properties Use the Jackson library to parse JSON data Don't write your own HTTP client, use OkHttp libraries Avoid Guava and use only a few libraries due to the 65k method limit Sail carefully when choosing between Activities and Fragments Layout XMLs are code, organize them well Use styles to avoid duplicate attributes in layout XMLs Use multiple style files to avoid a single huge one Keep your colors.xml short and DRY, just define the palette Also keep dimens.xml DRY, define generic constants Do not make a deep hierarchy of ViewGroups Avoid client-side processing for WebViews, and beware of leaks Use JUnit for unit tests, Espresso for connected (UI) tests, and AssertJ-Android for easier assertions in your Android tests Always use ProGuard or DexGuard Use SharedPreferences for simple persistence, otherwise ContentProviders Use Stetho to debug your application Use Leak Canary to find memory leaks Use continuous integration
If you are interested in iOS or Windows Phone development, be sure to check also our iOS Good Practices and Windows App Development Best Practices documents. Lessons learned from Android developers in Futurice.
Avoid reinventing the wheel by following these guidelines.