Try this method:

List<Business> mBusinesses2 = mBusinesses; mBusinesses.clear(); mBusinesses.addAll(mBusinesses2); //and do the notification 

a little time consuming, but it should work.

Just to complement the other answers as I don't think anyone mentioned this here: notifyDataSetChanged() should be executed on the main thread (other notify<Something> methods of RecyclerView.Adapter as well, of course)

From what I gather, since you have the parsing procedures and the call to notifyDataSetChanged() in the same block, either you're calling it from a worker thread, or you're doing JSON parsing on main thread (which is also a no-no as I'm sure you know). So the proper way would be:

protected void parseResponse(JSONArray response, String url) { // insert dummy data for demo // <yadda yadda yadda> mBusinessAdapter = new BusinessAdapter(mBusinesses); // or just use recyclerView.post() or [Fragment]getView().post() // instead, but make sure views haven't been destroyed while you were // parsing new Handler(Looper.getMainLooper()).post(new Runnable() { public void run() { mBusinessAdapter.notifyDataSetChanged(); } }); 

}

PS Weird thing is, I don't think you get any indications about the main thread thing from either IDE or run-time logs. This is just from my personal observations: if I do call notifyDataSetChanged() from a worker thread, I don't get the obligatory Only the original thread that created a view hierarchy can touch its views message or anything like that - it just fails silently (and in my case one off-main-thread call can even prevent succeeding main-thread calls from functioning properly, probably because of some kind of race condition)

Moreover, neither the RecyclerView.Adapter api reference nor the relevant official dev guide explicitly mention the main thread requirement at the moment (the moment is 2017) and none of the Android Studio lint inspection rules seem to concern this issue either.

But, here is an explanation of this by the author himself

I had same problem. I just solved it with declaring adapter public before onCreate of class.

PostAdapter postAdapter; 

after that

postAdapter = new PostAdapter(getActivity(), posts); recList.setAdapter(postAdapter); 

at last I have called:

@Override protected void onPostExecute(Void aVoid) { super.onPostExecute(aVoid); // Display the size of your ArrayList Log.i("TAG", "Size : " + posts.size()); progressBar.setVisibility(View.GONE); postAdapter.notifyDataSetChanged(); } 

May this will helps you.

Although it is a bit strange, but the notifyDataSetChanged does not really work without setting new values to adapter. So, you should do:

array = getNewItems(); ((MyAdapter) mAdapter).setValues(array); // pass the new list to adapter !!! mAdapter.notifyDataSetChanged(); 

This has worked for me.

In my case, force run #notifyDataSetChanged in main ui thread will fix

public void refresh() { clearSelection(); // notifyDataSetChanged must run in main ui thread, if run in not ui thread, it will not update until manually scroll recyclerview ((Activity) ctx).runOnUiThread(new Runnable() { @Override public void run() { adapter.notifyDataSetChanged(); } }); } 

Clear your old viewmodel and set the new data to the adapter and call notifyDataSetChanged()

I always have this problem that I forget that the RecyclerView expects a new instance of a List each time you feed the adapter.

List<X> deReferenced = new ArrayList(myList); adapter.submitList(deReferenced); 

Having the "same" List (reference) means not declaring "new" even if the List size changes, because the changes performed to the List also propagates to other Lists (when they are simply declared as this.localOtherList = myList) emphasis on the keyword being "=", usually components that compare collections make a copy of the result after the fact and store it as "old", but not Android DiffUtil.

So, if a component of yours is giving the same List each and every time you submit it, the RecyclerView won't trigger a new layout pass. The reason is that... AFAIR, before the DiffUtil even attempts to apply the Mayers algorithm, there is a line doing a:

 if (newList == mList)) {return;} 

I am not sure how much "good practice" does de-referencing within the same system is actually defined as "good" ... Specially since a diff algorithm is expected to have a new(revised) vs old(original) component which SHOULD in theory dereference the collection by itself after the process has ended but... who knows...?

But wait, there is more...

doing new ArrayList() dereferences the List, BUT for some reason Oracle decided that they should make a second "ArrayList" with the same name but a different functionality.

This ArrayList is within the Arrays class.

/** * Returns a fixed-size list backed by the specified array. (Changes to * the returned list "write through" to the array.) This method acts * as bridge between array-based and collection-based APIs, in * combination with {@link Collection#toArray}. The returned list is * serializable and implements {@link RandomAccess}. * * <p>This method also provides a convenient way to create a fixed-size * list initialized to contain several elements: * <pre> * List&lt;String&gt; stooges = Arrays.asList("Larry", "Moe", "Curly"); * </pre> * * @param <T> the class of the objects in the array * @param a the array by which the list will be backed * @return a list view of the specified array */ @SafeVarargs @SuppressWarnings("varargs") public static <T> List<T> asList(T... a) { return new ArrayList<>(a); //Here } 

This write-through is funny because if you:

Integer[] localInts = new Integer[]{1, 2, 8}; Consumer<List<Integer>> intObserver; public void getInts(Consumer<List<Integer>> intObserver) { this.intObserver = intObserver; dispatch(); } private void dispatch() { List<Integer> myIntegers = Arrays.asList(localInts); intObserver.accept(myIntegers); } 

... later:

getInts( myInts -> { adapter.submitList(myInts); //myInts = [1, 2, 8] } ); 

Not only does the List dispatched obeys the dereferencing on each submission, but when the localInts variable is altered,

public void set(int index, Integer value) { localInts[index] = value; dispatch(); // dispatch again } 

...

myModel.set(1, 4) // localInts = [1, 4, 8] 

this alteration is also passed to the List WITHIN the RecyclerView, this means that on the next submission, the (newList == mList) will return "false" allowing the DiffUtils to trigger the Mayers algorithm, BUT the areContentsTheSame(@NonNull T oldItem, @NonNull T newItem) callback from the ItemCallback<T> interface will throw a "true" when reaching index 1. basically, saying "the index 1 inside RecyclerView (that was supposed to be 2 in th previous version) was always 4", and a layout pass will still not perform.

So, the way to go in this case is:

List<Integer> trulyDereferenced = new ArrayList<>(Arrays.asList(localInts)); adapter.submitList(trulyDereferenced); 

Solution for those users who use reverse layout like chat list

add this function in your adapter class

fun updateChatList(msgData: DataDetails) { // DataDetails is custom model class var tmpdata = ArrayList<DataDetails>() tmpdata.add(msgData) tmpdata.addAll(data) //data is your data define in adapter data.clear() data.addAll(tmpdata) this.notifyDataSetChanged() }