Instead of using notifyDataSetChanged(), which refreshes the entire view, try using a slick, cool class called DiffUtils which allows you to only update the child elements that have changed. And if your layout is influx, you may still get burned.Īnother option is reduce the amount of time required for refreshing the RecyclerView. I’ve done a fair amount of testing with getLayoutPosition() and I can confirm that it is far more reliable than getAdapterPosition(). One solution is to check the result of the getAdapterPosition() method against RecyclerView.NO_POSITION (which is -1) before using the value returned by getAdapterPosition().īut what if you actually need the value right now and can’t just bypass it? In that case, you can use getLayoutPosition() instead. Unfortunately, the replacement method, getAdapterPosition() doesn’t…you know…work. In the distant past, we used to employ the getPosition() method. If you are planning to use this value to reference an element in an array, it will throw an ArrayIndexOutOfBoundsException. The reason is that the getAdapterPosition() method from the ViewHolder returns a value of -1 if the view is currently refreshing. Crashing RecyclerViewsĪnother quirk of RecyclerViewAdapters is that they sometimes crash when the user selects an item during a refresh. Here is a blog post on which explains the problem and the fix. A simple way to accomplish this is to use the element’s hash code. Then you override the getItemId() method in the adapter and ensure that it always returns the same value for each ID. To prevent this, you set the setHasStableIds value to true on the RecyclerViewAdapter. They briefly disappear and reappear which looks like a “blink”. ![]() Basically, it happens when the view refreshes its images. RecyclerView’s have a bad habit of “blinking” when they update.
0 Comments
Leave a Reply. |