Static Code Testing with Android Lint
Your code looks OK, but you want to see if it passes muster when subjected to expert scrutiny.
Run your code through Android Lint (included with modern versions of the Android SDK and
supported by the relevant versions of the ADT Plugin). Examine the warnings, and improve the code where it needs it.
The first "Lint" program originated on Seventh Edition Research Unix at Bell Laboratories.
Steve Johnson wrote it as an offshoot of his development of the first Portable C Compiler,
in the late 1970's. It is covered in my little book "Checking C Programs with Lint" (O'Reilly.
Ever since, people have been writing lint-like tools. Some well-known ones for Java code include
PMD, FindBugs, and CheckStyle.
The first two, plus a number of other tools, are covered in my 2007 book "Checking Java Programs."
The most recent one that's relevant to us is, of course, AndroidLint, a part of the standard Android SDK.
What each of these tools does is examine your code, and offer opinions based on expert-level
knowledge of the language and libraries.
The hard part is to bear in mind that they are only opinions.
There will be cases where you think you know better than the tool, and you later find out that you're wrong. But there will be cases where you're right. And, of course, it's an impossibly-hard problem for the computer to know which, so there is no substitute for the judgement of an experienced developer!
These tools typically find a lot of embarassing
issues in your code the first time you run time. One very common error is to create a Toast by calling makeText(), and forget to call the new Toast's show() method; the toast is created but never pops up! The standard compiler cannot catch this kind of error, but Android Lint can,
and that is just one of its many capabilities.
After laughing at yourself for a minute, you edit (and test!) your code,
and run lint again. You repeat this process until you no longer get any messages that you
To run Android Lint, you can use the command-line version in $SDK_HOME/tools/lint.
Or, you can run it under Eclipse. Just right-click on the project.
Select Android Tools -> Run Lint: Check for Common Errors.
The warnings appear as code markers
just like the ones form Eclipse itself.
Since they are not managed by the Eclipse compiler, you may need to
run lint again after editing your code.
If you get tired of the game, you can use the same menu to remove the lint markers.
Here is an example of running the command line version:
$ cd MyAndroidProject
$ lint .
Scanning .: ......
Scanning . (Phase 2): ..
AndroidManifest.xml:16: Warning: <uses-sdk> tag should specify a target API level (the
highest verified version; when running on later versions, compatibility behaviors may be
enabled) with android:targetSdkVersion="?" [UsesMinSdkAttributes]
<uses-sdk android:minSdkVersion="7" />
AndroidManifest.xml:16: Warning: <uses-sdk> tag appears after <application> tag [ManifestOrder]
<uses-sdk android:minSdkVersion="7" />
AndroidManifest.xml:6: Warning: Should explicitly set android:allowBackup to true or false
(it's true by default, and that can have some security implications for the
application's data) [AllowBackup]
<application android:icon="@drawable/icon" android:label="@string/app_name">
res/values/strings.xml:5: Warning: The resource R.string.addAccounrSuccess appears to
be unused [UnusedResources]
<string name="addAccounrSuccess">Account created</string>
res/values/strings.xml:6: Warning: The resource R.string.addAccounrFailure appears to be
<string name="addAccounrFailure">Account creation failed</string>
res: Warning: Missing density variation folders in res: drawable-xhdpi [IconMissingDensityFolder]
0 errors, 6 warnings
Nothing serious found in this project, but several things that can be cleaned up quickly and easily. Of course the unused string resources don't need any action if they are intended for future use, but if they are old and have fallen out of use, you should remove them to keep your app "mean and clean". As with any automated tool, you know your app better than the tool does, at least for making such decisions.
O'Reilly page on my Lint book and on my Checking Java Programs book.