Closed aerych closed 8 years ago
I took a stab at this yesterday afternoon and there were some issues switching to UISearchController which make me rethink this.
I think the work to resolve the above issues would make switching to UISearchController a zero-sum effort and am inclined to keep WPSearchController around.
Thoughts?
On the iPad, the search bar wants to be full width of its super view. Any constraints added are either broken or ignored.
I've tried setting width to searchWrapperView
's frame instead. It seems to work (more or less), the search bar filled up the wrapper view properly.
As a side note, I've noticed a couple of Remove this line when switching to UISearchController.
comments around the code that might be hard for others to find.
I took a new stab with this one after working on https://github.com/wordpress-mobile/WordPress-iOS/pull/5574 last week and also ran into a set of issues. It seems UISearchController
really wants to manage itself and how it's displayed. Particularly, UISearchController
seems best suited as a typical UITableView.tableHeaderView
.
I agree with @aerych's earlier comments of sticking with our current WPSearchController
which allows a nice mirror to the protocols of UISearchController
, also allowing our own use of the searchBar.
However, it might be best to ditch our current UX of the searchBar within navigation altogether and instead implement UISearchController
as a UITableView.tableHeaderView
, which is a bit more intended for UISearchBar
+ UITableView
.
Fwiw, UISearchContainerViewController solves many of the challenges we're having switching to UISearchController. However, its a 9.1 API and we're currently supporting 9.0.
Fwiw, UISearchContainerViewController solves many of the challenges we're having switching to UISearchController. However, its a 9.1 API and we're currently supporting 9.0.
I guess we could do this?
if #available(iOS 9, OSX 10.10, *) {
// Use iOS 9 APIs on iOS, and use OS X v10.10 APIs on OS X
} else {
// Fall back to earlier iOS and OS X APIs
}
I guess we could do this?
We'll probably be able to get away with just UISearchController
if we end up putting all the search bars as tableHeaderView
s.
I'll probably be able to get away with just UISearchController
Maybe. I'm skeptical but it could be worth trying. Its just makes so many assumptions about how it should be presented.
I guess we could do this?
We could, but it kinda makes me want to gag. ;) If it would add much complexity I'd vote no.
Its just makes so many assumptions about how it should be presented.
Yeah, that scares me. Go back to managing our own search bar?
Yeah, that scares me. Go back to managing our own search bar?
Maybe just until we're supporting 9.1 and later?
Adding this one to the list for the iPad refresh (#5576), since we'll need to ensure 100% compatibility on iPad anyways.
Maybe just until we're supporting 9.1 and later?
I'll give all three implementations a shot and see what's worth what.
I think we should just wait until we officially support 9.1. The branching above always scares me and we were bit hard by this during the iOS 6 to 7 transition. That being said we'll probably go to 9.1 with version 6.4 ;).
I've picked this back up, and I've finally got it working. Current progress:
Current progress is in feature/uisearchcontroller
.
After dropping iOS 7 we should be using UISearchController instead of the WPSearchController stand-in. Make the relevant changes and delete WPSearchController.