Divide OnUpdateListener in two diferentes Listener about flexibleadapter

[davideas]

Hello @danielpassos, during the development I also thought to divide the listeners, but in the end I opted for 1 only. I can separate them again now.
But I will not remove the parameter from the constructor because it's easier for a developer (the adapter can do these assignments for him), because changing the signature will change the current implementation of hundreds of people, because developers don't know the internal names of the listeners and they have to check the adapter code.

[danielpassos]

because changing the signature will change the current implementation of hundreds of people

I agree with that, I'll put it back in my PR, but pass a Object in the contructor seems wrong to me. Maybe deprecate that and create a new one or only deprecate that to remove in future releases. wdyt?

[davideas]

Wait to change the PR.
Also I was thinking that the method startUndoTimer can accept the listener for confirmation of deletion: basically it's only in that occasion and it is not necessary to have listener as member but can be kept as final parameter.

[danielpassos]

Wait to change the PR.

Done. I put it back as @deprecated but leave the example app using the new one

Also I was thinking that the method startUndoTimer can accept the listener for confirmation of deletion: basically it's only in that occasion and it is not necessary to have listener as member but can be kept as final parameter.

Not sure if I got you point here.

[davideas]

I mean to pass the listener to this function:

public void startUndoTimer(final OnDeleteCompleteListener listener, long timeout) {
    mHandler = new Handler(Looper.getMainLooper(), new Handler.Callback() {
            public boolean handleMessage(Message message) {
                if (listener != null) listener.onDeleteConfirmed();
                ...
            }
        });
    ...
}

[danielpassos]

Gotcha. Must better and done! :)

[davideas]

@danielpassos, so about OnUpdateListener, I am not sure to keep it, because after all I don't see a big advantage of an Asynchronous loading: usually the list is already loaded Asynchronously somewhere else.
I wanted a suggestion from you.

[danielpassos]

I totally agree with you but we need to keep in mind it will broke the old project/compatibility. I know it's sucks, but it's a library and what we do in libraries/frameworks is:

1. Make it as deprecated
2. Update the docs
3. Announce in some place we are about to remove it.
4. In a new version bumping MAJOR (see the semver) and remove it. It make clear for the developers we broke the compatibility.

[davideas]

Indeed it will break compatibility, but before release as major version, I wanted to add new functionalities, such as animation on loading. I already know how to do it, maybe multi ViewHolder, fix the way how ItemAnimator are used, use or import a nice SearchView, that I have identified, in the example App.
So your changes will not be released soon, and we have time to inform ppl about these deprecation.
In the meantime I have to work also on others projects...
Thanks for the suggestion.

[danielpassos]

You can release a small version bumping MINOR with the new listeners or for every new feature you add, and than release a new one with a new big improvement/removing deprecation bumping the MAJOR