It has been some time since the stable version of Android Studio 3.0 was released. Early on, I wrote an article encouraging everyone to try out the new version of the development tool: Analysis of New Features in Android Studio 3.0 and Compatibility with Old Projects.

To this day, I still see netizens discussing the so-called pitfalls brought by 3.0 in various groups. A considerable number of friends are unwilling to update, and some even revert to version 2.3 after trying it out for a while. Since that’s the case, let me write another article, mixed with my own process of dealing with issues in 3.0, to talk about the pitfalls encountered in regular development.

So what kind of errors can be considered pitfalls encountered during software development? For example, you write a piece of code, and then it throws an error during compilation, failing to run. You throw your keyboard on the ground and curse: “Garbage language, ruining my youth!”

Would you? Unless it’s that time of the month, I believe no one would do that. So why can’t we analyze the problems rationally when facing updates to IDE tools?

Many developers dislike reading update documents, especially the English version. Of course, the language barrier is indeed a reason. However, for such documents related to a multitude of development work, there are usually corresponding Chinese translations available online. It only takes less time than a game of Honor of Kings to read through.

After reading the update documents, you will find that most of the so-called compatibility issues and pitfalls brought by the new version are documented, including solutions for each problem.

Of course, there will occasionally be minor issues that the documentation cannot resolve. For instance, the issue I encountered with the CheckStyle-IDEA plugin not functioning.

This plugin being broken means that as long as there is one piece of code in the project that does not comply with the standards, this commit will not be able to submit to the Git central repository. The worst part is that with a large number of changes, I cannot visually identify where the non-compliant code is hiding.

Without detailed error logs from the plugin, search engines cannot solve such niche problems that have newly emerged. What should I do?

With the deadline for code submission looming, I had no choice but to use a jar package and command line to check files one by one. Then I attempted to contact the author of the CheckStyle-IDEA plugin on GitHub, submitting an issue to point out the problem, hoping for a response from the author.

As the saying goes, “Where there is a will, there is a way.” Most foreigners are indeed quite responsible and respond promptly. Due to the time difference between China and the West, we could only communicate once a day. Fortunately, after several rounds of communication, the author updated the plugin twice and finally helped me solve the problem.

The result is that I solved the problem, and the CheckStyle-IDEA plugin was further improved. I mention this example to illustrate that encountering problems is not scary. You must maintain the right mindset and actively seek various solutions. Don’t assume there is a pit right away and avoid it. Many times, what you consider a pit is just a path that others have already walked.

Here, I must also commend the seriousness with which foreigners treat their open-source projects. For compatibility issues like this, the author still pays attention and communicates multiple times with the problem submitter to troubleshoot the error, which is indeed commendable.

As of now, I have encountered no issues using AS 3.0. In other words, most of the so-called pitfalls that many people mention have been resolved. The functionality is practical, and the experience is smooth. I also recommend everyone to upgrade; the new UI is simply stunning.

Moreover, 3.0 also has a small but thoughtful change that I don’t know if you have noticed. That is, the singleLine property of the layout’s text control is no longer marked as deprecated by Lint!

The images show the comparison before and after 3.0. Those who have used it know that the singleLine property cannot be completely replaced by the maxLine property. Before version 3.0, it was marked as a deprecated property, which was difficult to understand.

Fortunately, it has finally been fixed now, which is definitely a surprise for a coder like me who has a compulsive need for perfection!

Trip to WuhanGoogle officially launched the Chinese version of Android development teaching videos, will you learn it!