The following is the first few sections of a chapter from The Busy Coder's Guide to Android Development, plus headings for the remaining major sections, to give you an idea about the content of the chapter.
As C/C++ developers are well aware,
lint is not merely something
that collects in pockets and belly buttons.
lint is a long-standing C/C++ utility that points out issues in a
code base that are not errors or warnings, but are still indicative of
a likely flaw in the code. After all, what might be legal from a syntax
standpoint may still be a bug when used.
Android Studio and the Android Plugin for Gradle have their own equivalent Lint tool, for reporting similar sorts of issues with an Android project’s Java code, resources, and manifest. You can also get Lint reports from the command line, such as via the Android Gradle Plugin, perhaps as part of integrating your builds into a continuous integration server.
To help Lint catch problems stemming from your own code, Google has
support-annotations library, to help catch things like
passing a widget ID, instead of a layout ID, into
You can also use these annotations to help those using your code –
whether in the same project or in consumers of a library that you publish –
make sure that they do not make similar mistakes.
This chapter will explore how you use Lint to detect problems and how you can add annotations to your code to help Lint catch even more problems.
Understanding this chapter requires that you have read the core chapters of this book.
Lint can be best described as “a pest, but a good pest”.
Normally, what stops you from building your app are compiler errors: bad Java syntax, malformed XML resource files, and the like. At the command line, these stop an in-progress build and dump error messages to the console. In Android Studio, these are noted in a log and also by notations in the source code, frequently as red sqiggle lines underneath the offending Java or XML when viewed in an editor. You also may get yellow squiggle lines for warnings — things the compiler will allow but the compiler thinks may be a problem.
However, there are many things that might be syntactically valid but are not a good
idea from an Android standpoint. For example, if you specify a minimum SDK version
of API Level 8, and you try using a class that only exists on API Level 11, that’s a
problem if you are not handling it correctly and avoiding this class on the
older-yet-supported devices. Yet, if your build target
compileSdkVersion in Android Studio) is API Level 11
or higher, it is perfectly valid syntax and would compile just fine.
Lint is designed to encapsulate rules that transcend syntax, to add more errors and warnings that reflect good Android practices beyond simple validity.
The preview of this section was lost in the sofa cushions.
The preview of this section was stepped on by Godzilla.
The preview of this section was eaten by a grue.
The preview of this section took that left turn at Albuquerque.