Can anyone tell me if this is a standard iOS controller; I see it often in many different apps. It behaves much like a segmented controller, in that you can select one option and that option "sticks" until you select another. But it also seems a bit different than the out-of-box segmented controller. Is it something else?
I've done a few of those with a row of simple UIButton instances
Related
I'm trying to create something similar to the following:
You see the dates at the top just underneath the search bar? Is that a nested tab view as I'm guessing? Is there a way to do it with the default components or do I need to create a custom view?
I'm not looking for a coding answer per se. I just want to know if there's a standard way of achieving this before trying to implement my own solution.
EDIT:
For future reference I found a library that does exactly this.
Apple's documentation states :
The tab bar interface displays tabs at the bottom of the window for selecting between the different modes and for displaying the views for that mode. This class is generally used as-is, but may also be subclassed.
https://developer.apple.com/documentation/uikit/uitabbarcontroller
So I would guess that it is a custom solution.
I know how to use tabBarController.
But I dont Know How to Create A Tabbed Page Like The Attached Image.
Whats The Name Of This Type Of Tab?
This is not any type of Tab. You can use a collectionView or a stackView for "Tabs" and a UIPageViewController for changing viewControllers.
You can check CocoaControls for similar controls, download source code and check their construction. You can possible do it with SegmentedControls (Or Custom UIViews for single Tab and draw in ScrollView) and UIScrollView as Content View (with Pagination On) as well, but it depends how much customisation is needed.
Trust me, it's REALLY tricky to obtain what you want with the iOS components. There are a lot of details that you will miss.
When I tried myself to build the same thing, it was like "ok I think I am reinventing the wheel, is not straight forward as I though, it require a lot of work"
You know you have to consider a lot of stuff like an User that start to scroll as a crazy between the pages and then tap on one tab bar button, and so on. Trust me, it's easy to have a working implementation, but it's really really difficult to obtain a PERFECT implementation
I decided to go for a library
https://github.com/aokizen/SPSlideTabBarController
https://github.com/xmartlabs/XLPagerTabStrip
but there are others that are all good to achieve what you want
Anyway if you want to go for your personal implementation I suggest a Segmented Control in the upper side and a PageViewController (maybe inside a Container View)
I'm making a UITableView that is going to act as a settings view controller. Obviously its going to have a few types of input. One cell might have a slider, one might drill down to another view controller, one with a textbox etc. Is there any way to avoid making umpteen different subclasses for UITableViewCell?
Try this github project: QuickDialog.
I'd like a new row of tabs just below the existing row. Is this possible in xcode?
I suppose it's possible but sounds like a really bad design choice. I would either use a "More..." tab in your tab bar or a UISegmentedControl.
You can't do it with the standard UITabBar. You would have to build your own solution with UIViews. I agree with Keller, its a bad design idea - I think it would use up too much screen space. Perhaps have a Table View with all the tabs as rows and drill down into your views instead?
More of a "best practice" question with regards to good application design. I have an application that has a number of popover controllers, each with different content. My first instinct was to create a new TableViewController for the content of each popover.
Is this the best way to go about things? I was wondering if it was possible or more tidy to handle the display of all this content within one TableViewController, and present different arrays of content depending on the popover?
Thanks
Unless your delegate/data source code is very similar between all tables I would recommend keeping the classes apart. It will make your code more modifiable in the future if you want to sub-split out one of these views or add additional popovers.