Speeding up RecyclerViews follow up

I posted my Speeding up RecyclerViews article on the androiddev subreddit. One of the feedback I’ve gotten said that the article is terribly written.

The reddit post is here.

Apparently the reason the article is terribly written isn’t because of the suggestions I made to speed up RecyclerViews, but because of the solution I chose to solve my client’s problem with the slow list of input fields.

In the specific problem that I was solving, the API was returning a list of data that was to be turned into a list input fields on the screen like EditText fields, checkboxes, date picker, and etc. Unfortunately, this list of data is completely unpredictable and varies based on the dataset I’m querying. If the list of data from this API endpoint was uniform and consistent, then yes, RecyclerView would have been a fine solution. But instead, I decided to simply display the dataset in a loop in a LinearLayout. Yes, I know this isn’t the perfect/ideal solution.

Perhaps there was more I could have done to make RecyclerViews work, like implementing some sort of caching of my own (as one redditor suggested) which would involve a lot of custom logic and among other things. But here’s the thing… This specific endpoint will never ever ever EVER return enough data for the app to have memory problems that RecyclerView was meant to address. Also, considering the budget and the timeline of the project, I decided that simply iterating over the dataset was a “good-enough” solution.

If the project had unlimited budget and time? Sure, I’d be happy to spend more time on this, but considering the budget of the project, I decided that writing beautiful perfectly optimized code wasn’t worth getting my hourly rate below the minimum wage especially when the “good-enough” solution will work fine.

Geez, developers are critical.