search

Doist / RecyclerViewExtensions

RecyclerView made easier.
MIT License
495 stars 42 forks source link

Add DelayedFlipper and delayed options to EmptyRecyclerFlipper + ProgressEmptyRecyclerFlipper #38

Closed bmoliveira closed 3 years ago

bmoliveira commented 3 years ago

This PR adds the option of adding the DelayedFlipper to EmptyRecyclerFlipper and ProgressEmptyRecyclerFlipper.

Additional changes:

bmoliveira commented 3 years ago

I will revert the .kts conversion, it makes sense to support the wider range of environments as possible.

Regarding Kotlin usage at this stage, it should not be a problem since almost every project will end up using it. And the versatility and benefits it brings are greater than the downsides.

bmoliveira commented 3 years ago

I still think that it's still too early for Kotlin conversion. As far as I know among most popular Android libraries, only okhttp was converted to Kotlin. For example AndroidX is still in java and has Kotlin only in ktx modules. Conversion into Kotlin won't provide any advantages to lib users but only extra dependencies. Given that we don't maintain this library often, keeping it in Java doesn't slow down us.

You are right we don't need to force the users to Kotlin yet, and the maintenance here is marginal so I've refactored the Flipper classes back into Java.

I still don't understand why we need method configure. Given how much changes it brings to client's code, I'd avoid it. We can pass livecycleOwner into constructor along with views. If method configure is necessary for delayed version of flippers, then we can make this method protected and use it internally in flippers where needed.

Here I was trying to refactor the EmptyRecyclerFlipper and ProgressEmptyRecyclerFlipper into a delegate approach because in some cases it might be needed, but the changes as you said are many, so I've maintained the current constructor approach and on the Delayed versions maintained the API as well.

Have separate module, e.g.FlippersDelayed

I've refactored the modules into a separate one, but now I have a small problem that I didn't find a solution for. The FlippersDelayed module will depend on Flippers. Afterward, when we will use it if the project doesn't have a Flippers module it will not be able to resolve. With libraries being distributed via maven for example, we don't need to worry about this, but in the git submodules case, I can't find a workaround for it. ref

bmoliveira commented 3 years ago

we should consider publishing it into maven :)

I also agree it would make the versioning and release process clearer for the end users.