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)However, the activity that worked had this line instead:
setContentView(binding.getRoot())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?
- 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).
- 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.
- 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!
