feat(card-browser): delegate Menu to SearchBar

[david-allison]

This is a no-op in PROD, and will work in dev once CardBrowser is updated to use MenuProvider

The current implementation was designed to produce the intended effect with minimal modification to the activity and Fragment.

An alternate would be to define activity.menuHost via an interface, but I deemed this to be unintuitive: NoteEditorActivity would need to implement it for no current reason.

Fixes

• Part of Card Browser: Migrate to Material 3 SearchView #18709

Approach

• Enable MenuHost delegation in CardBrowser
• Use MenuHostHelper to delegate to the Menu of the SearchBar
• Define an interface with a default implementation so CardBrowserFragment stays lean

How Has This Been Tested?

Right now, this is effectively a no-op, I have a (messy) branch which has converted the Card Browser to use MenuProvider and this works as expected.

Tested briefly on a tablet emulator, in both legacy and SearchView implementations of the Card Browser

Learning (optional, can help others)

super.onCreate on an activity adds MenuProviders, therefore delegation is more complicated than expected

onDestroy invalidates a MenuHost, but a fragment may no longer be attached to a context at this point

Using the incorrect MenuInflater means showIfRoom has no effect

MenuProvider/MenuHost

https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:core/core/src/main/java/androidx/core/view/MenuHost.java?q=MenuHost

https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:core/core/src/main/java/androidx/core/view/MenuHostHelper.java?q=MenuHost

Checklist

Please, go through these checks before submitting the PR.

• You have a descriptive commit message with a short title (first line, max 50 chars).
• You have commented your code, particularly in hard-to-understand areas
• You have performed a self-review of your own code
• UI changes: include screenshots of all affected screens (in particular showing any new or changed strings)
• UI Changes: You have tested your change using the Google Accessibility Scanner

[BrayanDSO]

Everything is okay, although it's hard to imagine how the integration is going to look like

[lukstbit]

LGTM

This is performed in the base class so CardBrowser appears 'lean' and free from low-level concerns

Ok, but do you see other activities using this(now or in the near future)? If not, moving code that is tied to CardBrowser into the super class doesn't feel right(and the implementation could have been simpler).

[david-allison]

@lukstbit moved to CardBrowser, strongly open to simplification if anything is proposed

[lukstbit]

This is fine. The simplification I was referring to was not using the super class.