Plain old Find

With the old Edit ⇒ Find ⇒ Find standby, you search for text in the current file (whatever file is currently visible in the editor). And, of course, when you choose Edit ⇒ Find ⇒ Replace, you replace occurrences of a word or phrase with another word or phrase.

I’m not big on memorizing keyboard shortcuts, but I always use shortcuts for this simple version of Find. It’s Ctrl+F on Windows and Cmd+F on a Mac. For the corresponding Replace action, it’s Ctrl+R on Windows and Cmd+R on a Mac.

When you select the plain, old Find option, you get a Find panel. (See Figure 1-20.) This Find panel has some nice options to help you customize your search.

With the up- and down-arrow icons, you can search upward or downward from your current position. With the Match Case check box, a search for textView doesn’t find the capitalized name TextView. With the Words check box, you find whole words only (so that searching for View finds android.view.Menu but doesn’t find textView).

With the Regex check box, you search for a regular expression match. Here are some examples:

• A character followed by an asterisk matches zero or more of those characters.

  For example, if you search for o*ps!, you find ps!, ops!, oops!, ooops!, and so on.

• A character followed by a plus sign matches one or more of those characters.

  For example, if you search for o+ps!, you find ops!, oops!, and ooops!. But you don’t find ps!.

• A dot matches any single character.

  The pattern b.t finds bat, bet, bit, bot, but, bbt, bct, b@t, b.t, and so on.

• A backslash followed by a dot matches a single dot character.

  The pattern b.t finds b.t, but it doesn’t find bat, but, b..t or b .

• A dot followed by an asterisk matches any sequence of zero or more characters.

  For example, b.*t matches bt, bat, boat, and the characters binge wat in the phrase binge watching.

• A bunch of characters enclosed in square brackets matches any one of the characters.

  For example, b[aeiou]t finds bat, bet, bit, bot, but. It doesn’t find bt, boat, or bbt.

For the authoritative description of Android Studio’s regular expression syntax, visit www.jetbrains.com/idea/help/regular-expression-syntax-reference.html.

Searching several files at once

When you choose Edit ⇒ Find ⇒ Find in Path, you get the dialog box shown in Figure 1-21. This is useful for finding all occurrences of a particular word in a project. Imagine that the name submitButton occurs somewhere in a project containing 100 .java files. You can find all files that mention submitButton using the Find in Path dialog box.

Here’s another scenario: I’ve typed my first and last name in several of my project’s files. At some point, I decide to add my middle initial. I can make the change automatically by choosing Edit ⇒ Find ⇒ Replace in Path. In a dialog box that’s similar to the one in Figure 1-21, I type Barry Burd in the Text to Find field, and type Barry A. Burd in the Replace With field.

Highlighting usages

You want to find all occurrences of a variable named button1 in your activity. You can do an ordinary Find, but there’s a better way. On a PC, choose File ⇒ Settings ⇒ Editor ⇒ General. (On a Mac, choose Android Studio ⇒ Preferences ⇒ Editor ⇒ General.) Look for the check box labeled Highlight Usages of Element at Caret. Put a check mark in that check box.

When you return to the editor, select any occurrence of the button1 variable. In response, the editor highlights all occurrences of that button1 variable. (See Figure 1-22.)

The Java file in Figure 1-22 is so small that highlighting a few words hardly matters. But even in this tiny example, you can see how smart the highlighting feature is. The code in Figure 1-22 has four occurrences of the text button1, so if you were to do an ordinary Find for button1, you’d get four hits. But the code really contains two different button1 variables — the button1 field and the button1 parameter. These two button1 variables play two different roles in the example’s code. (The two button1 variables are related to one another. But they’re still two different variables.)

So look again at Figure 1-22. When you select the word button1 in this.button1, Android Studio highlights both occurrences of the button1 field. But occurrences of the button1 parameter are not highlighted. If you selected the button1 parameter instead of the button1 field, only the two button1 parameter uses would be highlighted. That’s how smart the Highlight Usages feature is.

Normally, when you select a name in your code, Android Studio highlights all usages of that name in the file and removes the highlighting from previously highlighted names. You can override this behavior so that the highlighting of a name persists, even when you’re no longer selecting an occurrence of that name. To do so, select a name in the editor. Then, in Android Studio’s main menu, choose Edit ⇒ Find ⇒ Highlight Usages in File. All occurrences of that name will remain highlighted until you press Escape.

Navigating from place to place in your project

A method named computePrice gives you an answer that you don’t expect. You’re staring at the call to computePrice wondering why it gives you that answer. It would help to look at the declaration of the computePrice method. You can shuffle through your project’s files to find the method’s declaration, but it’s easier to select the method call and then choose Navigate ⇒ Declaration. Android Studio jumps instantly to the declaration of the computePrice method. This works for methods, variables, and other names in Android’s SDK, as well as for names that you declare in your own project.

The navigation trick has many variations. Consider the statement

pepBox = (CheckBox) findViewById(R.id.checkBox);

