October 4, 2014 at 22:02Useful tools in Android Studio
Quite a lot of time has passed since the presentation of Android Studio, and for sure many have accumulated a lot of knowledge, nuances and chips, often used in work. I would like to share this. I'll start, and you continue ...
- SSD
- Filling layout with test data
- Auto-increment version and change build name
- Creating various build options
- Pipette
- View code block history
SSD
Gradle collector collects for a long time. If on a simple project, the assembly time takes up to 10 seconds, then on a large one, with many modules, up to two minutes. Taking into account the fact that a project is assembled dozens of times a day during a day of work, a big time leak comes out and irritability appears (the computer sometimes goes into ANR, it’s even impossible to use a browser). The problem is solved simply by
The results of my testing of SSDs:
1. ANR Windows disappeared
2. The assembly time of complex projects decreased from a maximum of two minutes to a maximum of 20 seconds.
3. Buying an SSD allows you to painlessly use genymotion in conjunction with the studio.
Comparison of the speeds of HDD (top) and SSD (bottom) connected via SATA 1:
Filling layout with test data
The prefix “tools:” in addition to the Lint functions allows filling 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 familiarize yourself with additional features for using the “tools:” prefix here - tools.android.com/tech-docs/tools-attributes .
Auto-increment version and change build name
Gradle fully automates the assembly and allows you to collect various builds with one click. Below is the code from build.gradle, which allows you to remember 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 simplest and most popular options for using this feature is to create a free and paid version of the application or version for the 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 we create folders in src with the corresponding names. The following project structure will be obtained:
In the resources we indicate the differing data. For example, various keys for google analytics, crittercism, google backup service, etc.
In the code we do 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 we create folders in src with the corresponding names. The following project structure will be obtained:
In the resources we indicate the differing data. For example, various keys for google analytics, crittercism, google backup service, etc.
In the code we do checks on BuildConfig.PAID to implement the logic.
Pipette
The eyedropper allows you to find out the color code from any area on the screen. Many simply do not notice it and use paint in order to find out the color code from the picture. Pay attention to the upper left corner. This dialog box is called from colors.xml when clicking on a color.
View code block history
Agree, the standard situation when working in a team. I don’t 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.
Only registered users can participate in the survey. Please come in.
Your attitude to Android Studio:
- 14.1% Not tried 15
- 1.8% Tried, returned to Eclipse 2
- 83.9% Tried and stayed 89