Android - ListAdapter's isEnabled vs areAllItemsEnabled

   Android's ListView supports disabling few or all list items. These items can't be clicked by the user and applications can enable or disable items at runtime via an Adapter and notify a data set change. The confusion for developers is couple of APIs provided by ListAdapter for this functionality. The documentation of these APIs is straight forward.

   A ListView with few disabled items might want to return false from areAllItemsEnabled and return an appropriate value for the specific time from isEnabled.

    @Override
    public boolean areAllItemsEnabled() {
        return false;
    }

    @Override
    public boolean isEnabled(int position) {
        if ( position % 2 == 0 ) {
            return true;
        } else {
            return false;
        }
    }

   And a ListView with no disabled items might want to return true from both areAllItemsEnabled and isEnabled.

    @Override
    public boolean areAllItemsEnabled() {
        return true;
    }

    @Override
    public boolean isEnabled(int position) {
            return true;
    }

   Now, how about an adapter returning false from from areAllItemsEnabled and return true from isEnabled.

    @Override
    public boolean areAllItemsEnabled() {
        return false;
    }

    @Override
    public boolean isEnabled(int position) {
            return true;
    }

   How is the ListView supposed to display the items? It actually enables all these items. In fact, the value returned from isEnabled() takes more preference than that from areAllItemsEnabled(). So what is the need for areAllItemsEnabled(). It was perhaps meant for an optimization where in the ListView doesn't have to check the status for individual item should areAllItemsEnabled() returns true. isEnabled() needs to be invoked only when areAllItemsEnabled() returns false.

   However, this isn't the case with the current implementation and platform developers aren't really willing to change that behavior going forward as that might break quite a few applications in the market. This is documented in one of the changes to AOSP, https://android-review.googlesource.com/#/c/52196. This is one downside to dealing with public SDKs as backward compatibility takes more importance than doing the right thing.