I am writing a text editing app. I target iOS 6 and 7, and use storyboards and autolayout.
I thought this layout for the welcome screen would work well:
<Files in a table view>
<Instructions to user>
<Settings>
The settings view is pretty complex, and will probably benefit from having its own view controller. The instructions view is static, and has no logic.
I can think of three ways to organize this:
Create this as a table with three sections, where the 1st section is the list of files, and the 2nd and 3rd section are big, custom cells with.
Wrap all three views in a scrollview
Wrap the instructions and settings in a scrollview
I prefer the first solution, as it seems to be the, most natural way for the user to navigate, but I haven't seen any examples of adding a viewcontroller as a cell for a tableview anywhere, and haven't been able to google me any. Prototype cells do not seem like the right way to go for the settings view/controller either.
Best practice, suggestions, input?
Apple recommends only one view controller per "screen," so that rules out option 1. I wouldn't want to even start to attempt to embed a viewcontroller in a table cell and that just smells very wrong in any case.
You have three independent views that you want to scroll, and that clearly calls for a UIScrollView. As for the best way to organize this, I recommend creating modular UIView subclasses: one for the table, one for the instructions, one for the settings. See my answer on this question as to how you can package up views as reusable (not important in your case) and modular widgets: UIView and initWithFrame and a NIB file. How can i get the NIB file loaded?. Then you can create delegate interfaces for each one, and set your main view controller to implement them in order to communicate with each of the three "widgets."
Related
I have a lot of common logic, therefore all my viewControllers inherit from BaseViewController, BaseDetailsViewController or BaseWebViewController. The last two inherit from BaseViewController which inherits from UIViewController. The problem is I cannot use tableViews with static cells because my BaseDetailsViewController is not inheriting from UITableViewController.
I'v never used and inherited UITableViewController because the same could be achieved by inheriting from UIViewController, wiring it with an added UITableView and having implemented datasource and delegate methods. Therefore for the form type screens (SignUp or other data input screens), I use my own BaseDetailsViewController which adds nice and handy methods (input validation, custom styling, scrolling keyboard, handles input field navigation and etc.)
Using UITableViewController has two real benefits: 1) keyboard scrolling (if you use text fields) and 2) easy creation of your form UI elements inside on screen. The first benefit is irrelevant for me, because I'v already have my own implementation of this stuff inside BaseDetailsViewController. Regarding the second benefit, I'm creating my form inside scrollView which gives a lot of flexibility but it's a little bit more effort (especially when need to update the screen). Therefore I heard some guys implemented their own UITableViewController and then made it to inherit from their BaseViewController. Therefore I started to dig into this approach.
So far I'v came upon these two approaches:
Recreate your own tableVC. Not clear how to make it work for static cells. Currently my demo app crashes if my ReplaceTableViewController is not implementing numberOfRows and cellForRow, and not shows static cells if I implement them with dummy content.
method-swizzling. Not clear how to change class inheritance by injecting baseViewController inheritance for UITableViewController, thought still not clear which methods are needed to be added.
Anybody tried and want to share?
UPDATE I'm not using storyboards as I promote clean MVC - every screen as component should have its own Model, View (Xib), and controller, all stored in separate files to eliminate merge conflicts of multiple devs in large app projects (30+ screens). And therefore container view with embedded segue to tableViewController is also not an option.
UPDATE2 In case anybody would like to take a look why and how I'm doing this, here's a link to my open source template based new project generator framework which I started to publish recently.
Static cells need a UITableViewController. You can't changed this right now.
But to use static cells in a UITableView outside of a UITableViewController you can use a ContainerView in your Non-Table-UIViewController, where you place a real, separate created UITableViewController working with those static cells.
To share common code between multiple view controllers, inheritance is not that best solution as you found out by yourself while subclassing UIViewController vs. UITableViewController. You can use some sort of composition for sharing code or - especially for objective-c - categories.
Categories are not allowed to have its own properties, but there are workarounds possible with objc_setAssociatedObject.
Another approach would be to not use static cells, but dynamic cells in a UITableView with DataSource-Delegate :)
As you see in my screenshot, to reuse a special TableView with static cells, i place it in other ViewControllers in a ContainerView. Since you are not using storyboards, i am pretty sure that this can also be done by code without storyboard.
Is Multiple Storyboard in single project is better than single storyboard??if yes then why??
Which is better Single Storyboard or Multiple Storyboard??
Any one please clear me the above queries.
It depends on the project requirement. If you are good enough with the size classes and auto-layout and also if the requirement flow is almost similar for all the devices then go with single storyboard.
By default in Xcode 6 or later, recommending to use single storyBoard.
If you have a bigger app and/or not only one man team:
You should NOT use single story board. Like its name says, it is a "STORY" board. You should have one Story in one Board. This keeps the readability and maintainability of the storyboard.
If you have a team, it is a nightmare to "merge" one single story board if 2 made changes in it at the same time. It is more or less impossible. But if you have for each story a corresponding storyboard, even in a scrum team you can manage to work on one storyboard only one person, that you do not need merging.
There are a lot usefull documents and workshops in internet if you google "ios storyboard git merge ...."
When to Use Storyboards
Finally, while Storyboards are best used for scenarios involving multiple view controllers, it’s also defensible to use a Storyboard when working with a single table view controller for three reasons:
The ability to design table cell prototypes in-place helps keep the pieces together.
Multiple cell templates can be designed inside the parent table view controller.
It’s possible to create static table views (a long awaited addition that’s unfortunately only available in Storyboards).
When Not to Use iOS Storyboards
A few cases:
The view has a complicated or dynamic layout, best-implemented with code.
The view is already implemented with NIBs or code.
When to Use NIBs for iOS UI Design
A subset of all uses cases would be:
Modal views
Simple login and registration views
Settings
Popup windows
Reusable view templates
Reusable table cell templates
Meanwhile…
When Not to Use NIBs
You should avoid using NIBs for:
Views with dynamic content, where the layout changes significantly depending on content.
Views that by nature are not easily designable in the Interface Builder.
View controllers with complicated transitions that could be simplified with Storyboarding.
Apple's docs say that you may have multiple storyboards. Unfortunately they don't go into any real detail on how to do that. As you've found out, Interface Builder won't help you, so you'll have to do it in code. It works much like loading XIBs:
[UIStoryboard storyboardWithName:#”MyNewStoryboard” bundle:myBundle]
Having said that, if you don't "want one big/bloated storyboard" as then XIBs really are the way to go. That 'bigness' is the benefit: all the transitions between VCs are laid out in one place. Having multiple storyboards is really so that you can support multiple different and unrelated flows through your app: for example, one storyboard for a complex configuration flow and another one for the main user flow.
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.
Often, when I'm making my apps, I'm in this situation : I have a UINavigationController, handling the view stack, some UIViewControllers, controlling their respective views...
But when I want to add several custom UIViews in my mainView, I don't know how to manage my code.
Each UIViewController needs to handle one and only one view (wich normally occupy all the screen size), and a view should not control their content (update it a the extrême limit).
You can't neither do this :
[myViewController1.view addSubview:childViewController.view];
So if I want to achieve something like this, what should I do ?
The orange parts have to be 3 instances of the same UIView(Controller?), but with a content depending of a NSObject (User, obviously).
I think this very important to segment your content, this should be an easy problem, but I found a lot of contradictory answers so, what's the best practice to handle this common issue?
Theses orange views should be instances of UIViewControllers in order for it to handle their UITableViewDatasource? Is addChildViewController relevant in this case?
I already found a lot of things which work, but I don't know what should I do...
Also, I'm using xibs.
Thanks in advance if you can help me (and other people I think).
You can do it either way (view or view controller) depending on how you want to handle things. Certainly, you can have one object be the data source for multiple tables, so in that case, you would just add multiple views. If, however, you want to keep your code more compartmentalized, then add view controllers, and have each control its own view -- to do this, you do need to use addChildViewController, and use the methods that Apple describes for creating custom container controllers. Alternatively, you can use container views in a storyboard which makes the process of creating custom container controllers simpler.
You're on the right path... Create separate instances of your subviews, and add them to your view. If you will have more than 3 (for instance, imagine coverview for your music, and you could scroll indefinitely left and right), I'd take a look at UICollectionViewController ... That will help manage cell re-use.
But, if it's just 3, just create three instances with different frames and add them to your view.
Here's how I'd do it:
each orange box will be a custom view (inherits from UIView)
the view will have the label, image and the tableview.
since you are not sure of the number of instances of these views you'd be using, its better to use some kind of tagging, so that you can have one place for the datasource and delegate methods of the tables in these orange views.
in the datasource and the delegate methods, you can make use of the tableView.tag (same as the orangeView.tag property).
I personally dislike having more than one viewController in a view (except the splitVC), probably because I haven't had a such requirement.
I dont see how a uiviewcontroller for orange box would help, over a uiview.
as #James Boutcher mentioned in his answer, UICollectionViews will simplify this issue further.
Why not creating a UIView class and overriding the drawRect method and then adding subView for this class in your myViewController1.view
I would like to know how to develop an IOS Table View Controller with multiple sections.
For example attached is a screenshot from DrawSomething account page. They have different headings like account settings, password, then some buttons below.
Would this be setup as one UITableViewController then setup image backgrounds for the headers and customized cells for each table cell, or would this be setup using multiple different view controllers all within one main view controller?
Further to this, could this be setup and designed using a NIB or would it be alot easier using code to generate this. I understand that it the choice of the developer and your opinion but in common practice if it is possible to design (as such) within the NIB it would be easier. Although designing a table view layout in NIB does not appear to be possible...
For something like this, since there's nothing really dynamic about the content, I would use a UIScrollView and just place the various elements on it directly.
Looks to me like each "section" of that table is actually a custom cell. The "heading" of the cell is just a label with textFields place in it etc...
Get a UIImageView to back the cells and you're good to go.
I've done stuff very similar to this using Interface Builder.
Make each cell use a different reuse Identifier so that when you load the table you know which cell is which.
You can create a table view with multiple sections. You need to create custom cells for headings and the contents.