Why "wrapper" classes instead of B4XLibs?

This question, for once, is only for Erel.

Erel, you've created a number of "wrapper" classes to add functionality to the CustomListView; is there a reason you didn't "compile" them as B4XLibs?

LucaMs said:

This question, for once, is only for Erel.

Erel, you've created a number of "wrapper" classes to add functionality to the CustomListView; is there a reason you didn't "compile" them as B4XLibs?

Click to expand...

BTW, a list of them:

[B4X] CLVSwipe - xCustomListView Swipe actions and pull to refresh - escluso B4J (class)

CLVNested - Allows nesting CLVs (I haven't checked but I think this is a class too)

[B4X] PreoptimizedCLV - Lazy loading extension for xCustomListView (class)

[B4X] CLVSelections - extended selection modes for xCustomListView (class)

[B4X] CLVExpandable - Allows expanding or collapsing xCustomListView items (class)


and then I stopped looking, maybe there are others.

The extension classes are listed here: https://www.b4x.com/android/forum/t...-cross-platform-customlistview.84501/#content

As they are not compatible with one another, it better to keep them separate.

Erel said:

As they are not compatible with one another, it better to keep them separate.

Click to expand...

That answer wasn't clear to me; having N separate classes or N separate B4Xlibs makes no difference from an incompatibility point of view.

So maybe my question wasn't clear; I wasn't asking why you didn't compile all of them together, in a single library, but why you didn't "compil" the individual classes into as many B4Xlibs.

Now I understand. There is no real reason.

I can say:
1. They solve a small problem.
2. They can't be used without the exact instructions.
3. They don't stand on their own. As a developer, in such cases, I prefer to work with the source code directly.