There are many questions comparing building UI in storyboard vs programmatically but my question is does anyone have any data showing which approach has better performance in the app?
like if you had two UIViewController which have exactly the same ui but one was made in storyboard and another from code. If you present them each from another UIViewController ... which loads faster?
This is a case of "premature optimization". You'd need sensitive measurements to even detect the difference in performance between code-based creation of view controllers and storyboard-based creation. The difference is going to be at least a couple of orders of magnitude smaller than what a human can perceive. If one takes .0002 seconds, and the other takes .001 seconds, who cares?
Thus you should use the approach that is clearest and easiest to develop and to maintain. (That would be Storyboards, by a wide margin.)
Related
I've been working with Xcode for a while, and what I'm doing works, but I can't image that it is the best way to do it. When I want to transition between scenes in Xcode, I create a segue between UIViewControllers in the main storyboard. This is a picture of a storyboard in one of my apps.
By looking at the picture, you can probably understand why I'm curious about whether or not what I'm doing is bad practice. What should I be doing to transition between scenes, or what do most people do to transition between scenes? Thanks for the help!
This is not easy to answer, but I will give you some context:
Storyboards can be a nice visual way to remove push/present code from the view controllers and make it clear what is happening (vs code).
Having UIViewControllers handle navigation is not considered best practices (at least in many larger projects/enterprises). This is why patterns like VIPER (among other reasons, and yes VIPER can be overkill).
In your case the relationship is not clear, many things also go back and forth. Now it might be possible you can lay them out better, and perhaps the containment or relationships can be tweaked.
Here's some advice I can give. Try to make view controllers as dumb as possible about opening other view controllers, both the what and how - they ideally should just indicate to some controller/mediator/manager they wish to "do" something. It makes maintenance and refactoring a lot easier, especially adding a new feature later that might change how navigation works, such as adding on boarding into the app.
Long story short, storyboards are not bad, however many enterprise and large projects do not use them both due to the difficulty in version control with multiple developers (using shallow storyboards with NIBs can mitigate this, you do lose some of the Segue), and because you can tend to grow overly complex view controllers. Its great for personal, smaller apps... as complexity grows, value proposition becomes thinner.
I would like to know how much memory does a single ViewController take , because when I'm developing some apps I'm still not sure if it is better to create more ViewControllers , or if I should create less ViewControllers and change things in code , instead of UserInterface.
Example of what I mean: Let's say that I have two types of data and I want to see them on presented ViewController, but these two types are almost the same. So should I have only one ViewController and change things in code or I can just create ViewController for every type?
I know that it depends on how much code and how much things are in the UI but let's say that it is a few lines of code and just a very basic ViewController
I have looked into The Role of View Controllers
by Apple but I could not find the answer.
https://developer.apple.com/library/content/featuredarticles/ViewControllerPGforiPhoneOS/index.html#//apple_ref/doc/uid/TP40007457-CH2-SW1
I know that it's a bit weird , but I'm really curious.
Thanks.
An uninstantiated view controller doesn't use any memory. It's takes a trivial amount of disk space as part of the app, but no memory at runtime until it is created and displayed.
You are currently guilty of premature optimization. Write your code properly so it is easy to write, easy to maintain, and easy to debug. Don't worry about things like memory usage and performance until you have a problem that needs to be addressed.
If you have two different screens with two different types of data, then create two different view controllers.
Once it is working, then run it through Instruments and confirm you have no leaks or reference cycles wasting memory.
The size of extra view controller classes in your code is negligible, so unless you're talking about some extreme number of them, I wouldn't worry about that. The governing principle here is more likely to be DRY. If you've got a bunch of objects that differ in very small ways (e.g. the names on labels, etc.), then perhaps you can create a common protocol to which all of these objects conform, and then you can write a view controller designed for that protocol, rather than any particular object. But if you find yourself adding a bunch of unwieldy if statements and programmatically adding controls, simply to avoid having multiple scenes in your storyboard, then you may have gone too far.
I know this is a question that has been asked quite a bit, but it's iOS 9 and I still don't have a clear idea about what to do. For starters, here is what I seem to be surmising from all the data available:
Storyboards let you create segues. [I've never been a big fan of this answer because segues are often the least harrowing part of creating the UI layout for me.]
Xibs can let you create multiple top-level views. (Storyboards vs. the old XIB way) [I don't think I've ever used this much, though it seems rather helpful.]
Storyboards - Creating UITableViewCells is easier. [In my opinion, it's cleaner to create xibs for the cells and just invoke them in cellForRowAtIndexPath].
Storyboards can turn into one giant ultramassive file that is hard to edit. [I've seen this happen in practice and it is a big drawback, but at the same time...]
Storyboards let you arrange all your Views in one place with the layout shown as well. [This seems to be a big help for me. But then, over the years I've found doing this in code much easier. Which brings me to my final question.]
What is the performance aspect of both of these two things. My app is essentially the following :
A top level hierarchy of interconnected view controllers, not more than 5.
A large number of disparate, independent view controllers that range from Scroll Views to TableViews to static Imageviews.
Autolayout, size classes, the works.
For each of these view controllers, what is the performance of creating a storyboard for each of them vs. creating a xib for each of them. More importantly, what would be a good way to lay out an app like the one I've mentioned.
You definitely want to use storyboards for laying out view controllers - simply because you get access to topLayoutGuide and bottomLayoutGuide which the XIB editor won't give you.
For other views, it's a matter of preference. I tend to use XIBs for table view cells simply because I tend to reuse them on different screens and prefer to have them in their own files.
I would actually advise against manually writing view code where possible simply because it's much harder to read and work out how views are laid out, especially for developers who didn't write the code originally! For simple, dynamically sized things this can be fine, but if you're trying to lay out view controllers with different constraints depending on the size class it's going to end up a bit of a mess.
Yes, it's a pain to deal with merge conflicts of these files, but with iOS 9 you can split up view controllers into different storyboards a lot more easily using view controller references. Personally I find the inconvenience of merging storyboards/XIBs the lesser evil of having to write everything in code.
It sounds like a Storyboard is the right thing for your current project. However, my experience has been that Xibs and Storyboards are problematic in the real world, for these reasons:
extremely idiosyncratic from developer to developer, so it is tricky to build good storyboards as a team
black boxes, so they require a tremendous amount of knowledge to master (unbelievable amount of hidden behavior). Only the most superficial semantics are covered in the documentation.
internationalization is made much harder by being split up, especially if you have internationalized messages not contained in the Storyboard/Xib.
backwards compatibility breaks annually / deprecation guaranteed over time. This is especially difficult if you try to maintain compatibility with older devices.
As soon as more than two devs started touching our code we rewrote everything to avoid Storyboards and Xibs altogether, and we became much more productive.
If you have to deal with any of those real world situations, I heartily recommend programmatically creating all of your views. There is even an app that makes this easier (and is way more scalable). I have no relationship with this company or product, but it is hands down a better solution.
http://www.paintcodeapp.com/
I'm starting a new project and I have some doubts about storyboard good practices, specifically about optional hidden views (show only under certain circumstances).
Let's say you have an pdf downloader app, when the user select a download button a UIProgress bar appears and show the download progress. Should this progress bar be included in the storyboard or generated programmatically when the user press the download button?
It's a simple example but what about if there isn't only a UIProgressBar but also multiple hidden (optional) buttons? What if some of the buttons are overlapped? (I know overlapped button is bad design but just for the purpose of exemplify)
Should this ones be hidden or added programmatically? What about performance? Some say it takes more time to parse a Storyboard/Xib than a programmatically build view.
In DonaldKnuth's paper "Structured Programming With GoTo Statements", he wrote: "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."
So, you are trying to solve a performance problem you do not really have (at the moment).
You decision to have a view permanently or temporarily should be based on context of the view usage, not some hearsay performance issues between xib/stb vs programmatic approach, that resembles platform-wars, but otherwise, given how LLVM compiler works today, and what the HW performance of iPhone 4 or higher is, is basically nonsense.
Here's a simple rule. Have all the views in IB, hide or unhide them as necessary, and add/remove a view programatically only if you can give a good reason why.
I understand you instinctive desire to make it right, so instead of trying to manage one milion views in one controller, take a look at the problem that is satirically called Massive View Controller.
Proper decomposition into custom views, separation of concerns, clearly defined responsibilities split into more view controllers, view controller containment, is the answer to to address your concerns.
You want your app first and foremost to work correctly.That you can achieve by having a sound architecture so that you will be able to stay in control. Users will not appreciate that you instantiated some button programatically, because they couldn't care less. But if the app has inconsistent state because your view controller has 7000 lines and is spaghetti hell or is crashing, that is a problem.
if you are planning to use storyboards; would suggest to have view/buttons etc included . you can always hide / unhide the same from the code.
have a thought process and not cluster your view. Have multiple views and make your app look neat
Lately, when I navigate to my storyboard, I get the pinwheel animation for a few seconds and the laptop's fan goes into high gear for about a minute. This used not to happen, and I almost never hear the fan otherwise.
Firstly, is this indicative that there might be something wrong in my storyboard, or is it inevitable as the storyboard grows? The storyboard has about 25 VCs right now.
It will be adding many more VCs to the storyboard in the future. Some of them will be isolated, i.e., have no segues to any other VCs. Should I use nibs for those VCs in order to improve performance? Are there any drawbacks to using nibs in addition to a storyboard? Thanks
Yes, this will happen as the complexity of your storyboard increases. There are no technical issues using nibs in addition to a storyboard.
I prefer to use a third solution and have multiple storyboards each of which contains a logically distinct sub-set of view controllers. This retains the flexibility afforded by storyboards without allowing them to become too unwieldy.
You might be interested in http://www.raywenderlich.com/51992/storyboards-vs-nibs-vs-code-the-great-debate. Also read the comments.