Code handwriting UI, game between XIB and storyboard, and some tips on interface Builder

I recently came into contact with several new iOS learners who have a common and confusing question about how to create a UI. IOS applications place great importance on user experience. It can be said that the success of most applications is closely related to the interaction design and the beauty and ease of use of the UI. With the development of IOS so far, we can say that in the UI production, we gradually divided into three main genres: using code to hand-Write the UI and layout; using a single XIB file to organize viewcontroller or view; use storyboard to build all the UIS through one or a few files (which will be expanded later. Which method should be used to create the UI is a constant topic in iOS development, and there may never be a unified conclusion. However, the first thing you need to know is that each of the three methods has its own advantages and disadvantages. Therefore, each of them has its own best application scenarios, rather than its own advantages and disadvantages. For iOS development beginners, it is difficult to determine the most suitable UI architecture at a time. In this article, I hope to give some comments through my own experience, in order to help the author to select the solutions that best suit their application scenarios. For laruence, you can also compare your daily usage habits and use cases to see if there are any areas that can be improved or changed. Finally, because I am most used to and like using interface Builder (later referred to as Ib) and XIB for UI, I have attached some tips for using IB at the end of this article. Code handwriting UIThis method is often widely used by academic geeks or large projects relying on multi-person cooperation. Geek prefers to use code to build the UI, because the code is typed on the keyboard. In this way, you can do the work without enabling IB and without leaving the keyboard. You can focus on the coding environment, it seems cool is very efficient, and no one knows what it will look like when it is not running, it also shows the high and mysterious atmosphere of the programmer's career (this is really not in the dark .. let's think about the scenario where everyone works behind the designer ). A large multi-person collaboration project uses code to build the UI, mainly focusing on the advantages of pure code in version management, checking and tracking changes and merging code is relatively easy. In addition, the Code UI has the best code reusability. If you want to write controls that can be highly reused for other developers, the best choice is to use code to complete the uiview subclass. In this way, further modification and other developers' use will be convenient. Code is also the most powerful, and XIB or storyboard can't do things, but the use of code will eventually be able to meet the needs. However, the disadvantage of Code-based UI writing is also the most obvious. It is mainly a word: slow. First of all, you may need to write hundreds of lines of UI code to complete a not too complex interface than the visual IB. No matter whether you initialize a label, set a frame, or add a target-action, you need to write code, which is not only a waste of time in the early stage, in the future, it will be painful to maintain the location and search of codes in the ERA. Secondly, because you cannot intuitively see the results you can get, you may need to constantly modify the positions and sizes of each view by using cmd + R/CMD +. Even if you use tools such as reveal or restartlessoften, you still cannot easily complete the required layout. In addition, if you need to use autolayout for dimensional adaptation, it is even more difficult to use code for constraints. In many cases, a problem that cannot meet the constraints is enough to run the modification and debugging back and forth for a long time. XibsCompared with code, using IB and XIB files to organize the UI can save a lot of code and time to get faster development speed. If you have been infected by the visual interface of Microsoft Visual Basic or other visual systems, you may doubt the pure lineage and working ability of interface builder, it is recommended that you take a look at these materials to correct the three ideas: the interface builder myth of Jean-Marie hullot. The young man in the suit will build an application with IB at next (you need to flip the wall ). In addition, open the Applications folder on your Mac or the applications of apple on the iPhone. You will be surprised to find that IB is far more powerful than what you see: small to gadgets such as color calculator, big to three sets of iwork, professional applications such as aperture or final cut, all of them use IB to complete UI creation. In fact, IB and XIB have been bundled into the developer Tool Kit since the first release of the ios sdk. After xcode 4, they have been directly integrated into xcode as part of the IDE. The major purpose of XIB design is to achieve good MVC: Generally, a single XIB file corresponds to a viewcontroller, and for some custom views, it usually uses a single XIB and loads it from the main bundle. IB helps you complete the creation, layout, and file ing between views and file owners. For beginners, keeping in mind that XIB files are all view content helps to establish a good MVC concept, so as to avoid or avoid detours during development. The most common problem with the XIB file is that the file content is too complex and has poor readability. Even if it is simply opened and not edited, it may cause changes, resulting in the suffering of merging and submission. In xcode 5, Apple greatly simplifies the XIB file format, making it easy to read and maintain. It can be said that there is no big difference between version management and pure code for XIB files. As long as you carefully read the content of XIB files, you can naturally understand the vast majority, it also tracks and looks for past modification records. Of course, XIB is not perfect. The biggest problem is that the settings in XIB are often not the final settings. In the code, you will have the opportunity to overwrite your uidesign in the xib file. Setting the same attribute in different places will be a nightmare in subsequent maintenance. In fact, IB is still limited. It has no logic judgment and is difficult to configure at runtime. On the contrary, using code is omnipotent. When using XIB, adding some code to supplement and complete the function is almost inevitable. This should be highly valued during development. If XIB is selected, we should try to isolate the work of XIB from the work of code as much as possible: the content that can be completed by XIB should be implemented by using XIB, not to mention that two of the three labels set the font in XIB, but the other one is completed in the code. It is a good method to keep only necessary and few iboutlet and ibaction. StoryboardAfter ios5, Apple provides a completely new way to create the UI, that is, storyboard. Simply put, we can regard storyboard as a set of XIB corresponding to viewcontroller and a set of conversion methods between them. In storyboard, you can not only view the layout style of each viewcontroller, but also clearly know the Conversion Relationship between each viewcontroller. Compared with a single XIB, it has fewer code requirements. Because of the combination of XIB, the speed of understanding and modifying the interface is also greatly improved. Reducing the amount of code is to reduce the amount of bugs, which is also one of the truth in program development. After xcode5, storyboard has become the default configuration for new projects, which also represents Apple's suggestions for developers and future directions. Storyboard is also basically used for demonstration in various sample codes of wwdc2013. It is foreseeable that Apple will continue to strengthen in this respect, and the pure code or single XIB method will not be enhanced. If you do not consider the support for the IOS version (in fact, there are very few apps to be supported from ios4), the biggest problem facing storyboard is multi-person collaboration. Because all UIS are defined in one file, many developers or technical directors of enterprises think that storyboard cannot be developed collaboratively, in fact, this is more of a misunderstanding caused by strangers to storyboard. Although Apple did not explicitly mention it in WWDC, no one requires that the entire project only have one storyboard file. One feasible approach is to split different parts of the project into several storyboards and arrange for developers to take responsibility for their own parts. For example, for an application with four tabs independent of each other based on uitabbarviewcontroller, four storyboards can be used to represent four tabs respectively, and complete development without mutual interference. In this way, there will be no conflict issues. The storyboard API is so simple that the number of methods in the current SDK can be counted by one hand, so the specific method is no longer here. Another challenge for storyboard is the reuse of viewcontroller and the processing of custom views. For the former, there is no essential difference between the VC reuse of storyboard and the VC reuse of code based on the correct encapsulation interface and good design, add scene that is well encapsulated and needs to be reused to the storyboard. For the latter, because the storyboard does not allow the existence of a single view, we still need to customize the UI with a single XIB. This can be said because of the storyboard design philosophy. storyboard emphasizes a hierarchical structure and organizes the uidesign and migration from a global perspective. For a single view, more emphasis will be placed on reuse and customization, but it has little to do with the entire project process. We believe that by grasping this key point, we can have a good understanding of when to use XIB and when to use storyboard. The last thing to say about storyboard is that there are some concerns about storyboard performance. Compared with a single XIB, storyboard files are usually larger, and the loading speed slows down accordingly. However, with the upgrading of devices, the performance gap between iPhone 4 and iPhone 4 is almost negligible. The devices that follow the process will only get faster and faster, regardless of reading or parsing. Therefore, there is no need to worry about performance issues. My views and choicesI used XIB when getting started, because there was no storyboard at that time, and I was not an academic geek who liked the code. Up to now, I have tried all three methods, and I have gained some experience that may not be particularly profound. For me now, XIB is my cheese and I have been using it in my own projects, I can use XIB to build a complex UI that includes custom elements and good component reusability in a very short time. However, after I tried to create a demo using storyboard several times, I decided to switch to storyboard in later projects. On the one hand, because it is indeed the future direction (every time a new project deletes a storyboard, it is annoying ..), currently, storyboard's proprietary preview function and further improvement of autolayout are worth looking forward to. On the other hand, it also feels that it will be difficult to put cheese for a long time, taking advantage of the big revolution of ios7, it may be helpful to update your ideas and methods and place your cheese in another place. For beginners, I don't recommend using code directly for UI creation and layout, because lengthy UI code is really boring. Seeing the finished product as soon as possible, at least seeing the prototype as soon as possible, is an effective motivation to stay interested, continue to deepen and engage in the profession. Therefore, if conditions are possible, select storyboard under the guidance of laruence for rapid building (or if it is single-person development, it is easier to consider multiple storyboard collaboration ), it will be a good choice for getting started. The latest tutorials and documents have gradually become more inclined to storyboard, and the questions about storyboard will be paid more attention to so, so that more information will be available for reference at the start. This does not mean that you do not need to care about the code ui or XIB, because when using storyboard, you can only use the code and customize a single view, but you still need to access them inevitably. One of the suggestions here is that although you do not rely on code for UI creation, it is necessary to understand and master how to use pure code to build the UI from the beginning: including creating a window, initialize viewcontroller, add necessary views, set their properties, and add and process various responses and responser links. Now it is very easy to get started with iOS development. xcode and XIB/storyboard help developers hide too many details, but if you do not understand what underhood is, if these XIB/storyboard functions like this, it is often stuck in some silly and elementary bugs that cannot be found in the north. This is actually a huge waste of time and is not worth it. Some IB tipsFinally, let's end with some tips on using IB. Many of these methods can also be used on the storyboard. So while paying tribute to my previous XIB user's career, it is also a little memo. Add multiple outlets at the same timeIn IB, right-click a view and a gray HUD will appear. You can easily drag or set the event and outlet on it. You can open multiple such panels to add all outlets at one time. Right-click the panel, drag it, and open another one. You will find that the previous panel is also left, so that you can easily drag and drop settings. Multiple outlet HUD, of course, for iboutlet with similar behavior in groups, it is more convenient to directly use iboutletcollection for processing. Visual coordinate distanceThe most annoying problem with IB is to solve it. When using code, we can clearly specify the X and Y coordinates, but when switching to IB, we need to drag and drop the uiview for layout. For example, three labels with the same interval are required. Apart from using the powerful naked eye to determine whether the distance is equal, do you have to select three labels separately, write down their coordinates and open the calculator for addition and subtraction? Obviously, don't be so stupid. Try to select a label, then press and hold the option key and move the mouse over another label? You can find that the distance between views is displayed in an easy-to-understand manner. The distance between the selected view and other view levels is also displayed. Display the distance between views Select from a group of view levelsFor some complex view-level relationships, it is often difficult to choose directly from IB. For example, when the view overwrites each other, it is difficult to select the underlying view in the editing view. At this time, the general practice is to open the view level panel on the left side, expand layers, and then select the view you need. In fact, we also have a simpler method: Press CMD and shift, and right-click the view to be selected to list all views in the click position. In this way, you can quickly select the desired view. Select the underlying view in the edit view. Add guidesSo high skills must be put at the end... Double-click a view in the Level list on the left, and then run cmd + _ or cmd + | to add a horizontal or vertical guides to the selected view. Of course, this guides can be moved at will. If you have worked on the design, you will surely understand the significance of this, and there will be important reference values for it and the design change in the future. Add guides for IB Source: onevcat blog original address: http://www.cocoachina.com/applenews/devnews/2014/0102/7640.html