Who is the best optimized way?
Create objects in my UITableView using storyboard (Drag and drop in my cell), or create objects programmatically (cellForRowAtIndexPath)?
When the project compile and run in device which of the two options will run faster?
In terms of pure performance, code created UI objects are faster than any nibs / storyboards objects, only because storyboards and nibs files are stored on disk until they are loaded in memory and translated in UIKit objects.
That being said, it also depends on how you are implementing it. If you use prototype cells in storyboard vs creating cells everytime in cellForRowAtIndexPath, then storyboards win because of the reuse cells (though you can also reuse code created cells).
And that being said again, the performance win you have by creating UI with code is ver small and not even close to be perceptible by the human eye. Therefore, for me, using the storyboard is a no brainer for the ease of creating interface without polluting your code.
You can see a nice article about that here: http://www.toptal.com/ios/ios-user-interfaces-storyboards-vs-nibs-vs-custom-code. The article is approx. 1 year old but it still is accurate.
The effective performance will be identical for the same layouts. I would choose one approach over the other based on different needs.
Storyboard prototype cells can be faster to setup, easier to get Autolayout constraints working correctly, but you cannot re-use that prototype cell outside of its Storyboard. If using the same cell layout across multiple views is required, writing your table view cell in code or using a nib file is required.
Also, it should be pointed out that cellForRowAtIndexPath is still required when using a Storyboard prototype cell in order to configure your cells, assuming you have some sort of dynamic data to display. Similarly, in the programmatic approach you should not be creating views in cellForRowAtIndexPath but rather configuring them.
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?
For creating a login page or something like that, in autolayout case I use tableView instead of using a scrollView in viewController. For IndexPath majority cases I reuse the customCell. For entirely different items only I use another customCell. Since the Cell Class are increasing in my project. I dont know is it a good practice. Please share your opinion to increase the overall performance and least memory usage for my application.
Putting UITableView in all views is not a good practice every time.
I recommend using scrollviews and content views inside them in pages like login.
Use Tableviews only in those screens which show repeated contents.
I have seen codes generated through tableview controllers in every page.
I dont do in that way.
Better you go for Scrollviews.. Its a good method as far as I have seen.
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.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Currently we use Storyboard over xib in all projects. But in my view if you want to make reusable view (custom view or Tableview cell) which can be re-used in different view controllers, you must use xib files as in storyboard there is no way we can make single view object separately.
Note that I am using Storyboard for workflow (view controllers with segues all around) of entire application. Only for reusable tableview cells I am using XIB.
I have searched in lot of apple documents as well as WWDC videos but I could not find any concrete proof from Apple developers which says that XIBs are here to stay or you should use XIB for custom views.
If any of you guys have any kind of links which gives somewhat confidence that we can still use XIB without fear of apple removing it, it would really be appreciated.
Storyboards are recommended when you don't reuse views.
Once you want to reuse something in multiple views/storyboards, then you need XIBs. You already mentioned the example of custom cells. That is something I need quite often and I want to use the same cell in multiple table views. I do the same with charts. I create a chart view in which I set colors etc. and I reuse it everywhere, only putting different data in it. This saves me a lot of code in respect to style/appearance and makes the app easily maintainable. In case of change (e.g. because of new iOS version), I need to change everything on a single place.
Furthermore, I want to have views (e.g. cells) for iPhone and iPad and let the system determine which one to use. For this, again, I need XIBs. I use the notation with ~iphone or ~ipad at the end and I don't have to write code for retrieving the correct view.
This are two things that you simply cannot do without XIBs. So, following the Apple guidelines, my approach is to use storyboards whenever possible and XIBs only when I need them (mainly because of reusability). But there are real cases when one needs XIBs! Simply ignoring them is not a good practice for sure. Actually, in each project I have storyboards as well as XIBs.
Edit: I just found a great post explaining the disadvantages of storyboards. There are plenty of things that I was not aware of.
Also, you don't have to use either exclusively. You can still use XIB files even if most of your work is in storyboard. And using either also doesn't restrict you from creating a view that isn't built in IB at all.
Storyboard has plenty, plenty of advantages. Particularly when you start bringing new people in on the project. Without getting engulfed looking at hundreds of thousands of lines of code, a new developer can look at the storyboard and in 30 minutes or less get a quite good idea of the flow of the app.
With that said, you should never limit yourself to anything. Limiting yourself to just storyboard and never using XIB or building a view completely in code is like saying "We're only going to use NSArrays, and never NSDictionary or NSSet". Instead of a silly limitation, you should always just be sure you're using the right tool for the job.
My opinion is use which one is appropriate for that context, here is some guidelines:
When to use nibs
Modularity is key to well designed nib files
Use nibs to store views, subviews, custom controls or repeated views
There’s no way to represent the relationship between screens of related content
When to use Storyboards
Storyboards are best used to represent screens of content and the connections between those screens
Give due care and attention to the prepareForSegue:sender: method
Modularity is still applicable when designing storyboards
General Guidlines
Decompose your projects into nibs and storyboards
Views, subviews and custom controls should be contained within separate nib files
Use storyboards when designing full screen content and there are clear relationships between scenes
Consider whether the interface needs to be static or dynamic
Use separate storyboards to encapsulate reusable sequences of scenes
Use separate storyboards for unrelated scenes
Table view cells that can be reused across different controllers belong in nib files
In my applications I have nibs which include up to 3 tableviews each, one above the other, which I set to hidden whenever their corresponding tab (i.e. segmented control segment) is not selected.
The question is: can I avoid loading all the nib components if they are not needed (i.e. hidden)? Let's say I have 3 tables in a view and I want to load just the first one (the one above), loading the other tableviews on demand if needed. Is constructing the tableview programmatically the only way to achieve this?
Just for clarification: I am not using the same tableview with different data sources because I want to manage the "drag to refresh view" on each table separately and I like the idea to have separate tables (it seems more neat to me).
Just divide that NIB in 3 nibs with a UITableViewController each and switch them programmatically on-demand. Your code will be more organized and your resources easier to maintain. Simplify!