Which is Which: Named Breakpoints15 Jan 2020 | tags: android studio tools
I have always believed that one of the biggest factors that influence a person’s enjoyment and delight in doing their job are the tools. Having the right tools and using them the best way possible helps direct our energy on the what rather than the how.
For instance, I have lost count of how many times I stopped in the middle of a debugging session only to find myself drowning in breakpoints. I have put in so many that I have lost track of which breakpoint does what, or why I even put a breakpoint on a particular line in the first place.
What are even these lines
It is situations like this that breakpoint descriptions become super handy. These descriptions appear after the line number and provide an easy way of keeping track AND searching for breakpoints.
For example, adding “drag dismiss” after the breakpoint on line 84 serves as a short note to myself what that piece of code is doing. It gives me a hint about what I may want to do with that breakpoint when I’m grouping, muting, cleaning up, or managing all the other breakpoints.
Breakpoint with a description
To add a description, open the Breakpoints Dialog.
First open the Edit Breakpoint dialog using any of the following:
ALT + ENTERon any line with a breakpoint and then choosing “Edit Breakpoint”
SHIFT+COMMAND+F8on any line with a breakpoint
- right-clicking on a breakpoint in the gutter
Edit Breakpoint dialog
We can then click on More or press
SHIFT+COMMAND+F8 to open the Breakpoints Dialog. Right click on the breakpoint in question and choose Edit Description:
Adding a description
This is admittedly an over-simplified example (in my main project I have so many breakpoints accumulated over so many debugging sessions and I’m afraid to remove any of them. Don’t @ me.), but finding a specific breakpoint is now easy as!
Search through all breakpoints easily
Scratch That Itch21 Nov 2019 | tags: android studio tools
One of the most useful things for me whilst I was learning Kotlin was TryKotlin. It gave me a quick way to test concepts, try new APIs, or just to get familiar with the syntax.
Sometimes though I want to see if something would work with my own data classes, and it’s a bit too much trying to cram them all into that page. Other times I don’t want to use my own app either, cause that means adding logs or
TextViews then recompiling and rerunning the whole app just to see if something would work as I expect it to.
It is during these times that scratch files really come in handy. Scratch files are super lightweight, runnable, and debuggable files.
Creating scratch files
To create a new scratch file, press
⌘ + SHIFT + N (or
File > New > Scratch File). There are a whole bunch of file types available, including Kotlin, Java, and JSON.
Some of the available file types
Since scratch files are fully functional, make sure to choose the correct file type so you get syntax highlighting, auto-completion, and all the other file type-specific features of IntelliJ.
When choosing Java, IntelliJ automatically creates the
main()function for you; when choosing Kotlin, there is no need to declare a main function – everything in the file is executed as if they are inside
Locating scratch files
You can access all of your scratch files inside
Project > Scratches and Consoles > Scratches.
Open Project View by default in Android Studio by going to
Help > Edit Custom Propertiesand adding
All of the scratches
The first file of any particular type is named
scratch by default, and any subsequent ones have an increasing integer attached to it.
Scratches are not attached to any one project, which means that we can try something out in project and have that scratch file viewable in other projects as well!
Using scratch files
You can use and navigate around scratch files the same way you would any other file in Android Studio.
When you’re ready to run your file, click on the green play button on the upper left of the editor. The output of the scratch would be displayed on the right hand side of the screen.
Output of scratch file
For added fun, enabling Interactive Mode runs your code automatically when you stop typing!
If we are logging too much text and it won’t fit the side panel, Android Studio would automatically open the Scratch Output panel.
That's a lot of text
Accessing Your Own Stuff
Let’s say I want to play around with the
User data class in the
about module of Plaid. With scratch files, we do not have to copy-paste the data class.
To access this existing class, we need to import them into the file like normal. And since scratch files are fully functional, auto-import is supported too!
Make sure to choose the correct option in the “Use classpath of module” dropdown before running your scratch file. Remember that if the underlying source code changes, the scratch files pick up those changes too (as soon as you rebuild the module that is!)!
On-Device Debugging Part V: Strut Your Stuff20 Jul 2019 | tags: android
Over the past year, my team have been steadily building a Developer Options screen for our app. It is a simple
PreferenceScreen available on debug builds that help us:
- figure out what’s going on without needing to be attached to a computer
- test various configurations without re-installing
- have a host for various experimentations we are trying to explore
In this series of posts, I will share what these various options are and how we made them.
Read the other posts in this series:
- Part I: Now It’s On, Now It’s Off
- Part II: Timbeeeeeeer!
- Part III: Inspect, Reset, Repeat
- Part IV: Log All The Things!
Working on an app means we are constantly tweaking how things look. Change this shade of green, use this widget instead of that, move this thing to there.
In the last part of our on-device debugging series, we look at some of the ways we showcase how things should look in our app.
Design Playground and Shortcuts
My team is SMASHING IT. 💪 pic.twitter.com/YoJmRF1ZLJ— Zarah Dominguez 🦉 (@zarahjutz) June 3, 2019
We fully expected that some widgets might look strange and we might have to tweak some things a bit. Taking inspiration from the MDC Catalog app, we came up with a Theme Showcase page.
This page has all the widgets as well as the custom components we use throughout the app.
This has been really useful in helping us figure out how things look as we go through adapting MDC. This page has also been handy when we are tweaking something with our design team, and as a reference page for when we are visually testing a new feature.
Since we also have multiple themes in the app, we included a theme switcher that allows us to see how everything looks in each of the themes.
Dynamically switch themes
This switcher is accessed through the overflow menu. When the user chooses a theme, we save the value to a
For simplicity, we only save the position of the chosen theme:
We then need to make sure that we get back the chosen theme:
And set it on our Activity’s
Some parts of the app are a bit cumbersome to get to.
When we were building our app’s order confirmation page, it was getting annoying having to complete an order each time to see how it looks whenever we change something in the layout.
As we saw in my previous post about app shortcuts, we can put in a
targetPackage and a
targetClass in our
Having these shortcuts available helped us skip having to navigate through multiple steps to get to a particular screen.
And with that, we wrap up this series on on-device debugging options. We have seen how we can make feature toggles more user-friendly, how we can surface stacktraces for quicker debugging, and how we can retrieve Logcat traces out of our testers’ devices.
Thank you for sticking with the series, and massive thanks to everyone who has given me their time helping get these posts through!