If you select pepBox and choose Navigate ⇒ Declaration, Android Studio jumps to a line of the following kind:

CheckBox pepBox;

But, if you select pepBox and choose Navigate ⇒ Type Declaration, Android Studio jumps to the declaration (in the SDK) of the CheckBox class. If you select MainActivity and choose Navigate ⇒ Super Method, you jump immediately to the declaration of the Activity method.

You can even jump quickly to the Android documentation. Select a name in your code in Android Studio’s editor. Then choose View ⇒ Quick Documentation in the main menu. When you do, a pop-up menu appears. The pop-up menu contains a summary of the Javadoc for that name. The summary contains links. So, within the pop-up menu, you can go from MainActivity to Activity to setContentView and beyond.

Intention actions

You’re minding your own business, typing code, having a good time, and suddenly you see some commotion in the Editor window. A yellow lightbulb icon appears. The icon signals the presence of intention actions — proposals to make small changes to your code. In response to the icon’s appearance, you press Alt+Enter. Doing so makes a pop-up menu appear. The pop-up menu contains a list of suggested changes. If you scroll to a list item and press Enter, Android Studio makes the change.

Figure 1-23 shows just such a pop-up menu.

• If you select Create Test, Android Studio writes a JUnit test for your MainActivity class.

  The JUnit test class calls your activity’s methods and checks the result against results that you expect.

• If you select Create Subclass, Android Studio does what the label suggests. It creates a subclass of your MainActivity class.

  public class MainActivityImpl extends MainActivity {

  }

  The new subclass has an empty body. You add statements to that empty body.

