DEV Community

Cover image for Matt's Tidbits #102 - Debugging a perplexing view binding issue
Matthew Groves
Matthew Groves

Posted on • Originally published at Medium

Matt's Tidbits #102 - Debugging a perplexing view binding issue

This week I have a tidbit (plus a bonus!) to share about converting an existing app to using Android view binding. Last time, I wrote about how to write a good bug report.

First, the bonus! (Shouldn't dessert always come first?) I recently started getting back into some Android development (after working in React Native for the past 6+ months), and opened up the shiny new Arctic Fox release of Android studio. Upon doing so, however, I noticed that many of my familiar keyboard shortcuts no longer worked (such as ⌘W for closing an editor window). It appears that Android Studio changed the default keyboard mappings - so if you run into this, just go into Preferences->Keymap and select "macOS" instead of "IntelliJ IDEA Classic".

Now, for the main tidbit. 😉

The reason I came back to Android is because I am updating an internal project to work with all of the latest tools/paradigms/etc. This app still uses MVP as its paradigm, and even still uses Butterknife (which has been deprecated for more than a year). The UI for this app is fairly simple - it has a RecyclerView, and when you click on one of those items it launches a new activity. In the process of switching over to Android view binding, however, I ran into a bug - nothing was rendering in my RecyclerView!

I spent WAY longer than I'd like to admit debugging this - putting in breakpoints, print statements, double-checking that the data was being passed to the right place, trying various combinations of calling notifyDataSetChanged() and submitList() - all to no avail. No matter what I did, the onCreateViewHolder() and onBindViewHolder() methods of my adapter were never being called.

Stumped? Thankfully, the solution ended up being pretty simple. Once I looked at a complete implementation for a screen that had a working RecyclerView, I noticed a key difference.

In the activity that wasn't working, I had the following line in the onCreate() method:

setContentView(R.layout.my_activity)
Enter fullscreen mode Exit fullscreen mode

However, the activity that worked had this line instead:

setContentView(binding.getRoot())
Enter fullscreen mode Exit fullscreen mode

That was it! Switching to the newer version that used the binding object I had saved was enough to do the trick.

What did I learn from this?

  1. I need to do some more studying to make sure I'm staying up-to-date with the latest tools (I haven't honestly used view binding that much - I like what I see thus far, but I didn't really know what to look for at first).

  2. Take a break/talk to someone else - I will give my wife the credit for this one - she's not a programmer, but asked me what I was trying to solve, and simply in the process of trying to explain it and showing her the code, I stumbled upon this key difference.

  3. Simplify the problem/challenge your assumptions - I should have done this sooner - stripping out all unnecessary code and sanity-checking myself to make sure I could reproduce a working solution, and then comparing that with what wasn't working.

I hope you learned something, and that if/when you convert your old Android UI code to use view binding that it's a smoother/faster transition than this was for me!


Interested in working with me in the awesome Digital Products team here at Accenture? We have several open roles, including:


What has your experience with using view binding been like? Let me know in the comments below!

Top comments (0)