Request: use the default divider of the OS about recycler-view-divider HOT 24 CLOSED

Well you can put the basic ones, and if in code it's different, the code overrides how it works, just like on other cases on Android.

from recycler-view-divider.

It can be a good idea to use the OS default for the divider color but it will introduce a breaking change so currently I'll keep this open.
BTW, you can change ALL the RecyclerViewDivider in your app in once using RecyclerViewDivider.BuilderProvider (wiki reference).

E.g.

class App : Application(), RecyclerViewDivider.BuilderProvider {
    override fun provideDividerBuilder(context: Context): RecyclerViewDivider.Builder =
        // Set the default drawable reading the value of android.R.attr.listDivider.
        RecyclerViewDivider.with(context).drawable(typedArray.getDrawable(0))
}

In this way, by default all the RecyclerViewDivider in your app will have the default Android divider and in case, you can override that default with other custom configs.

I'm leaving this issue open until I won't release a breaking change version.
Tell me if you have any question.

from recycler-view-divider.

Wait, how does your library know where to look for the class that implements this interface?

from recycler-view-divider.

It should be the Application. The library checks if the Application implements RecyclerViewDivider.BuilderProvider using context.applicationContext every time you invoke RecyclerViewDivider.with(context).

from recycler-view-divider.

Why every time? It's already initialized...
Or does it assume it might change on some cases, like changing themes?
Why do you think it's a breaking change?
Set the drawable to be the default one, and if it doesn't exist for some reason, set one that was used so far.
The current one is very white...

Speaking of colors, isn't it actually better to set it in the themes instead of in the class that extends Application?

from recycler-view-divider.

Why every time? It's already initialized...
Or does it assume it might change on some cases, like changing themes?

Exactly for this, cause the themes can change.

Why do you think it's a breaking change?

Because some of the users of the library could use the default color instead and when they upgrade, the color will change.

Speaking of colors, isn't it actually better to set it in the themes instead of in the class that extends Application?

In the old versions of this library, it worked like this, but there was a problem: it couldn't be flexible.
The users couldn't provide a default using for example a VisibilityManager which hides the last divider of a list.
It should be set programmatically to provide this flexibility.

from recycler-view-divider.

About breaking I see.
But I don't get about the themes. What's the difference? Just provide both ways (themes and programmatically), just like on many things on Android.
How is it related to VisibilityManager ?

from recycler-view-divider.

I meant that in the attributes you can't insert any logic inside it like "show all the dividers in a list except the last one" or "every two divider, change the color".
But thinking about themes, what I can do is provide some default attributes as you said which can be overridden by the RecyclerView.BuilderProvider which can be overridden by the in-place configuration.

from recycler-view-divider.

BTW, I think what you mean in the application class should be as such:

    override fun provideDividerBuilder(context: Context): RecyclerViewDivider.Builder {
        val result = RecyclerViewDivider.Builder(context)
        obtainStyledAttributes(intArrayOf(android.R.attr.listDivider)).use { typedArray ->
            typedArray.getDrawable(0)?.let { result.drawable(it) }
        }
        return result
    }

from recycler-view-divider.

Yes, before I wrote it quickly, your version should achieve what you want until the behavior we discussed above will be implemented inside this library.

from recycler-view-divider.

OK.
May I suggest a bit more for next version?

If indeed it could break older code, you should change the API calls so that it won't be able to be built for people who upgrade without them needing to check why it occurs and what should be done to fix it via the repository website FAQ.

Also, I suggest adding nullability annotation everywhere that's possible. It helps with handling possible bugs

from recycler-view-divider.

May I suggest a bit more for next version?

Sure, I appreciate it.

If indeed it could break older code, you should change the API calls so that it won't be able to be built for people who upgrade without them needing to check why it occurs and what should be done to fix it via the repository website FAQ.

Yes, I can implement it like so.

Also, I suggest adding nullability annotation everywhere that's possible. It helps with handling possible bugs

I have not understood this one. The library is totally written in Kotlin, therefore the nullability is explicit. If you use this library in Java, it automatically adds the annotation @NotNull when it shouldn't be null. What did you mean?

from recycler-view-divider.

Oh never mind about the nullability part. I think it was my mistake about something there...

from recycler-view-divider.

Oh ok, no problem. BTW currently you can use the version you posted above. I'll update this issue when I'll release the new library with these new features.

from recycler-view-divider.

I think the application method doesn't always work well for me for some reason (shows a very dark divider that I can barely even notice), but only in dark theme ( a theme that extends from Theme.MaterialComponents).

There is a difference between using the application method and the one that I wrote in the beginning. The one I wrote in the beginning works in both cases, showing the divider.

Note that I set the theme at runtime.

I suggest you to check it out.
For now, I will use the original method I've suggested.

from recycler-view-divider.

Oh, it occurs even if I don't set the theme at runtime.

from recycler-view-divider.

I think I will just create an extension function addDefaultDivider . That's the reason I use this library, actually, because all the others had some issues.

from recycler-view-divider.

Mmh this is very strange since the method provideDividerBuilder(Context) will be invoked every time you invoke RecyclerViewDivider.with(Context) using the same Context of your in-place call (e.g. your Activity).

This is the implementation of RecyclerViewDivider.with(Context):

fun with(context: Context): Builder =
    (context.applicationContext as? BuilderProvider)?.provideDividerBuilder(context)
        ?: Builder(context)

So honestly I can't understand what's wrong since if you change the code:

obtainStyledAttributes(intArrayOf(android.R.attr.listDivider)).use { typedArray ->
    typedArray.getDrawable(0)?.let { RecyclerViewDivider.with(this).drawable(it).build().addTo(recyclerView) }
}

to:

RecyclerViewDivider.with(this).build().addTo(recyclerView)

After the changes to your Application class, it will the same to write:

// From the builder provider.
val result = RecyclerViewDivider.Builder(this)
obtainStyledAttributes(intArrayOf(android.R.attr.listDivider)).use { typedArray ->
    typedArray.getDrawable(0)?.let { result.drawable(it) }
}
// From your in-place call.
result.build().addTo(recyclerView)

from recycler-view-divider.

I don't know. Would you like me to try to create a POC ?

from recycler-view-divider.

If that's not a problem for you, yes, it would be helpful to reproduce it.

from recycler-view-divider.

OK here:

#43

from recycler-view-divider.

Ok thanks very much, for this bug we'll continue in the related issue #43

from recycler-view-divider.

Please refer to the issue #45 from now on.

from recycler-view-divider.

Just released the version 3.2.0 which uses android:listDivider by default to get the divider's Drawable.

from recycler-view-divider.