I was wondering if it was possible to have a search bar and search display controller without having a table view on the same view. If this is possible, I would really appreciate it if you would please respond.
It works just fine without a table view. The UISearchDisplayController instance needs a searchResultsDatasource and delegate, which are really UITableView datasource and delegate.
Since these implementations are present in UITableViews, they are often reused as the implementations for the search controller, but that needn't be the case.
Related
How do you add a search bar to a collection view controller in iOS 12? I realize this should be a simple question but I'm having difficulty finding an example that doesn't look half-baked.
This can either be just using a search bar or a search controller. I don't know what the best approach should be in iOS 12. I would also like to do this programmatically.
Use a UISearchController. Put the collection view controller into a navigation controller and set the searchController of its navigationItem. Now the search bar will appear in the navigation bar. You can configure things so that the search bar appears only when the user scrolls the collection view all the way down; that is effectively the same as making the search bar be at the top of the collection view. This is a nice interface and is what Apple expects you to use.
I am a bit confused, it is a very strange thing to put the UISearchBar in the UICollectionView. Because the UICollectionView the display uses the UICollectionViewCell, each UICollectionViewCell can be reused.
So I guess you are not going to put in the UICollectionView, but search the results through the SearchBar, using the UICollectionView to display the results.
Sorry, my network can't upload images. The layout is probably UISearchBar and UICollectionView in UIViewController.
- UIViewController
- UISearchBar
- UICollectionView
In the UISearchBarDelegate proxy method, the network request can be executed when the search is triggered, and the data returned by the network request is refreshed on the list.
If you are not very demanding on the layout of the list, you can use UITableView, UICollectionView needs to set UICollectionViewLayout to be slightly more complicated.
In code huh? Using storyboards all you need to do is add the search bar and connect it to an IBAction outlet. When it changes you pass the value to a predicate and reload your collection. Delegate and other Mac Search bar options can be set in code or right in the storyboard. Sorry I couldn't fully bake it for you!
So I'm really new to iPhone development and this is what I want to achieve. I want a search bar that uses a REST api that I've written to get back data and populate a table view.
In terms of what I've attempted - I'm not sure where to start, so I'll just post some thoughts.
What I've done is created three views - a root view, a search view and a results view. The root view should have a UISearchBarDelegate, an UITableView DataSource and an UITableViewDelegate because there needs to be a controller that can execute the search and populate the table.
However I'm not sure if this is the right approach, or even where to go next after this.
I know I should probably try more code, but I'm just really not sure where to start because this is an architecture thing - I'm not sure where the data will be passed between search and results(I think this should be in the root view) and how that root view will know when the search is done.
Thanks
You can do this all in one ViewController. Make it a delegate to the UITableView and the UISearchBar, as well as the DataSource for the tableview. Put the searchbar in a UINavigationBar along with a button with the text "Search". When the button is pressed take the text in the search, send it to your REST api, then set the data as the DataSource. Then just call [tableView reloadData] and the view will refresh with your updated data.
I am using ECSlidingViewController, a library that gives a side-drawer effect. My application opens to a (navigation controller holding a) table view controller of 'Nearby' results, and the cells segue to a scroll view controller.
The hidden left menu is a table view controller (of different class) with a few options, 2 of which are other table view controllers that will use the same layout, cell prototypes, and detail scroll view as the table view seen on startup.
I would like to know if it would be better design to make a more generic tableView with some sort of property like an enum'd typeOfDisplay, which lets me conditionally manage different nuances like populating cells from server/CoreData, navbar titles, sort order, toggling auto-updating, editability, etc. - OR - if I should make a NavigationController->TableViewController->ScrollViewController for each different view controller (A 'Nearby', 'Featured', and 'Saved')
I'd like to reuse my table view because the cells/display/detail will be identical, but the methods for populating the table are different, and I don't want to make something that's difficult to modify.
Edits -
If you are familiar with table views inside tab-bar contollers, the implementation details should be nearly the same.
It's better to put view configuration into view controller. But there can be ways to reuse the configuration actions.
I have ran into the same situation like yours. And I decided to use Strategy Pattern to refactor my controllers. I put all the data related stuff into a TableDataManager class which conforms to the UITableViewDataSource and UITableViewDelegate protocols and I applied polymorphism to it to configure the data in cells and the appearance of the UITableView under different circumstances at runtime.
All the identical actions are implemented in TableDataManager, and nuances are overridden by subclasses of TableDataManager. By assigning a proper subclass of TableDataManager to a view controller, there is no need for you to copy and paste the identical cells/display/detail actions here and there.
That's my experiences. Hope it will help.
I would recommend you to use different view controllers for different datasources. It sounds good initially to put them all together in one place, but as time goes by, you may need to add different functionalities to each table view, and your view controller will be a horrible mess.
There is something that bothers me about this concept of having table view controllers in a page view controller.
Yet, the customer wants separate pages with a table view in each page. It even makes sense in this case. However, I have not come across this before and something bothers me about it.
By the way, each row of a table will take a person to a detail view controller where the data can be edited.
I think if gesture recognizers are used that allow page transitions to happen via tapping or flicking, that could get in the way of the table rows.
I am going to check it out. However, my time is limited and I will have to bail quickly if this does not work out.
Anyone see gotchas on this and I should come up with another approach now? :)
update: Another approach could be a navigation controller containing tableview controllers.
For the basic case, there is no reason a PageViewController cannot contain a TableViewController
I'm trying to figure out the best approach to take in my current situation.
I have an app with a navigation bar controller that at one point needs to present/show x number of table views.(x meaning that the number is decided by communicating with a server)... The table views will each represent e.g a class or a group... (this could be school classes or kindergarden classes)
Okay... So... Only one table view should be visible/in focus, but the others should be accessible from the same view...
E.g. The view is presented. A table view for class A is shown. The user can swipe to get class B
I've been considering different approaches, but I can't figure out the best approach to this...
I considered using a scroll view containing the x table views, where only one was visible at a time, and the others could be scrolled in view... But, after doing some research, it seems that Apple recommends that you shouldn't place table views in scroll views, because the scrolling can interfere with each other..
Using a tab bar... Again, my research told me that the navigation bar should be placed in the tab bar, and not the other way around... And I only want a tab bar on this view, and not earlier in the app..
Use a custom tab bar that better supports my "needs"...
Any ideas??
In my opinion the most important thing is that only one UITableView have to be visible. The best solution (ie the simplest) is a first UITableView with its UITableviewController that lists all the classes/categories A,B,.. retrieved from the server, and a secondary UITableView (ie controller /+ tableView) that will display the detailed list for a given class of items. You may also continue to drill down your data tree other sub-tableViews.
I recommend to use a UINavigationController to push/pop your tableViews when a cell is selected.
Stacking several UITableViews in a unique container view seems too much complicated and may lead to tricky and/or unwanted states.