isEnabled override method in the inner adapter is not implemented

[BenderNK]

Hello @ganfra, Thank you for taking the time to build this library. We are using your spinner in our project and it looks great. However, I found out that your inner class HintAdapter does not override isEnabled() and areAllItemsEnabled() methods. We wanted to display certain rows in the spinner but make them un-selectable depending on the data conditions. Only after closely examining the code, I found out that only certain override methods were implemented in the private inner BaseAdapter class. The supplied adapter is used to construct the private adapter that MaterialSpinner uses but not all of the supplied properties and information is used in this private adapter. For this reason, it is unclear whether supplied adapter's settings will be respected or not. This sort of issue might happen to others so I thought I would bring that to your attention. Thank you!

[patuoynageek]

@TurkerKucuk did you end up implementing it?

[BenderNK]

Yes, I ended up adding the material spinner as a module to our Android project where I implemented required overrides. As a result I appended these two override methods to MaterialSpinner's inner HintAdapter class.

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

@Override
public boolean isEnabled(int position) {
	if (getItemViewType(position) == HINT_TYPE) {
		return false;
	} else {
		return true;
	}
}

[mdumrauf]

@TurkerKucuk can please explain what you are trying to achieve and why that code snippet fulfills your needs? Is it a bug or a feature?

[BenderNK]

Hi @mdumrauf - So in the original post, I explained a little bit. Our goal was to "to display certain rows in the spinner but make them un-selectable depending on certain conditions." When you instantiate the MaterialSpinner, you have to supply an adapter, as you could do with any other listview/recycler view sort of situation. I thought that MaterialSpinner would use the supplied adapter as is when determining how to display items on the list. It turns out that MaterialSpinner was using that adapter to build another private adapter which is eventually used in the code. The final adapter doesn't have those overrides therefore even if we supplied those overrides in the original adapter, final adapter never implemented them.