• If you select Add Javadoc, Android Studio creates an empty Javadoc comment.

  /**

  *

  */

  public class MainActivity extends Activity {

  You type lines inside the Javadoc comment.

• If you select Make Package-Local, Android Studio removes the word public from the start of the class declaration.

  In this case, Android Studio is just offering to change whatever it finds in your code. If your class is public, the pop-up menu offers to remove the word public. But if your class isn’t public, the pop-up menu includes a “Make ‘public'” option.

  For a main activity, there’s no good reason to remove the word public. In fact, your app won’t run if the MainActivity class isn’t public.

Code completion

When you type code in Android Studio, the editor guesses what you’re trying to type and offers to finish typing it for you. In Figure 1-24, I type the letters Log. (ending with a dot). Android Studio reminds me that the Log class has static methods named d, e, getStackTraceString, and so on. I can select one of these by double-clicking the entry in the pop-up menu. Alternatively, I can select an entry in the pop-up menu and then press Enter or Tab.

If I press Enter, the selected item goes between the cursor and any text that comes after the cursor. For example, I start with Log.i(MYWHATEVER). I place the cursor after the letter Y and type an underscore. Now I have Log.i(MY_WHATEVER) with the suggestions MY_TAG and MY_WORDS. (See Figure 1-25.)

With the suggestion MY_TAG selected, I press Enter. Then Android Studio creates the text shown in Figure 1-26.

If I press Tab instead of Enter, the selected item replaces any text that comes after the cursor. Starting with the text shown in Figure 1-25, I end up with the text shown in Figure 1-27.

Optimizing imports

InBook I, Chapter 5, I describe a way to make Android Studio write all your import declarations. (On a PC, you put check marks in check boxes after choosing File ⇒ Settings ⇒ Editor ⇒ General ⇒ Auto Import. On a Mac, you do the same, but you start by choosing Android Studio ⇒ Preferences.) When you follow my instructions, Android Studio automatically adds and removes import declarations as you type. That can be a good thing. But sometimes, you want a bit more control.

So what happens if you ignore my instructions from Book I, Chapter 5? You still need import declarations, so you type all the import declarations yourself. But typing import declarations is a big pain. You might not remember the package names for all the classes and methods that you use in your code. Even if you remember these names, you have better things to do with your time than to type a bunch of import declarations.

To help you generate import declarations, Android Studio has several tricks. Here are two stories to illustrate some of the tricks:

• You type the name Toast (a name from the Android API). You haven’t typed the required import declaration at the top of the Java file, so the name Toast appears in red letters. If you hover over the name, Android Studio says Cannot resolve symbol ‘Toast'. (See Figure 1-28.)

  Finally, you click your mouse on the word Toast. When you do, Android Studio suggests a fully qualified name. (See Figure 1-29.) You press Alt+Enter to accept this fully qualified name. As a result, Android Studio adds the appropriate import declaration to your code.

• You use the name Random, and (one way or another) you add import java.util.Random to your code.

  import java.util.Random;

  …

  Random random = new Random();

  Sometime later, you change your mind and decide not to create an instance of the Random class. You delete the declaration of random, but you don’t remove the import declaration. Android Studio changes the color of the import declaration from blue and black to a light gray.

  You can delete the import declaration yourself, but you might have several other declarations to delete. You can delete all the unused import declarations in one fell swoop by choosing Code ⇒ Optimize Imports in Android Studio’s main menu.

Reformatting code

In these busy days, who isn’t in a hurry sometimes? You’re rushing to write code, and you type it in a sloppy fashion.

public class MyClass {

TextView textView;

        public void onButtonClick(View view) {

    textView.setText("Hello");

    }}

You figure you’ll fix the indentation later, when you’re not so pressed for time. But “later” keeps slipping away. Eventually, you have to bottle up your code and publish it on the Google Play Store. No worries! The code’s poor formatting has no impact on its run.

But there’s a big problem. The next time you look at this code (and that time will definitely come) you’ll have trouble understanding what you wrote. Poorly formatted code is difficult to read. And code that’s difficult to read is costly to maintain. What’s even worse, hard-to-read code is annoying!

So how do you fix this quickly and easily? One solution is to avoid ever writing poorly formatted code. To some extent, Android Studio helps you in this goal. As you create new code, the editor positions your lines where they’re supposed to go. Of course, you can override this automatic positioning. (Sometimes, you override the positioning without intending to do so.)

The good news is that Android Studio has a magic bullet. Click your mouse inside the editor. Then, in the main menu, choose Code ⇒ Reformat Code. Et voilà! Android Studio fixes your code’s indentation.

public class MyClass {

    TextView textView;

    public void onButtonClick(View view) {

        textView.setText("Hello");

    }

}

Of course, you might not like the way Android Studio reformats code. I certainly don’t. I have to squeeze long lines of code onto narrow 58-character-wide printed pages. For most of my examples, I need two-character indenting instead of four-character indenting. And I need spaces instead of tab characters because, on the printed page, spaces are more predictable.

Here’s another example. Some people prefer the Allman style for positioning curly braces. In the Allman style, each brace has a line of its own:

public class MyClass

{

    TextView textView;

    public void onButtonClick(View view)

    {

        textView.setText("Hello");

    }

}

Can Android Studio help you with that?

Yes, it can. On a PC, choose File ⇒ Settings ⇒ Editor ⇒ Code Style ⇒ Java. (On a Mac, do the same, but start with Android Studio ⇒ Preferences.) When you do, you see hundreds (maybe thousands) of options for adjusting the way Android Studio formats your code. Change your code’s line length, change the indentation, change the positioning of curly braces, and change so many other things.

In addition to all of its check boxes and drop-down menus, this dialog box shows you some sample Java classes. So when you make a change, you see immediately how the change affects the sample code. If you like the change, you can click Apply. If not, you can keep experimenting.

If you’re one of those people who becomes obsessed with the positioning of curly braces, visit www.riedquat.de/prog/style. On that page, you find a thorough discussion of all the brace styles that people use.

Commenting and uncommenting

I have several lines of code that I don’t particularly like. I want to experiment to find out what happens if these lines are gone. I can select these lines and press Delete, but I might not like the results of the experiment. I might want the lines back in my code. Instead of deleting these lines, I can turn them (perhaps temporarily) into comments.

Java has a few different kinds of comments, including block comments and end-of-line comments. (The language also has Javadoc comments, but you probably wouldn’t use a Javadoc comment to temporarily disable lines of code.) To turn one or more statements into a comment, start by selecting those statements. Then, in the main menu, choose Code ⇒ Comment with Line Comment or Code ⇒ Comment with Block Comment. Whichever option you choose, Android Studio obliges by commenting out the lines that you selected. This trick is a lifesaver if you want end-of-line comments on many lines. But it also helps when you want to create a block comment.

Android Studio’s commenting trick works both ways. Imagine that you’ve turned several statements into end-of-line comments, and you want to change them back to ordinary statements. (That is, you want to uncomment these lines.) First, select the lines. Then, in the main menu, choose Code ⇒ Comment with Line Comment. The name of the option is a bit misleading. (You want to uncomment, not to comment.) Nevertheless, Android Studio sees that you’ve selected commented lines and removes the comment markers as you wish.

Generating code

Consider the humble Java class that I reformat in a previous section.

public class MyClass {

    TextView textView;

    public void onButtonClick(View view) {

        textView.setText("Hello");

    }

}

With your cursor positioned somewhere inside that class, choose Code ⇒ Generate. When you do, you see the pop-up menu shown in Figure 1-30.

If you select Constructor in the pop-up menu, you get another dialog box. (See Figure 1-31.) This little MyClass example has only one field — namely, the textView field. So you can either select or unselect that textView field. If you select the field, Android Studio adds this constructor to your code:

public MyClass(TextView textView) {

    this.textView = textView;

}

If you don’t select the textView field, you get the empty constructor:

public MyClass() {

}

You can repeat the procedure to get as many constructors as you like.

Other options in Figure 1-30 include the Getter, the Setter, and the Getter and Setter options. When you select the Getter and Setter option, you see a dialog box that’s similar to the one in Figure 1-31. The dialog box lists all the fields in your class and lets you select one of these fields. For the tiny MyClass code in this section, the only field is textView. So, when you double-click the textView entry, Android Studio generates the following new Getter and Setter methods:

public TextView getTextView() {

    return textView;

}

public void setTextView(TextView textView) {

    this.textView = textView;

}