feat: Support multiple filter selection

[RafaelsRamos]

What does this PR do?

1. Fixed typo on filter preference key;
2. Create a bottom sheet for filtering & sorting;
3. Ensures Home & Subscription screens filter their content accordingly;
4. closes Adding multiple selection to the subscription feed filter  #5453

Notes

Transition

Fixing the typo on the filter preference key results in resetting the users' current filter preference. This is intended since it greatly simplifies the logic to support multiple filters. If we decide that we want to transition to multiple filter support without a reset, that can be achieved by reverting the typo fix + adjusting the following property on ContentFilter.kt:

private val enabledFiltersSet get() = PreferenceHelper
    .getString(SELECTED_FEED_FILTERS, "1,2,3")
    // Line below supports a transition from the currently selected filter
    .let { filtersPref -> if (filtersPref == "0") "1,2,3" else filtersPref } 
    .split(',')
    .toMutableSet()

If you think it is worth it, we can go ahead and add support for a transition from the currently selected filter.

Showcase

sample.mp4

Closing Notes

Thank you for reviewing! Please let me know if you disagree with the approaches I chose.

[Bnyro]

Fixing the typo on the filter preference key results in resetting the users' current filter preference. This is intended since it greatly simplifies the logic to support multiple filters. If we decide that we want to transition to multiple filter support without a reset, that can be achieved by reverting the typo fix + adjusting the following property on ContentFilter.kt:

I think it's fine to change the preference key for the transition, I already did the same thing multiple times before when refactoring a preference.

[Bnyro]

Looks pretty good and well overthought from the UI/UX perspective, only left some recommendations for the code implementation, which would make things a bit cleaner overall 👍

Thank you for looking into this!

[M00NJ]

Awsome!
Since the player screen design ideas where well recieved I wanted to look at some other screens in the app and propose improvements. This was one of the ideas to make the subscription tab ui a bit cleaner. Cool that it's already implemented :)

[RafaelsRamos]

Awsome! Since the player screen design ideas where well recieved I wanted to look at some other screens in the app and propose improvements. This was one of the ideas to make the subscription tab ui a bit cleaner. Cool that it's already implemented :)

That's on @SameenAhnaf , he's the one that proposed that UI 💪

[RafaelsRamos]

Looks pretty good and well overthought from the UI/UX perspective, only left some recommendations for the code implementation, which would make things a bit cleaner overall 👍

Thank you for looking into this!

Thank you for the review Bnyro!

I hope I have not forgotten any of the changes we discussed 😊

[Bnyro]

The above suggestions (except the SVG thing) are only a small refactor to avoid crashes when the bottom sheet is being recreated, since the var sortOptions = ... value won't be kept either when the sheet is killed. Hence we must pass it as an intent data argument in order to not become killed by Android lifecycle.

[RafaelsRamos]

Hey Bnyro, thank you for catching this issue. It would lead to some unnecessary crashes...

Updated the icon's formatting + passed the parameters through arguments.

One point to note. I was not able to use the recommended arguments.parcelable(...) due to the fact that the argument being passed is a collection of items. For that reason, I used the arguments.getParcelableArray, I hope that's OK.

[Bnyro]

One point to note. I was not able to use the recommended arguments.parcelable(...) due to the fact that the argument being passed is a collection of items. For that reason, I used the arguments.getParcelableArray, I hope that's OK.

Sure 👍

I didn't test the code at all before commenting, it was just more of a general hint how I'd imagine the changes to be :)

[Bnyro]

Lgtm now, thank you!

Would you mind rebasing squashing your commits into two or three so that we can make the history of commits cleaner. Or should I just squash the whole PR into one commit when merging?

[RafaelsRamos]

Yeah go ahead! I just like committing multiple times to keep track of what was done (it helps me with the PR description).