Should UI be done in XIB /storyboard or handwritten code?

Article source: www.devtang.com/blog/2015/0…

Reference article:

About Code writing UI, XIB and StoryBoard

Blog.csdn.net/likendsl/ar…

The Game between Coding UI, XIB and StoryBoard, and some Tips for Interface Builder

www.onevcat.com/2013/12/cod… \

I plan to share some controversial topics and express my opinion. This is the second in the series.

What I want to discuss in this article is: Should UI writing be done in XIB /storyboard or handwritten code?

In line with the principle of “once used, you have your say”, I would like to share with you my experience:

• When netease first developed “Youdao Cloud Note”, we used XIB to make the interface.
• When I started writing Chalknet three years ago, I also used XIBS to make interfaces.
• Later, when I was developing “Ape Bank”, I tried to use storyboard to make interface, but finally gave up. Then I changed most of the interface writing to hand-written code.
• I used storyboard again last year when DEVELOPING “Little Ape Search” due to time constraints, but now I plan to reconstruct it in handwritten code.

Xib usage survey

In addition to my own experience, I also investigated the development of all apps installed in my mobile phone. I wrote a script to analyze the number of XIB files contained in more than 100 apps in my mobile phone. In general, an App that is written entirely through xiB/storyboards should contain no fewer than 10 XIBs (note: storyboards are broken up into multiple XIBs when packaged).

The final results of this research, as well as the source of the script I analyzed, are here. I’ve picked some of the more famous ones and listed them below. (I have also listed the number of JS files they contain, which reflects the application’s use of UIWebView-based Hybrid programming, but is irrelevant for this discussion.)

This chart shows that even the better-known apps have a wide variation in how they use XIB/storyboards. A few examples:

• QQ, WeChat and yixin are all social applications and should be more complex than yixin due to the number of users and longer development time. However, the number of XIBs of the former is very small. This means that in QQ and wechat, a lot of the interface must be done by handwritten code.
• Didi Dache, Kuaidi Dache and Yidao Yongche are all ride-hailing apps. Supposedly, Didi Dache and Kuaidi Dache both have taxi and private car hailing functions, which should be more and more complex than Yidao Yongche. But the number of XIBs in the former is very small. This also shows that the interface of Didi Dache and Kuaidi Dache is completed by handwritten code.

In addition, the number of XIBs in apps such as Mailbox, Podcast, Twitter and Objcio is 0, indicating that the UI interface is written entirely by handwritten code.

Of course, there are some apps that are almost made up of XIBs, such as Dianping, Meitu Xiuxiu and Netease Youdao Dictionary. Apple’s iMovie uses over 4,000 XIBs, which is incredible. When I looked at it later, it turned out that iMovie was internationalized and had about 120 XIBs per language, but since nearly 40 languages were supported, the number of XiBs had grown to over 4000. Each XIB of Dianping is also divided into 4. I have not studied the specific uses of these xiBs. Here is an example:

