The effectiveness of your software development depends not only on your depth of knowledge and experience, but also on your development tools, environment configuration, and teamwork.
I recently did a share at Droidcon Berlin about an Android developer best practice from our Zalando Tech team. Here you can find some points from my talk that will make your development life more enjoyable and your application more stable.
What does your AndroidManifest file really look like
Most of us already know that the Androidmanifest.xml file we see in a text editor is not the same as the actual compiled content. This is mainly because there are extra < uses-Permission /> tags in the third party libraries you include in your project, which will be mixed with your own manifest file. (The Commons Blog for more details)
To examine your manifest before building APK, we can use Merged Manifest Viewer, a new feature available in Android Studio 2.2. AndroidManifest will show you how to combine your AndroidManifest with build types, flavors, and variants of your dependencies. You can navigate to the Androidmanifest.xml file by clicking the Merged Manifest TAB at the bottom to use this tool.
Support Annotations are your friend
Another tool that’s particularly useful is the Support Annotations Library. You can use in your build. Gradle file to add “com. Android. Support: support – annotations: 23.4.0” to include in your project. Use these metadata annotations to decorate your code to help you find bugs and define coding rules. The most common use scenario is to mark Nullable and non-Nullable, link resources, and specify from which thread they are called back.
Since these annotations are metadata annotations, your project will compile even if you violate the syntax rules it defines. However, it will be highlighted by Android Studio and Lint and will be visible to your team members in the output of your continuous integration tool.
3. Fast and painless code review
Assuming you want to do a code review, it makes sense to check how the development feature works, so you need to compile your project. There is a common workflow for this situation:
2.Checkout branch to review 3. Reload gradle configuration in your IDE 4. Read code 5 in your IDE. Compile start and test app 6. Repeat (1) – (5)
“Is there a problem here?” Can you ask. Yes, no problem except for the fact that your project has 1000+ different classes and configuration files and you’ll spend more than three minutes compiling your code with your powerful MacBook.
Our solution is to use a dedicated IDE instance and repository folder for code review. In this case your work will not stop for some time, and you can go back to your main IDE and branches at any time. Here’s a small disclaimer: We recommend that you use a machine with at least 16GB of RAM, and the time savings are well worth it.
4. Quick application and modification
Even if your project is small, you will often spend time compiling and deploying the latest changes to test machines and emulators. If you have hundreds of classes and XML files, each compilation and deployment can take a lot of time, even if you use a highly configured computer. In addition, you need to manually locate where the application changes, which also takes some time.
At the end of 2015, the Android community received two tools that allow code changes to be applied faster. The first is JRebel, which comes from the Java backend world and has been the industry standard for a long time. Another tool is Instant Run, released by Google in Android Studio 2.0. These tools have a common purpose, but JRebel has more features and requires an annual license fee.
The two tools alone can’t tell the difference, so we analyzed the differences through documentation and some blogs:
Source: developer.android.com/studio/run/… Reto Meier: “Instant Run: How Does it Work? !” Oleg Selajev: “Looking at JRebel for Android and Instant Run…”
Almost every week, both tools are being actively developed and improved. In our experience, you can already benefit from these tools, although many use cases are not covered yet.
Measure execution time
Another very useful feature is logging method input/output and execution time in application debugging and performance analysis. For these requirements, we use Hugo by Jake Wharton, a simple and elegant method annotation tool. You don’t need a tool as deep and sophisticated as Systrace if you just want to see log output.
All you need to do is label the target method, as shown below:
@DebugLog public String getName(String first, String last) {/* ... * /}Copy the codeFind the printed information for the corresponding method call in the log:
V/Example: --> getName(first="Jake", last="Wharton")
V/Example: Copy the code6. How to read log output from your device
For our daily needs, most of us use Android Studio’s built-in Monitor to read logs. It’s convenient to use in simple scenarios, but we noticed several trade-offs using this approach:
1. Logs are difficult to read and you should use external tools or format configurations.
2. The Android Studio logging tool is associated with the process ID of the application you are deploying. If you redeploy the application or kill the process, your previous logs will be lost because Android Studio is tied to the process ID.
To solve this problem we can use Jake Wharton — pidcat. Its main benefits are as follows:
1. Good color patterns and formats.
2. Connect to the debug application by package name, not process ID. All logs will be kept after the application is redeployed.
7. Network output log recording and analysis
The most common way to read your application’s network interaction log output is through an HTTP client. However, this approach has several trade-offs:
1. If you want to keep logs of all network requests during development, you will notice that application performance degrades and it takes some time to print the logs.
2. If your application has additional libraries that need to be networked (e.g., Google Analytics), you need to configure these additional libraries to allow all data to be logged.
Here’s another approach: Use HTTP monitoring software Charles Proxy. This type of tool provides the following functionality to wrap your application in a black box:
1. Monitor and record HTTP/HTTPS channels
2. Re-modify the boundary between the return value and the server response
3. Interrupt at the point of network callback
4. Install the SSL certificate on the device to read encrypted traffic
Update, another alternative network monitoring tool mentioned by Nahuel Barrios in the comments is Facebook Stetho. We still can’t read SSL-encrypted communications in Google Analytics through Stetho. If you know anything about this please contact me.
8. Be sure to test on different operating systems
What I’ve been doing and pushing my colleagues to do is testing every feature in Lollipop and higher (API 21+) versions. This way I can catch these bugs during testing.
You’ll find that common compatibility issues are touch feedback and system color inconsistencies, and we often see apps crash on older apis due to compatibility issues.
9. Automate screen interaction testing
We often need to check scenarios where we do repetitive UI clicks and inputs on different devices. It can be very annoying if you have three or four test devices, and you need a regression test plan to test through 30 scenarios.
The first step in automation is to enter ADB commands or scripts to avoid having to manually interact with the device every time. You can enter ADB commands using system keys, keyboard input, and on-screen touches.
But what do you do if you have three devices testing a scene? We can use adB-Ninja to test different devices at the same time.
10. Check your build.gradle configuration
Sometimes even experienced developers use outdated configuration practices. Let’s take a look at your build.gradle file and see if you’ve fallen foul of it:
1. Abandon mavenCentral and use JCenter as the dependency repository. Jcenter has faster response times and already integrates with mavenCental.
2. Check the version of the Android Plugin for Gradle. Keeping it up to date improves compilation performance and gives you handy features like Instant Run.
3. Do not specify the version range of the dependency library. Use a version constant like “23.4.0” to reduce network requests each time the dependency library is compiled.
4. Setting the build version minSdkVersion 21 or higher will speed up the build.
