Android Studio Tips and Tricks

Inlining With Shortcuts

Not only can you use Android Studio shortcuts to extract, but you can also do the opposite: Inlining.

Use the key combination ⌥ + ⌘ + N on MacOSX and Ctrl + Alt + N on Windows/Linux to replace all occurrences of the variable with the actual value or methods in the method body:

Now, it’s time to move on to the next cool thing that Android Studio can help you do: Find and resolve errors!

The Magic of Quick Fix

Android Studio has a super cool feature called Quick Fix or Intention Actions. This feature offers you possible solutions to issues with your code based on the current cursor placement and context.

Quick Fix can fix many common issues such as removing unused imports, unused methods or unused variables; switching out var with val; switching out multiple if–else instances with switch/when statements; and more.

To summon this magical feature, simply use the key combination of ⌥ + Enter on MacOSX and Alt + Enter on Windows/Linux:

So you’ve found quick ways to rearrange your code and to identify and fix problems. But how about moving around your codebase?

Using Android Studio to Navigate Your Codebase

While refactoring code is a powerful tool for developers, another benefit of using Android Studio is being able to navigate your codebase efficiently. Android Studio’s options and key bindings make it effortless to look through the codebase.

Searching the Codebase

When it comes to finding anything in your code, Android Studio has a super-helpful global search, which you access by pressing the Shift key two times.

That shortcut brings up a search box where you can look for files, classes, symbols, tests, methods etc. If there’s one thing that you need to memorize, it’s this keyboard combination:

Running More Specific Searches

But wouldn’t it be better to search for specific types of items, like files, classes or symbols, in the first place?

Don’t worry, Android Studio has you covered with various sub-search features that you can access with these key combinations:

1. To search only enumerations, classes, interfaces, and so on, use ⌘ + O on MacOSX and Ctrl + N on Windows/Linux
   
2. To search files only, use ⌘ + ⇧ + O on MacOSX and Shift + Ctrl + N on Windows/Linux
   
3. To search only symbols, use ⌘ + ⌥ + O on MacOSX and Shift + Ctrl + Alt + N on Windows/Linux
   

Another kind of search which is very handy lets you look for actions. When you forget where a particular action is in the IDE, you can find it again easily by using ⇧ + ⌘ + A on MacOSX and Shift + Ctrl + A on Windows/Linux:

How about jumping to corresponding tests? To do that, you need to go to the class declaration and use ⇧ + ⌘ + T on MacOSX and Shift + Ctrl + T on Windows/Linux.

Showing Methods and Properties

Now and then, it’s helpful to get an overview of the whole class, which gives you a better understanding of the code and a bird’s eye view of the class’s functionality.

Android Studio provides a quick overview, which you can access using the key combination ⌘ + F12 on MacOSX and Ctrl + F12 on Windows/Linux.

Go to an Implementation/Declaration

Let’s say that you’re scrolling through the codebase and find an unfamiliar method being called. To jump to its definition, all you need to do is select the method and hit ⌘ + B on MacOSX and Ctrl + B on Windows/Linux.

Once at the definition, if you press the same keyboard shortcut again, it’ll take you back to where the method is used.

Locating Errors

When the project encounters errors, you’re already sad. :[ Having to hunt for those errors in the file is even more frustrating. Trying to scroll through thousands of lines of code to find the error is like finding a needle in a haystack.

Android Studio simplifies this to a single key: F2. Hitting F2 when there are errors in the file will allow jumping to the next line of error. That’s quite a productivity booster!

By pairing F2 with Shift, you can jump back to the previous line of error in the same file.

To test this, delete the method named printRecordingState() inside MainActivity.kt. This will introduce errors in the class.

Now, use the shortcut to jump to the lines of code where there’s an error.

Before you move on to the next section, undo your changes to remove the errors.

Debugging Like a Pro

As a developer, you can’t avoid debugging your codebase. Being a good debugger is a necessity.

Android Studio offers a few tricks to make debugging easier.

Color Code Logcat

This trick is somewhat superficial, but it helps you to separate logs inside Logcat using colors. Each type of log will have its own color.

To change Android Studio Logcat, you need to:

• Assert #BA68C8
• Debug #4CAF50
• Error #F44336
• Info #2196F3
• Verbose #BBBBBB
• Warning #FF9800

1. Go to Preferences (Settings on Windows or Linux machines) ▸ Editor ▸ Color Scheme ▸ Android Logcat.
2. Change the foreground color for every type of log.
3. Uncheck the option: Inherit values from: Console ▸ Error output.
4. Set a color value for each type of log:

Logging Using Non-Suspending Breakpoints

This next trick is a sure time saver. As a developer, you might want to put debug logs in your code so that you can track specific points while it’s executing.

Obviously, this is not very efficient; since debug logs are not required in the release codebase, you’ll have to remove them manually. Oh my!

Android Studio has a neat trick that can save you from the overhead of adding and removing log statements by using breakpoints.

To get this set up, place any breakpoint on a line and then right-click inside of it. This will open a menu pop-over. Uncheck the Suspend option to enable more options in the pop-over:

Once you’ve enabled the extra options and they’re visible, check the Evaluate and Log option. Next, enter a log statement with a variable appended to it, just as you would with a normal log statement.

Now, when you run the app in debug mode, your code will hit the breakpoint but won’t stop the execution. Instead, it will print the evaluated statement into the Console window.

Once done, remove all the breakpoints. Since these breakpoints are non-suspending, you can also choose to keep them.

Your code will only hit the breakpoints when you run the app in debug mode. For the release/production version, you don’t have to do any extra work. A win-win situation for all. :]

Now that you have some debugging tricks in your toolbelt, it’s time to take a look a how to set up the UI to be just the way you like it.