| 1 2 3 4 | “` ./Payload/DPScope.app/WEDHotelShopInfoMainModule.nib . / content/DPScope. App/WEDHotelShopInfoMainModule. Nib/objects – 8.0 +. Nib ./Payload/DPScope.app/WEDHotelShopInfoMainModule.nib/objects.nib ./Payload/DPScope.app/WEDHotelShopInfoMainModule.nib/runtime.nib

| ---------------- | ------------------------------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------------------------------ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - | # # to discuss the research above we can see that you're on whether should use xib do interface is controversial. In practical cases: * There are cases like Twitter, Mailbox, objcio that don't use XIBs at all. * XiB is also used in a small amount, such as QQ, wechat, Didi Taxi, netease News and XiB. * There are also cases of heavy use of XIB like Alipay and Dianping. So I will express the advantages and disadvantages of using XIB and not using XIB from my point of view. ## The advantages of using XIB and Storyboard * To develop interfaces wySIWYG, you can quickly construct interfaces by dragging and dropping. * You can easily tease out the call relationships between all the 'View Controller' interfaces from the storyboard. This point to the new join the project team development colleagues, more friendly. * You can use the Static Cell function of the Table View Controller in Storyboard. For developing a few cells, but each Cell is different list class Settings interface is convenient. * By implementing the '-- (void)prepareForSegue (UIStoryboardSegue *)segue Sender (ID) Sender' method, the jump logic for each View Controller is clustered in one place, This makes it easy for us to unify the interface to jump and transfer data. * Storyboards make it easy to modularize and reuse common functionality. WWDC's 2011 Storyboard video, for example, modularizes twitter sharing into a separate Storyboard. ## Disadvantages of using XiBs and Storyboards * XiBs are a disaster for versioning. A storyboard is actually a collection of xiBs, making it easier for multiple editors to clash. And even though they are XML, conflict resolution is not as easy as code. * Apple designs xib storyboard with current PC OS versions and Xcode versions. So if two collaborating developers have different operating systems or Xcode, this file will be modified every time you open it. In addition, even if the operating system version is the same as the Xcode version, sometimes opening it will cause some automatic changes. * The concept of segue introduced by storyboard is not easy to develop, especially when passing parameters. If you are using an internal program trigger a segue, you need to set the dest View Controller parameter information in place of another callback. * We found that the color values set in the XIB were not exact and RGB was often off by more than 10 pixels on the real/emulator. * XiB and Storyboard are not friendly to inheritance support. Cannot do interface inheritance. * Xib and Storyboard are not friendly to search support and can't easily look up keywords in Xcode (but can be found by writing bash commands). * Storyboard does not support composition well and does not allow multiple subviews in a XIB. * XiB and storyboard are not very convenient for modular management of interfaces. For example, if we want to change the font style of all buttons in the interface, we can only change the font style of xiB and storyboard one by one. If it is written in code, we only need to change the implementation of a factory method. * For complex apps, storyboard performance can be poor. Therefore, I prefer to use code to write UI interface. In addition, nowadays mobile development has increasingly strong requirements for App, and many complex interaction effects need to be written in code. In this case, XIB can provide more and more limited help. But the wySIWYG advantage that XIB offers is huge, and it would be painful to debug if we were writing. In this article, I recommend you to buy [Reveal](http://revealapp.com/), an interface debugging tool. Reveal can dynamically modify the parameters of interface elements while the App is running. In this way, we can debug the font, color, and location of interface elements in the Reveal code at one time, avoiding multiple restarts to debug the interface. I in my [the iOS development advanced] (http://item.jd.com/11598468.html) in the book, also spent an entire chapter to introduce the use of pass Reveal. Here is a screenshot of the Reveal runtime from the book: [] (http://tangqiao.b0.upaiyun.com/reveal/reveal-ui.jpg) # # In fact, you don't need to do a "tough decisions", you can like QQ and WeChat, Use xiBS and Storyboards selectively depending on the situation. Here are some of my suggestions: * For complex, dynamically generated interfaces, it is recommended to use hand-written interfaces. * Manual code construction is recommended for buttons or UI controls that require a uniform style. Easy to modify and reuse later. * For UIView classes or UIViewController classes that require inheritance or composition relationships, it is recommended to manually code the interface. * For simple, static, non-core functional interfaces, consider xiB or Storyboard. For many novices, they are exposed to using Interface Builder to construct interfaces. Hopefully this article will shed some light on the controversy surrounding XIB and Storyboard development. Writing interfaces are not a niche activity and have many benefits, so I hope everyone can master them and decide whether to adopt them on a case-by-case basis when needed. Wish you have a good time ~ the Posted by tang qiao Mar 22 nd, 2015 (iOS) (http://www.devtang.com/blog/categories/ios/), original articles, copyright statement: Free reproduced signature - not commercial - not derivative - keep | [Creative Commons BY - NC - ND 3.0] (http://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh) \ \Copy the code