About code handwriting Ui,xib and storyboard

Code Handwriting UI

This approach is often used on a large scale by college-based geeks or large projects that rely on multi-person collaboration. Geek like to use code to build the UI, because the code is the keyboard knocked out, so you can do not open IB, hands do not leave the keyboard to complete the work, you can focus on the coding environment, looks very cool very efficient, and not to run when people do not know what it will look like, It also shows the height and mystery of the programmer's profession (this is not really black.) Think of all the jiangshan behind the designers. Large multi-person collaborative projects use code to build the UI, mainly to look at the advantages of pure code in version management, to check for tracking changes and to make code merging relatively easy.

In addition, the code UI can be said to have the best reusability of code. If your goal is to write some highly reusable controls for other developers to use, it's no wonder that the best choice is to use code to complete UIView subclasses. such further modifications and other developers will be much more convenient when used. The use of code is also the most powerful, there will be xib or storyboard can not do things, but the use of code in the end will certainly be able to complete the required requirements.

But the disadvantage of the code handwriting UI is also the most obvious, mainly a word: slow. first of all, to complete a less complex interface than the visual IB, you might want to write hundreds of lines of UI code. Whether you are initializing a label, or setting a frame or adding a target-action, you need to write code that is not only a waste of time in the early stages, but also a pain in locating and looking for code after maintenance. Second, because you can't visually see the results you can get, you probably need to constantly Cmd+R / Cmd+. to modify the position size of each view. Even if you use tools such as reveal or restartlessoften, you will not be able to easily complete the layout you need. Plus, if you need to use AutoLayout for size adaptation, it's even more frustrating to use code to constrain it. Many times an unsatisfied constraint problem is enough to run back and forth to modify debugging for a long time.

Xibs

By using IB and Xib files to organize the UI relative to the code, you can save a lot of code and time for faster development. If you have ever been poisoned and maimed by the visual interface of the Microsoft home Visual Basic or other visual system, and therefore suspect interface Builder's pure pedigree and ability to work, it is recommended to take a look at these materials to correct the three views: Jean-marie Hullot's Interface builder myth as well as the green amid in a suit are used to build an application with IB at Next (FQ required). Alternatively, you might want to open the application folder on your Mac or the Apple Home app on your iphone. You will be surprised to find that IB is far more powerful than you can see: small tools such as the Calculator picker, up to iwork three-piece set, aperture or final cut for professional applications, none of which is done using IB for UI production.

In fact, IB and Xib are bundled in the Developer Toolkit from the first launch of the iOS SDK, and have been integrated directly into Xcode after Xcode 4 as part of the IDE. One of the main purposes of xib design is good MVC: In general, a single xib file corresponds to a viewcontroller, and for some custom view, it is often loaded using a single xib and loading from the main bundle. IB helps with the creation of view, layout, and relational mapping with file owner, among other things. For beginners, keep in mind that xib files are the content of the view, help to build a better concept of MVC, so that in the development of avoid or less detours.

Xib file before a big problem is that the file content is too complex, the readability is poor, even if simply open without editing can cause changes and cause the suffering of merging and submitting. in Xcode 5, Apple dramatically simplifies the format of the Xib file, making it easy to read and maintain. can say now for the Xib file in version management and pure code is not much different, as long as carefully read the Xib file content, naturally can understand the vast majority of, and well track and find the past changes record.

Of course xib is not perfect either. The biggest problem is that the settings in Xib are often not final, and in the code you will have the opportunity to overwrite the UI design you made in the Xib file. Setting the same property in different places will be a nightmare in later maintenance. Because IB is still limited, it has no logical judgment, and it is difficult to configure at runtime, whereas the use of code is indeed omnipotent. When using Xib, it is almost inevitable to complement and complete functionality with part of the code. On this point in the development should be highly valued, if you choose Xib, then try to isolate the work of xib and the work of the code: the ability to use Xib to complete the content of the unified use of xib to do, not to say three labels two of them in the Xib set the font and the other is in the code to complete. It would be a good way to try to keep only the necessary, less iboutlet and ibaction.

StoryBoard

After IOS5, Apple provides a new way to make the UI, which is storyboard. Simply understood, storyboard can be seen as a set of Viewcontroller corresponding Xib, and the way in which they are transformed. In storyboard, you can see not only the layout style of each viewcontroller, but also the conversion relationship between each viewcontroller. Compared with the individual xib, the code needs less, and because of the aggregation of the various xib, the speed of understanding and modifying the interface is improved greatly. Reducing the amount of code means reducing the amount of bugs, which is one of the truths in program development.

After Xcode5, Storyboard has become the default configuration for new projects, which also represents Apple's advice and future direction for developers. WWDC2013 's various sample code also basically used storyboard to demonstrate. As you can foresee, Apple will certainly continue to strengthen in this area, and conversely, pure code or a single xib will probably not be enhanced.

If you don't consider iOS version support (in fact, it's very rare to see apps that you want to start supporting from IOS4), now the biggest problem for storyboard is collaborating with multiple people. Because all the UI is defined in a file, many developers personally or the company's technical leaders believe that storyboard is not able to collaborate on development, in fact, this is more a kind of storyboard of the unfamiliar caused by misunderstanding. Although Apple does not explicitly mention it in WWDC, no one is required to have only one storyboard file for the entire project. One possible approach is to break down different parts of the project into several storyboard and arrange for developers to be responsible for their own parts. For example, a Uitabbarviewcontroller-based application with 4 tab functions that is independent of each other, can use 4 storyboard to represent 4 tabs, and develop without interfering with each other. So there is no such thing as a conflict. Storyboard API is so simple, now the total number of methods in the SDK a hand can be counted, so the specific method here is no longer wordy.

