Useful tools in Android Studio
It has been quite a lot of time since the presentation of Android Studio, and probably many have accumulated a lot of knowledge, nuances and chips, often used in work. This is what I want to share. I will begin, and you will continue ...
- SSD
- Filling the layout with test data
- Version autoincrement and build name change
- Creating various build options
- Pipette
- View code block history
')
SSD
Gradle collector collects a long time. If on a simple project the build time takes up to 10 seconds, then on a big one, with a lot of modules, up to two minutes. Taking into account the fact that during the day of the project, the project is collected dozens of times a day, a large leak of time comes out and irritability appears (the computer sometimes goes to ANR, even the browser cannot be used). The problem is solved simply by
The results of my SSD testing:
1. ANR Windows are gone
2. The build time of complex projects decreased from a maximum of two minutes to a maximum of 20 seconds.
3. Purchase SSD allows you to safely use the genymotion in conjunction with the studio.
Comparison of HDD (top) and SSD (bottom) speeds connected via SATA 1:
Filling the layout with test data
The “tools:” prefix, in addition to the Lint functions, allows you to fill the layout with test data without consequences for the application.
Even such things are possible:
android:visibility="gone” tools:visibility="visible” More details here - tools.android.com/tips/layout-designtime-attributes .
You can learn more about the use of the "tools:" prefix here - tools.android.com/tech-docs/tools-attributes .
Version autoincrement and build name change
Hradl fully automates the build and allows you to build various builds with one click. Below is the code from build.gradle, which allows you not to forget to raise the version of the application and renames the build based on the version and date - appname-release_v50_2014-11-04
Example:
Then it remains to run the release command of the main module of the project.
import java.util.regex.Pattern android { buildTypes { debug { applicationIdSuffix '.debug' debuggable true runProguard false jniDebugBuild false } release { signingConfig signingConfigs.release applicationVariants. { variant -> def file = variant.outputFile; def newName = file.name.replace("release.apk", "release_v" + getVersionCode() + "_" + getDate() + ".apk"); variant.outputFile = new File(file.parent, newName) } runProguard true proguardFile file("proguard.pro") debuggable false jniDebugBuild false } } } def getDate() { def date = new Date() def formattedDate = date.format('yyyy-MM-dd') return formattedDate } def getVersionCode() { println "getVersionCode" def manifestFile = file("AndroidManifest.xml") def pattern = Pattern.compile("versionCode=\"(\\d+)\"") def manifestText = manifestFile.getText() def matcher = pattern.matcher(manifestText) matcher.find() def version = ++Integer.parseInt(matcher.group(1)) println sprintf("Returning version %d", version) return version } task incrementVersionCode << { println(":incrementVersionCode - Incrementing Version Code...") def manifestFile = file("src/main/AndroidManifest.xml") def patternVersionCode = Pattern.compile("versionCode=\"(\\d+)\"") def manifestText = manifestFile.getText() def matcherVersionCode = patternVersionCode.matcher(manifestText) matcherVersionCode.find() def mVersionCode = Integer.parseInt(matcherVersionCode.group(1)) def mNextVersionCode = mVersionCode + 1 def manifestContent = matcherVersionCode.replaceAll("versionCode=\"" + mNextVersionCode + "\"") println(":incrementVersionCode - current versionCode=" + mVersionCode); println(":incrementVersionCode - next versionCode=" + mNextVersionCode); manifestFile.write(manifestContent) } task incrementVersionName << { println(":incrementVersionName - Incrementing Version Name...") def manifestFile = file("src/main/AndroidManifest.xml") def patternVersionNumber = Pattern.compile("versionName=\"(\\d+)\\.(\\d+)\"") def manifestText = manifestFile.getText() def matcherVersionNumber = patternVersionNumber.matcher(manifestText) matcherVersionNumber.find() def majorVersion = Integer.parseInt(matcherVersionNumber.group(1)) def minorVersion = Integer.parseInt(matcherVersionNumber.group(2)) def mVersionName = majorVersion + "." + minorVersion def mNextVersionName = majorVersion + "." + (minorVersion + 1) def manifestContent = matcherVersionNumber.replaceAll("versionName=\"" + mNextVersionName + "\"") println(":incrementVersionName - current versionName=" + mVersionName); println(":incrementVersionName - new versionName=" + mNextVersionName); manifestFile.write(manifestContent) } task release << { println(":release - Build and Version Increment") } task debug << { println(":debug - Build") } incrementVersionName.mustRunAfter build incrementVersionCode.mustRunAfter build debug.dependsOn assembleDebug release.dependsOn assembleRelease release.dependsOn incrementVersionCode release.dependsOn incrementVersionName Then it remains to run the release command of the main module of the project.
Creating various build options
I think one of the easiest and most popular options for using this feature is to create a free and paid version of an application or a version for a release and test server.
Below is an example on this topic.
Example:
Specify the build options - free and paid, and the corresponding parameters in build.gradle
In the case of a release and test server:
Then create folders in src with the appropriate names. The result is the following project structure:
In resources we specify the different data. For example, various keys for google analytics, crittercism, google backup service, etc.
In the code, we make checks on BuildConfig.PAID to implement the logic.
productFlavors { free { packageName "by.yegorov.communal" buildConfigField "boolean", "PAID", "false" } paid { packageName "yo.mobile.meters" buildConfigField "boolean", "PAID", "true" } } In the case of a release and test server:
productFlavors { debugServer { buildConfigField "String", "SERVER_PATH", "\"http://test.api.ru\"" } releaseServer { buildConfigField "String", "SERVER_PATH", "\"http://api.ru\"" } } Then create folders in src with the appropriate names. The result is the following project structure:
In resources we specify the different data. For example, various keys for google analytics, crittercism, google backup service, etc.
In the code, we make checks on BuildConfig.PAID to implement the logic.
Pipette
Pipette allows you to find out the color code from any area on the screen. Many people simply do not notice it and use the paint to find out the color code from the image. Pay attention to the upper left corner. This heading is called from colors.xml when clicking on a color.
View code block history
Agree, the standard situation when working in a team. I do not know how long this solution exists and whether it is in the eclipse, but the thing is really useful:
Thanks to all! Waiting for your comments.
Source: https://habr.com/ru/post/239199/
All Articles