IOS miscellaneous-why don't I use Interface builder?

The quarrel about Interface Builder on the Internet occurs every day, and there are a lot of reasons to use it. I have read this article recently, and many parts of the article have resonated with the author. Based on some of my experiences, you can see what you see now. You can regard it as the Chinese version of the former.

I started iOS development a year ago and saw Stanford's CS 193 P. The old man recommends beginners to use Storyboard for development. Because it is visualized, users can drag out the interface without having to know much about the code layer. Various configuration items can be checked to save a lot of code, in addition, Storyboard makes the activity process of the application clear at a glance. I am not used to this drag-and-drop Programming Method: this is not a miracle of the code!

I started to do the actual project. After reading the code of several open-source projects, I know that there isxibFormat File. This product is the product of Interface Builder. Now we call them NIB. Similar to Storyboard, visual drag and drop and configuration. Storyboard is relatively new, and there are not many people in the industry, so I am very entangled. Is it because I use new things to listen to the old man's words or try NIB alone with the big stream? I'm not afraid of tigers at the beginning. I didn't do iOS development anyway. Let's talk about it in class. Our team used Storyboard to drag the UI. A month later, I proposed to abandon Interface Builder without any NIB (including Storyboard ). Until now, as long as it is within my control, I have never touched any NIB, and I prefer to use code to generate it.

There are many reasons not to use Interface Builder. For me, there are several points:

Multi-person collaboration

From the perspective of project management, NIB should not be used. Can you ensure that you will never conflict when merging NIB? Merging NIB in a project with a small scale and multiple developers is simply a nightmare. In particular, when multiple people share a Storyboard, developers will spend a lot of time and energy solving conflicts, rather than doing something more meaningful than this.

Of course, if the final merge result is correct and credible, many people can still bear it. However, merging is problematic, especially automatic merging with Git. These problems do not occur until they are running! Testing is insufficient, which is a potential risk. In addition, we know that NIB is unreadable, that is, Version Control is meaningless. You can't tell the story from diff. Else makes you use not NIB, but a line of Objective-C code, the results will be much better.

Select explicit instead of implicit

I like to use code to complete various things, so that you can open a view or a view controller to see everything. Otherwise, the student reading your code will have to find the corresponding NIB.

NIB is also a breeding ground for bugs. Many times, after debugging for half a day, you find that a bug is not in your own code, in a small corner of Interface Builder, you forget to tick an option. If all the components are generated by the Code, it is much easier to debug. You only need to focus on the View-related code. Explicitly writing a view in the Code gives you powerful control over the view. You can intervene from initialization to layout and drawing. In the code, you can clearly know the attributes of a view, rather than being managed by the Interface Builder, although it seems that there are too many lines of code, it helps you reduce the number of bugs and save debugging time.

Coupling

Using Interface Builder to create reusable views is a tough task. First, you need to drag a variety of components, and then set properties for each component. Then you need to connect the outlet to the code block to be used ...... One time, you forget to connect to outlet, and then your program is in runtime crash. You have made a bunch of bugs. For a variety of fragmented views, I prefer to write classes for them, and then implement a variety of things I want in them. When these views are needed, it is enough to generate objects. If I have any errors, the compiler can help me check them.

Using NIB makes me feel at ease, and it makes the program less compact. Many things that require cohesion are split out. In terms of actual development experience, it is a block in the East, a block in the west, and I am tired of cutting it apart. Once you customize more and more views, NIB will increase.

Layout

I admit that I have hardly used various layout (including auto-layout) in Interface Builder ). I don't know if it is difficult to use NIB for layout. But I know that rewriteUIViewOflayoutSubviewsMake the layout easy. You only need to set the layout of all child elements here. When you need to re-layout, clicksetNeedsLayoutThat's all. You don't need to worry about various layout concepts in Interface Builder, and you don't need to write the layout code in different places (reducing coupling ). It is not difficult to adapt the same view to the iPhone and iPad with a slight judgment. Providing NIB for iPad and iPhone is simply intolerable.

Localization

What happens when IB encounters localization? I have been trying again! As long as the NIB involved in localization requires you to invest time and physical strength. Click the mouse, set it, and work only! If code is usedNSLocalizedString(@"Localizable String", @"Comment")In the resource file.

Summary

The original intention of Interface Builder may be to help developers save time and energy for writing interfaces. Visualization, presentation layer, and data separation are good ideas. However, it is not satisfactory yet. It makes multi-person collaboration difficult, leads to poor practices, reduces reusability, and slows down your development ......

If I don't need IB, I don't need it. As a programmer, I should use code to speak. From the perspective of installation force, does this seem to be a high-end atmosphere?

Turn: http://blog.xianqu.org/2013/06/why-i-dont-use-interface-builder/