Another challenge for storyboard comes from the reuse of Viewcontroller and the processing of custom view. For the former, in the correct packaging interface and good design on the basis, in fact, storyboard VC reuse and code VC reuse is no essential difference, in the storyboard to add a good package needs to be reused scene can be resolved. For the latter, because the existence of a single view is not allowed in storyboard, many times we still need to customize the UI with the help of a single xib. This is due to the storyboard design ideas, storyboard more emphasis is a hierarchy, is a global perspective on the organization of UI design and migration. For a single view, more attention is paid to reuse and customization than to the entire project's process. I believe that by seizing this point, you will be well aware of when to use Xib and when to use storyboard.

The last word about storyboard is that there are now some concerns about storyboard performance. Because storyboard files tend to be larger and load slower relative to a single xib. But in fact, with the current equipment replacement, in the iPhone4 are difficult to find today, this performance gap can almost be ignored. And then the device, whether read or parse, will only get faster and quicker. So the problem of performance is absolutely not necessary to worry about.

My point of view and choice

I started out with Xib, because there was no storyboard, and I didn't like the code of the College School geek. Up to now, three ways I have tried, and separately got some may not be particularly profound experience. For me now, xib is my cheese and the way I've been using it in some of my projects, and I can use Xib to set up a complex UI that includes custom features and good parts reuse in a very short period of time. But after I tried several times to make a demo using storyboard, I decided to turn to the storyboard after the project. On the one hand because really is the future direction (every time the new project deleted storyboard very annoying. ), now the storyboard proprietary preview function, and then AutoLayout further improvements are worth looking forward to, on the other hand also feel that the cheese put a place too long will not be good, take advantage of the great changes in IOS7, also update their own ideas and ways, Putting the cheese in a different place may be a boon for the future.

For beginner's mind, I don't recommend using code directly for UI authoring and layout, because the tedious UI code is really boring. As soon as possible to see the finished product, at least as soon as possible to see the prototype, is to maintain interest, continue to deepen and engage in professional career. So if it is possible to have conditions, under the guidance of the veteran to choose storyboard for rapid construction (or if it is a single-person development, you can not consider multiple storyboard collaboration, it is easier), will be a good choice to get started. While the latest tutorials and documentation have begun to tilt toward storyboard, the issue of storyboard will be much more focused on so that there will be more information available for reference when getting started.

This is not to say that there is no need to care about the code UI or Xib, because when using storyboard, it is unavoidable to touch them when you can only use code and customize individual view. One of the suggestions here is that while you don't rely on code for UI authoring, it's essential to understand and learn how to build the UI from scratch using pure code: Starting with the new window, initializing the Viewcontroller, adding the necessary view, Set their property, and add and process their various responses and responser chains. It's easy to get started with iOS, and Xcode and Xib/storyboard help developers hide too much detail, but many times if you don't understand what underhood is, why these xib/storyboard work, Often the card in some very ridiculous and the initial bug can not find North, which is actually a huge waste of time, it is not worth it.

Some IB tips

Finally, share some tips on using IB to end it. Many of these methods can also be used on storyboard, so it is also a small memo to summarize the xib of a user's career before I go to myself.

Add multiple outlet at the same time

In IB, by selecting a view and right-clicking, a gray HUD will appear, allowing you to easily drag or set events and outlet. You can open multiple panels at the same time to add all outlet at once. Right-click the Panel, drag the Panel, and then open another. You will find that the previous panel has been left behind so you can easily drag and drop the settings.

Of course, for groups and similar iboutlet, it is more convenient to use iboutletcollection directly for processing.

Visual coordinate distance

The most annoying problem for IB is to be on it. We can explicitly specify X, y coordinates when using the code, but when we switch to IB we are more often uiview by dragging and dropping. For example, need three of the same label, in addition to the powerful naked eye to estimate whether the distance is equal, you can only obediently select three labels, write down their coordinates and then open the calculator to do add and subtract?

Obviously not so stupid. Select a label, and then hold down the option key and move the mouse over the other label to try it? You can see that the distance between the view is displayed in a very easy-to-understand way. Not only the same level of view, but also the distance between the selected view and other levels of view can be displayed as well.

Make a selection in a set of view hierarchies

For some complex view hierarchies, we tend to be more difficult to choose directly from IB. For example, when a view is covered with each other, it is difficult to even select the underlying view in the edit view. The general practice is to open the View Level Panel on the left, expand layers and select the view you want. In fact, we also have an easier way: Hold Cmd and Shift , and then right-click above the view you want to select to list all the views in the clicked position. This allows you to quickly and easily select the desired view.

Add Guides

Such a big skill must be put at the end ... Double-click a view in the hierarchy list on the left, and then Cmd+_ either Cmd+| add a horizontal or vertical center Guide to the selected view. Of course, this auxiliary line is free to move. If you have done the design of the students must understand the meaning of the later on and design changes in the time have important reference value.

Transferred from: http://onevcat.com/2013/12/code-vs-xib-vs-storyboard/

About code handwriting Ui,xib and storyboard