feat(YouTube - Settings): Add ability to search in settings

[MarcaDian]

Adds search feature to YouTube ReVanced settings.

[oSumAtrIX]

Regarding

Implement search in external SB and RYD fragments (or rewrite them)

A rewrite to implement it via the preferences framework would be ideal. It would restore consistency with other preferences and also allow searching. May be out of scope of this PR, but would be welcome in it as well.

[oSumAtrIX]

@LisoUseInAIKyrios Do you think if a fuzzy search would be possible? Casing, spacing and co is something many would have to trial and error for probably.

[oSumAtrIX]

Maybe also strip spaces? "sponsorblock" and "sponsor block" would match.

[oSumAtrIX]

Or things like ', " etc. Lowercase alphabet would be ideal probably. @LisoUseInAIKyrios what do you say?

[LisoUseInAIKyrios]

With the exception of "SponsorBlock" and "Sponsor Block", I don't think the preference text has any ambiguos spacing or punctuation that would affect searching. Even if searching for "sponsor block", the SponsorBlock settings will show before they get to "block". Using a combination of individual word searches (if little to no results exist) I mentioned would also fix this since "sponsor block" would show the combined search of each word "sponsor" and "block".

Since the results show up as the user is typing, I think they may stop when the result they want is shown.

[oSumAtrIX]

I don't think the preference text has any ambiguos spacing

That's just an assumption. There's no benefit in including spaces in search. It's only beneficial for the statistics to omit them from the search as it's more unlikely to be useful in search than not useful

[oSumAtrIX]

@LisoUseInAIKyrios Searching should be possible via the base implementation of the settings patch, so when we add the patch to other apps, its there as well. Isn't this implemented in the wrong place?

[LisoUseInAIKyrios]

The only simple solution is to make a self sorting preference list, but there's nuances to that since for this use case the first list element should always be first (so 'default' or 'disabled' is always first).

The biggest headache of doing that is the way preferences are programmatically created during patching, then serialized to xml, then de-serialized during runtime. Because of the xml serialization it makes adding extra custom parameters very difficult or overly complex (such as do not sort the first N preference list elements).

The best solution is to not do the xml serialization/deserialization and instead create all preferences at runtime, similar to how ReVanced TikTok does it. Then all kinds of extra data and behavior could easily be added to the preference objects and not what RV YouTube does with clunky static methods modifying stock Android Preferences.

Making that change is way outside the scope of this PR and would be a lot of work to accomplish, but it would both simplify things and open up a lot of use cases that are difficult or almost impossible to do right now.

[oSumAtrIX]

This PR would break compilation on the attempt to separate the shared patches to their own extension as the youtube unspecific patch references youtube specific settings. For that the code needs to be restructured

[LisoUseInAIKyrios]

Regarding

Implement search in external SB and RYD fragments (or rewrite them)

A rewrite to implement it via the preferences framework would be ideal. It would restore consistency with other preferences and also allow searching. May be out of scope of this PR, but would be welcome in it as well.

Doing it for RYD would be fairly simple since it doesn't have any custom behavior except the API stats (but those could be handled using a custom preference that hides itself if debug is off).

But converting all of SB would be way more substantial, since it has a lot of custom code to validate/fix user input, show custom colors/segments, user stats, and more.

[LisoUseInAIKyrios]

@LisoUseInAIKyrios Do you think if a fuzzy search would be possible? Casing, spacing and co is something many would have to trial and error for probably.

Fuzzy search would be ideal, but obviously adds complexity.

Other fuzzy search ideas are if multiple words are searched for, and the search results are few (less than maybe 10), then show the combined search results of each word individually (and stop combining sub searches when 10+ results exist).
 

But fuzzy doesn't handle if a user searches for a different wording of a preference. Preferences could declare related words that are silently searched against. So SponsorBlock could declare [ "sponsor block", "sponsors", etc ]

Another example is disable resuming Shorts (Preference summary is: Disable resuming Shorts player, Shorts player will not resume on app startup) could declare related words such as ["resume", "launch", "open"].

[oSumAtrIX]

But fuzzy doesn't handle if a user searches for a different wording of a preference.

That's correct behavior. Fuzzy aids the user and prevents light spelling mistakes. It doesn't make attempts to guess what the user might search. The guess approach doesn't look ideal. It won't be useful in most or make weak guesses at what the user might or might not type. Fuzzy search is sufficient on the other hand. I don't think it adds any complexity other than a library for fuzzy searching

[oSumAtrIX]

But converting all of SB would be way more substantial, since it has a lot of custom code to validate/fix user input, show custom colors/segments, user stats, and more.

If inputs needs validation a custom input component can be made. Similarly the color and popup ones. Or those can be removed and they can consistently use the same input preferences as other preferences. Consistency is more important here which would also solve side effects as seen in this PR

[LisoUseInAIKyrios]

I cannot reproduce either of the issues. Locking/unlocking works, and I no longer can reproduce the SB unresponsive settings.

Are you sure you're on the latest commit? I forced pushed, so you'll need to force reset if you're on a divergent branch.

[MarcaDian]

Maybe related to the fragment lifecycle (onPause, onResume)?

[LisoUseInAIKyrios]

What if SponsorBlock is not included during patching? Is the lock/unlock issue fixed?

[LisoUseInAIKyrios]

The issue only shows up when locking/unlocking?

I think it's caused by onStart() being called more than once.

[MarcaDian]

Also, when use a gesture to go to the desktop and return to the app. If do this with other words in the search, the search will be empty.

[LisoUseInAIKyrios]

Since the preference key is searched, it might be worth reviewing the existing setting keys and adjusting the key names if any could cause false positive/negative search results.

[MarcaDian]

I think it would be appropriate to also implement the android:dependency and app:searchDependency keys to improve the search results, for example, if the parent setting disables the child, then it should not be shown in the search, or the parent setting should be shown next to it.

[LisoUseInAIKyrios]

The built in dependency declaration is very simple and doesn't allow the more complicated dependencies of the ReVanced settings (such as turning on either swipe volume or swipe brightness enables the same sub settings).

But this functionality could be done using the existing setting availability function.

[MarcaDian]

I still have the problem with locking/unlocking

The problem was solved. Thanks for the good work =)

[MarcaDian]

Until the SB settings is completed, the search by its categories is not yet working.

[LisoUseInAIKyrios]

edit: SponsorBlock category settings now show in the search results.

Overhauling the last of the SB settings will be a decent amount of work. I think for now what's here is ok.

[MarcaDian]

changerColor can be moved to shared utils or to ThemeHelper for future using.

[MarcaDian]

I tried to implement to close the search field when pressing back, but it's difficult to do without the androidx.activity library.

[LisoUseInAIKyrios]

SponsorBlock is showing up with duplicates again. Needs a small adjustment to fix.