Article source: www.cocoachina.com/industry/20…
Recently, I contacted several beginner iOS learners. Among them, there is a common confusion and question, that is, how to make UI interface. IOS apps place a lot of emphasis on user experience, and the success of most apps has a lot to do with interaction design and whether the UI is beautiful and easy to use. As iOS development has evolved so far, there have been three main schools of UI creation: writing UI and layout with code; Organize viewControllers or views using a single XIB file; Use StoryBoard to build the entire UI from a single or very few files (more on this later). The debate about how to make uIs has been one of the most enduring in iOS development, and there may never be a consensus. But the first thing to know is that each of the three methods has its own advantages and disadvantages, so each has its own best situation, and there is no complete superior or inferior. For starters in iOS development, it can be difficult to decide which UI architecture is best for you. In this article, I hope to give some suggestions based on my own experience, in order to help beginners to choose the most suitable scheme for their own application scenarios. For the old birds, it is also advisable to compare their daily use habits and use of the scene, to see if there is any place that can be improved or changed. At last, because I am most used and fond of using Interface Builder and XIB to make UI, some tips for using IB are attached at the end of this article to make a conclusion.
Code writing UI
This approach is often used on a large scale by academic geeks or by large projects that rely on collaboration between multiple people. Geeks like to build uIs in code because the code is typed at the keyboard, so that they can do their work without turning IB on, without taking their hands off the keyboard, can focus on the coding environment, looks cool and efficient, and nobody knows what it’s going to look like until it’s run. Also shows the programmer this profession lofty and mysterious atmosphere (this is really not in black.. Think of all the people behind the designer’s back.) Massively multiplayer projects use code to build uIs for the benefit of pure code for version management, making it easier to check, track changes and merge code.
In addition, the code UI arguably has the best code reuse. If your goal is to write highly reusable controls for other developers to use, then the best option is to subclass UIView in code. This will make it easier for further modifications and other developers to use it. Using code is also the most powerful. There are things that xiB or StoryBoard can’t do, but using code must eventually fulfill the requirements.
But the disadvantage of writing UI code is also the most obvious, mainly in one word: slow. First of all, compared to visual IB, you may need to write hundreds of lines of UI code to complete a less complex interface. Whether it’s initializing a Label, setting up a frame, or adding a target-action, you need to write code, which is not only a huge waste of time up front, but also a pain to locate and find code later in maintenance. Second, because you can’t visually see what you’re getting, you’ll probably need to keep Cmd+R/Cmd+. To change the position size of each view. Even if you use a Reveal or restartlesrate reminder, you still don’t get the required layout all that conveniently. Plus, if you need to use AutoLayout for sizing, using code for constraints becomes even more of a headache. Many times a problem with an unmet constraint is enough to run change debugging back and forth for a long time.
Xibs
Using IB and XIB files to organize the UI as opposed to code saves a lot of code and time, resulting in faster development. If you’ve ever been poisoned by Microsoft’s Visual Basic or any other Visual Interface, and wondered if Interface Builder was a pure product or capable of working, take a look at this information to correct three things: Jean-marie Hullot’s Interface Builder myth, where Joe, a young man in a suit, built IB applications by hand at NeXT (scaling walls). Also, open your Apps in the Application folder on your Mac or Apple’s Home app on your iPhone. It’s amazing how much more powerful IB is than it meets the eye: everything from gadgets like a calculator color finder to iWork three-piece, professional-grade applications like Aperture or Final Cut uses IB for their UI.
IB and XIB have been part of the developer toolkit since the iOS SDK was first released, and have been directly integrated into Xcode as part of the IDE since Xcode 4. One of the main goals of xiB design is for good MVC: Generally, a single XIB file has a ViewController, and custom views are often loaded using a single XIB and loaded from the main bundle. IB helps with view creation, layout, and relational mapping to the file owner. For starters, keeping in mind that xiB files are all view content helps to establish a good MVC concept and avoid or avoid detours in development.
Xib files have been criticized for their complexity and poor readability, and simply opening them without editing can cause changes that lead to merge and commit misery. In Xcode 5, Apple dramatically simplified the format of XIB files, making them easy to read and maintain. It can be said that xiB files in version management and pure code has not much difference, as long as a careful look at the XIB file content, naturally can understand most of the, and well track and find the past modification records.
Of course xiB is not perfect. The biggest problem is that the Settings in the XIB are often not the final Settings, and in code you will have the opportunity to overwrite the UI design that you did in the XIB file. Setting the same property in different places can be a nightmare for later maintenance. Because IB is limited, it has no logic and is difficult to configure at run time, whereas using code can do anything. When using xiBs, it is almost inevitable to supplement and complete functionality with some code. If you choose a XIB, try to keep the XIB work separate from the code work: use the XIB for everything that can be done with the XIB, not the three labels where two of the fonts are set in the XIB and the other is done in the code. It would be a good idea to keep as few IBOutlets and ibactions as necessary.
StoryBoard
With iOS5, Apple came up with a whole new way to do UI, and that’s StoryBoard. To put it simply, you can think of a StoryBoard as a set of XiBs that correspond to a viewController, and how they translate between them. In a StoryBoard, you can see not only the layout of each ViewController, but also the transition relationship between each ViewController. There are fewer code requirements than a single XIB, and the speed of understanding and modification of the interface is greatly improved by bringing together the XIBs. One of the truisms in program development is that less code is less bugs.
Since Xcode5, StoryBoard has become the default for new projects, which represents Apple’s advice to developers and future direction. Each Sample Code of WWDC2013 basically uses StoryBoard to demonstrate. It is predictable that Apple will continue to enhance this area, whereas the pure code or single XIB approach will probably not be enhanced.
Regardless of the support for iOS, the biggest issue facing StoryBoard is multiplayer collaboration. Because all the UI is defined in a single file, storyboards are considered uncollaboratively developed by many developers and corporate technical leaders, but this is more of a misunderstanding caused by the strangeness of storyboards. Although Apple didn’t explicitly mention it at WWDC, no one stipulated that there should be only one StoryBoard file for the entire project. One possible approach is to break the different parts of the project into storyboards and assign developers responsibility for their own parts. For a simple example, a UitabbarViewController-based application with four separate TAB functions can be developed with four storyboards representing each TAB without interfering with the other. Then there would be no conflict. The StoryBoard API is so simple that you can count the number of methods in the SDK on one hand, so I won’t bother with the details here.
Another challenge in StoryBoard comes from reusing viewControllers and handling custom views. For the former, there is no essential difference between VC reuse of StoryBoard and VC reuse of code on the basis of properly encapsulated interfaces and good design. It can be solved by adding scenes that are well encapsulated and need to be reused in StoryBoard. In the latter case, because storyboards are no longer allowed to have a single view, a lot of times we need to customize the UI with a single XIB. This is due to the way storyboards are designed, which is more hierarchical, organizing UI design and migration from a global perspective. For a single view, there is more emphasis on reuse and customization, and it has little to do with the overall project flow. With that in mind, you’ll have a good idea of when to use xiBs and when to use storyboards.
The last thing I want to say about storyboards is that there are now some concerns about the performance of storyboards. Because StoryBoard files tend to be larger than a single XIB, they load more slowly. But in fact, with the current generation of devices, in today’s iPhone4 is hard to find, this performance gap is almost negligible. And devices after that, both reading and parsing, will only get faster. So there is no need to worry about performance.
My views and choices
I started with XIBS, because storyboards didn’t exist, and I wasn’t an academic Geek who liked code. Up to now, I have tried all three ways, and got some of them may not be particularly deep understanding. For me now, XIB is my cheese, and it’s the way I’ve been using it in some of my own projects, where I can build a complex UI with custom elements and good part reuse in a fraction of the time. But after a couple of demos IN StoryBoard, I’ve decided to switch to StoryBoard for the rest of the project. On the one hand because it’s really the future direction (it’s annoying to delete storyboards every time a new project is created) We are looking forward to the StoryBoard’s proprietary Preview feature and further improvements to AutoLayout in the future. On the other hand, I also think it’s bad to keep cheese in one place for too long. Taking advantage of the big change in iOS7, I also update my concept and way of putting cheese in another place, which may be beneficial in the future.
For starters, I don’t recommend using code directly for UI creation and layout, because long UI code can be very boring. Seeing the finished product as soon as possible, or at least the prototype as soon as possible, is an effective motivation to stay interested, keep going, and pursue your career. So if possible, choosing storyboards for quick builds under the guidance of Old Bird (or, if you’re developing them individually, it’s easier not to worry about multiple storyboards working together) is a good way to get started. The latest tutorials and documentation have started to focus more on storyboards, and more attention will be paid to StoryBoard issues in SO, SO that there will be more information to refer to when getting started.
This is not to say that you don’t need to care about the code UI or XIB, because storyboards will inevitably have to do that when you can only use code and customize individual views. One piece of advice here is that while you don’t rely on code for YOUR UI, it’s important to understand and master how to build a UI from scratch using pure code: This includes starting with a new Window, initializing the ViewController, adding the necessary views, setting their properties, and adding and handling their various responses and responser chains. Getting started with iOS development is pretty easy now, Xcode and XIB/Storyboards help developers hide too many details, but a lot of times if you don’t understand what underhood is and why xiB/Storyboards work the way they do, Getting stuck on ridiculous and rudimentary bugs can be a huge waste of time and not worth it.
Some IB tips
I’d like to close with some tips on how to use IB. Many of these methods can also be used in storyboards, so it’s a little bit of a cheat sheet summary while paying tribute to my own previous XIB user career.
Add multiple outlets at once
In IB, selecting and right-clicking a view brings up a gray HUD on which you can easily drag or set events and outlets. You can have multiple of these panels open at once to add all outlets at once. Right click on the panel, drag it around, and then open another one. You’ll notice that the previous panel is also left, so you can easily drag and drop Settings.
Multiple Outlet HUD
Of course, for ibOutlets that are grouped and behave similarly, it would be more convenient to use IBOutletCollection directly.
Visual coordinate distance
The most annoying problem with IB is the problem with IB. In code we can specify x and y coordinates explicitly, but when we switch to IB we’re more likely to be laying out UIView by dragging and dropping. For example, if we need three labels with the same spacing, in addition to using powerful naked eyes to estimate whether the distances are equal, should we just select the three labels, write down their coordinates and then open the calculator to do addition and subtraction?
Obviously don’t be stupid. Try selecting a label, holding down the Option key and moving the mouse over another label. You can see that the distance between the views is displayed in a way that is easy to understand. Not only views of the same level, but also the distance between the selected view and views of other levels can also be displayed.
Displays the distance between views
Select from a set of View hierarchies
For some complex view hierarchies, it is often difficult to select directly in IB. For example, when views overlay each other, it is difficult or even impossible to select the underlying view in the edit view. In this case, the general approach is to open the view hierarchy panel on the left, expand the layer by layer and select the view you want. There is an easier way to do this: hold Cmd and Shift, then right-click over the view you want to select, to create a list of all the views at that point. This allows you to quickly and easily select the view you want.
Select the underlying view in edit View
Add auxiliary wire
Such a great skill must be saved last… Double-click on a view in the hierarchy on the left list, and then the Cmd + _ or Cmd + | add a view on selected with the center of the horizontal or vertical auxiliary line. Of course this guide line can be moved at will. If the students who have done design must understand the significance of this, it will have important reference value for it and design change later.
Add auxiliary wires for IB
Source: onevcat’s blog
\