I've made a project based completely on xibs. Now I need to add a table view whose cells will lead into the xibs I have in my project. All of the tutorials I've found for table view use storyboard, so I was wondering, how I would go about building the table view in storyboard in my current project and then having the detail view be my xibs? If that's not possible, would I have to start a new project that uses storyboard and then add all my xibs into the project? Finally, I think the easiest solution is to make a table view using xibs, not storyboard. Is this possible and if so, how do I do it?
Please let me know if my question is unclear or if you need my information. The last question I posted was left unanswered because I didn't ask correctly and I still have no idea why...so I don't want that to happen again.
The help is much appreciated. Thanks
You can add storyboards into a mainly xib based project but as you said using UITableView with xibs is what you would prefer and yes, you can do this.
If you go to File > New File > Objective-C Class > subclass UITableViewController. Tell it to make you a xib. This will implement UITableViewDelegate and UITableViewDataSource for you. Then you just need to provide it the necessary methods and it should work from there.
Here is a good tutorial that may help you: http://www.icodeblog.com/2009/05/24/custom-uitableviewcell-using-interface-builder/ (some of this is not relevant if you subclass UITableViewController because it will automatically establish the Delegate and DataSource properties).
Also, feel free to ask any questions if something does not make sense. I am a bit unsure as to what you are after exactly so my answer may not be perfect.
Related
I have a project which is based on storyboard. The problem is some views are repeated in some view controllers.
I created xib file for these repeated views and then I use don't create theses view again. I just add a uiview and set its class to the custom view I have created.
It work ok as it avoids repeated view changes.
But I don't know if this cause performance or any other problems later.
And I cannot change the whole project to only use with xib files.
one of the clean code goals is to reuse your code. so base on this, xib file is a good solution, but about performance, using interface builder has less performance than implementation through code. if you are concern too much about performance, use the code, if not, your implementation is ok.
If your project has similar kind of design or view then yes using xib with storyboard is good. you can reduce redundancy by taking similar kind of view or Tableview cell or collectionview cell. that will also make your storyboard neat and clean.
you can check this and based on that you can use as per your requirement.
Which is more efficient way? StoryBoard or XIB?
Does anyone know if we can design our custom UIViews in Xamarin's storyboards ? I would like to use autolayout and size classes for a custom View that I need to develop. I am not much comfortable with Xcode, having been so attached to Xamarin's IB. So I would prefer to design it in Xamarin storyboards than going for XIB files. I know we can prototype UITableViewCells in storyboards, but that is not what I want. I want a standalone custom UIView, with a code-behind class that I can re-use.
I am a bit confused as to what you are asking.
Are you wanting to design XIBs in the Xamarin Designer?
Currently, it is not possible as storyboard's XML and XIB's XML are completely different. But it looks like Xamarin is thinking about supporting it as it is on UserVoice here. So you could vote for it and hope it gets added in.
Another option is to start using Xcode.
I have found out a way. But it is kind of a hack and will increase bundle size and thus a memory-inefficient way. First add a View Controller to the storyboard and give a class name to create a code behind, say "DummyViewController". Then drag a UIView to DummyViewController and in "properties" pane give "class" name as the name of the Custom View as shown in the image.
A code behind for this View will be created in project folder, MyCustomView inheriting from UIView. Now we can design the view from within XS storyboard with AutoLayout and Size Classes without a separate XIB file.
I do not recommend this unless you really want it to be done this way. Hope Xamarin will come up with a solution to design Custom Views from within XS soon.
Assume you do not want to use storyboards and instead programmatically create your viewControllers / views and autolayout them by code also. How do you properly make use of topLayoutGuide and bottomLayoutGuide? They are properties of the viewController.
I might be wrong, but I think the proper place to set constraints for autolayout are the relevant views and they usually are not supposed to have references to their viewControllers (again afaik).
Am I mistaken and the coding of constraints should be done in the viewController or if not, how do you get the information down to the views?
Please be patient I am learning ;-)
All of our views are in a single storyboard. After we edit the interfaces we are responsible for, we find it is a disaster when we commit the storyboard. Do any better ways exist that make it easier to manage the storyBoard? Should we write UI with code instead of storyboard or xib? While it is really efficient to use storyboard.
What's generally worked for me and my team is to separate related functionality into different storyboards. So if one person is working on x portion of the app, stick all things x related there. As long as only one person is dealing with each component at a time, there's no chance for conflicts that blow up your whole storyboard.
Another thing to keep in mind if you can only use one storyboard, is to limit who can work on each ViewController in the storyboard. It's not the best idea to have multiple people working on the same controller anyways, since you will both be interfering with each others layout. I have found that as long as we stick to our own components, merges are super easy.
Your solution of using code instead of storyboard is also a very valid way to go about it. The decision between code and xib based approaches depends on the user. Code takes longer to get going, but is super easy to reuse, whereas xibs/storyboards make prototyping a snap but are very hard to reuse.
You need to read this links:
http://blog.waynehartman.com/archive/2012/01/07/uistoryboard-on-ios-5-the-good-the-bad-and-the.aspx
http://www.linkedin.com/groups/Which-is-better-StoryBoard-NIB-162305.S.185584395
Should I use storyboard and mercurial for team work?
Storyboard is one single file, so only one person can work on the storyboard at once. It is essential factor for working with team in iOS.
The following post helped me to understand answer on this question:
http://robsprogramknowledge.blogspot.pt/2012/01/uistoryboard-best-practices.html
I'm trying to develop a universal iOS app and ideally I'm trying to get as much code re-use as possible.
I'm using storyboards so the UI is segmented into scenes.
In the iPhone storyboard the particular scene in question is best suited to a table view.
In the iPad storyboard, the equivalent scene in the storyboard would ideally implement a UICollectionView and so render the content in a grid.
Both views should implement a pull-to-refresh control which in one case is going to call a [UITableView reloadData] and in the other a [UICollectionView reloadData].
Anybody any advice on how to get the maximum amount of code re-use, ie. what does the controller class look like?
1 option would be to have 1 monolithic class that conforms to both the UITableView protocols and the UICollectionView protocols but this doesn't feel right.
Another option would be to have a base class and then subclass it with specialisations for iPhone and iPad. Whilst this feels cleaner, I'm still thinking there might be a better way. In my first attempt at this it felt like there was more code in the specialisation classes than there was in the base class.
The third plan I've considered is simply to use a UICollectionView in both apps therefore eliminating the complexity of the controller. Hopefully I could force the layout of the collection view to be a grid on the iPad whilst tell it to mimic a table view on the iPhone.
Whilst on the face of it this sounds easy I'm struggling to make a UICollectionView work exactly like a table view would do normally.
Any advice guys?
Many thanks,
CA.
If you are not using some of the specific UITableView features[1], making UICollectionView look exactly like a table is trivial. I think I would go for using UICollectionView as it will allow more flexibility in the future and you will have to use it anyways.
When you are talking about code reuse you probably mean the DRY principle. It just says you should not write the same code or the same information twice, but I don't think this is your main issue here.
I would use a UITableViewController on the iPhone and a UICollectionViewController on the iPad. I think this is the cleanest and easiest way to go. What exactly do you hope to reuse among both controllers? The both require two different delegate protocols, so most of the methods will be specific to one platform. You will need two NSFetchedResultsController if you're using Core Data, but reusing the fetched results controller code only makes sense if you need the same data on both platforms.
If you create a new universal project in Xcode you will get a basic project setup that looks different on iPhone and iPad. Try to understand it (there are some details to pay attention to) before you start programming, I think it will answer at least some of your questions.