Support CupertinoSliverNavigationBar.search with condensed large title

[victorsanni]

search.animation.mov

Fixes Suggestion: CupertinoSliverNavigationBar allow forcing condensed title
Fixes Expose search field in CupertinoSliverNavigationBar.search

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
• I signed the CLA.
• I listed at least one issue that this PR fixes in the description above.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is test-exempt.
• I followed the breaking change policy and added Data Driven Fixes where supported.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[MitchellGoodwin]

Uploading Screen Recording 2024-11-19 at 10.49.22 AM.mov…

Looking at the settings app, the content will fade in and out during the search transition as well. To enable coordinating the two transitions, ideally they both would use the same animation controller. So I wonder if we should either: Make the animation controller of the sliver navbar public so it can be accessed, or accept an animation controller in the constructor so it can be passed down from the context around it? I think I'd lean towards the former option.

Also, are we planning to do something similar with the non-sliver navbar?

[MitchellGoodwin]

For the final version, we probably don't want to refer to it as onSearchFocused. Focused suggests it triggers when a keyboard navigates to it, which is probably not what we want. Maybe onSearchActive?

[victorsanni]

So I wonder if we should either: Make the animation controller of the sliver navbar public so it can be accessed, or accept an animation controller in the constructor so it can be passed down from the context around it? I think I'd lean towards the former option.

Thinking the former as well. This implementation also replaces the initial search field with a new interactive one. I'm thinking we also add that as a property? Maybe activeSearchField? It will be confusing though because a user might customize it expecting the initial search field to be customized as well. Or should I figure out a way to make it always use the same search field?

Also, are we planning to do something similar with the non-sliver navbar?

I doubt it. Since in the non-sliver version we don't provide a .search affordance. The user has unrestricted control on what the bottom widget should be, and the ability to change the nav bar as required to match it.