I have a View Controller that displays 3 custom views. My question is, would it be better to create a XIB for each subview or not?
I have been told that loading a XIB file is really expensive, so it's better to have just one XIB for the View Controller and avoid having XIB for the custom views in that controller. However, in order to avoid that, I have seen the custom views' constraints set by code (as there is no XIB for them and no way to use the IB), which I don't like. That's why I'm wondering if it's fine (both a good practice and efficient) to create a XIB for each subview and set then set the constraints using the IB.
Thanks in advance.
Unless you are planning on destroying views with a large amount of components and rebuilding them serval times a second you should not notice any performance hit. If you do, cache them.
As for best practice (in my option) you don't use XIBs for the efficiency, you mainly use them because they are quicker to build and easier to understand if you need to revisit the view at a later date.
If your going to use AutoLayout in code anyway I would use XIBs where possible as you get the advantages above. The layout engine is usually the expensive part anyway.
Hope this helps.
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?
I am working on an e-commerce based app, and the designer has passed on the mockup to me. !
This is the mockup the designer has passed.
I am working on storyboard of this mockup and I have managed to get to this level as of now.
There are several views and features which cannot be included in this storyboard now because of the limited space. I know the designer has passed on me the rendered view, which can be seen on scrolling the app.
I wonder which could be the best approach to include all these views in a single storyboard or render them in a single view.
I have looked onto using xib files and calling them from my viewcontroller class, which could be a possible solution. But, I want to know, what could be the best solution?
Best solution is use Storyboard so that you have all screens at one place. But keep one thing in mind that start doing the whole project in XCODE 8 storyboard (Because XCODE 7 and 8 storyboards are not fully compatible with each other). So that you get compatibility with previous iOS versions also (< iOS 10)
Now as far as design is concerned, I would like to suggest you use autolayouts and proportional layout.
your View controller will always have self.view. Start on that view. First add navigation controller (with root view controller as your first prefered view controller on app start) or simply add one toolbar. Then add one UIScrollView to whole remaining space. Then start with your design inside UIScrollView. Don't forget to provide contentSize of UIScrollView.
For any help, feel free to ask.
The best solution would be using a tableView with multiple prototype cells for this kind of problem. Well, going through the concept as mentioned, I could easily scroll in the storyboard and maintain my design as per the mockup.
I have decided to create my UI programmatically as oppose to storyboards to avoid merge conflict nightmares and a few other things. However, I'm running to a few problems:
How would I do size classes?
My viewDidLoad methods are usually very large which reduces the readability of the code. Any suggestions or best practices?
1) Using size classes programmatically, Programmatically implementing two different layouts using size classes,
http://www.digistarters.com/swift-autolayout-and-size-classes-programmatically
2) Constraints may take a big place in your viewDidLoad method if you create all of this programmatically. I moved from fully-coded-UI to xibs and storyboards couple of years ago, and now my life much easier.
Also, when view controller becomes too long, you can try this methodology Viper.
I have to implement the layout of a single screen, which is not connected to the overall app flow, and I was wondering if it makes sense to use a Storyboard.
Storyboards make sense for flow/navigation (multiple controller), have some convenient features like, iirc prototype cells which are not available in xib. And it also makes sense if I think maybe later the screen may become a "story" (more view controllers). But none of this advantages are useful for my particular case.
I was thinking anyways in using Storyboard, as it seems to be a bit more flexible than xib generally, but is there any disadvantage? Maybe performance penalty or such? Is there a preferred way to setup single view controller?
Go ahead..take the advantages of using storyboard. There is no disadvantages or performance issues particular to storyboards when compared to xib files. Its all about your convenience. As you said the single view controller may become a story in future, then the storyboard would be a right decision. And when to use xib? thats upto you, one ideal situation where i will choose xib is, if i have an independent controller that i want to share with other project also then i would choose xib.
The performance penalty would only bother under the circumstance which too many controllers (more than 10) with segues were squeezed in one Storyboard. Everything would be totally fine before that.
And if you have more than two people are trying to edit same storyboard file than you have to resolve conflict, which will be more tedious job.
Storyboard benefits:
a. easy demo purpose and fast implementation.
b. small team like two person.
c. Storyboard is providing complete view and navigation model.
XIB benefits:
a. You can modularize your code.
b. More people can work on different-different controller without affecting your xib or code.
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 ;-)