Three basic implementation methods of APP pages: storyboard, xib, code implementation and automatic layout, storyboardxib

Three basic implementation methods of APP pages: storyboard, xib, code implementation and automatic layout, storyboardxib

Three basic implementation methods for APP pages: storyboard, xib, and code implementation.
Of course, without the use of automatic page layout, code implementation can be mixed with storyboard and xib. Let's just say that we only adopt the basic implementation method, rather than hybrid page implementation, you can mix them yourself.
Storyboard is used to achieve the largest installation package on the APP page. If you want to use its powerful functions (page organization logic, which is visible and available), the size of your APP package is only a long tumor, you don't have to worry too much about the size of the installation package. However, many old code farmers are used to writing apps. They do not like such modern tools. They are still using code to implement pages or XIB to implement pages. The usage is indeed not very high.
The APP page installation package implemented by XIB is smaller than the storyboard. Many old coders still love it. After all, it first achieves a visible and Available page layout. I used to encounter a problem that occurs after the willappear function jumps a few page results and returns the intermediate page from other pages, the page starts to show a white screen, and it takes more than 10 seconds. Later, I replaced the page implemented by XIB with code to solve this problem. So there are a lot of people using XIB, so don't be too harsh on the package size.
The APP page installation package implemented using code can be small. The page is very flexible, but you need to adapt a model to a model, so that you can see the effect only when running it. You need to write a lot of code and adapt a lot. It is not like storyboard, and xib is visible. However, there are still many old codes in use. After all, full code implementation allows multiple people to change the same file, which is conducive to development by large teams. When multiple people develop a storyboard or xib page at the same time, you are prone to conflicts. To solve the conflicts, You need to compare the files of similar scripts that are hard to understand. In addition, when storyboard is opened, the xib file is not written or modified. When uploading the configuration library, a message indicating a conflict needs to be uploaded is displayed. So the code implementation is still solid.
When iponet6 and ipone6 plus do not appear, you only need to adapt to the two mobile phone screens. Code adaptation is not very troublesome.
When iponet6 and ipone6 plus appear, they need to adapt to four mobile phone screens. Code adaptation is not very troublesome, and a lot of repetitive work is required.
Therefore, Apple advocates automatic layout. Both storyboard and xib support Automatic Layout. However, once Automatic Layout is adopted, the Code cannot be used to implement the control. Otherwise, the compiler reports an error.
Automatic Layout is visible and not available on one screen. The disadvantage is that storyboard and xib will make the installation package larger and less flexible than code implementation, it is easy for many people to modify a file and conflict with each other, making it difficult for large teams to collaborate. Nowadays, the traffic is getting cheaper. Most people download or update applications in WIFI environments, and the APP update frequency is not very high. Therefore, the APP installation package is not so sensitive, unless the main audience of your APP is the parent (they work outside, it is not so easy to use WIFI ). Automatic Layout is a major trend in APP development. It facilitates rapid APP development and frees you from repetitive adaptation work. Our new project uses an automatic layout, and the APP has been made in a month. There are not so many complicated page adaptation problems. My colleagues who write business logic are far from writing pages quickly, I really feel that automatic layout is a big killer, which can greatly improve the development efficiency. The size of the package he wasted. After all, the traffic is getting cheaper and the labor cost of IOS programmers continues to increase.
After practice, it is proved that a project can be automatically deployed, and the page problem can be solved in a month. Only three types of adaptation are required, namely, three times the figure (iphone 6 plus, iphone 6 s plus) A type of phone, two times figure (iphone 6, iphone 5S, iphone 5c, iphone 5) in a type of phone, a double figure (iphone 4, iphone 4S) in. You do not need to write the code to adapt to all mobile phones. You only need to adapt to three typical mobile phones. The simulator can replace some mobile phone tests, but it cannot represent a real machine test. Some simulators test normally and the problems with the real machine test are obvious. It can be seen that automatic layout saves you a lot of money.
To achieve automatic layout:
1. First, set the automatic layout for the storyboard and xib.
2. Set 2 to 4 Constraints for controls (such as buttons.
3. Set the size of the constraint to be greater than or equal to the value of your constraint.
The actual pixel points and image rate corresponding to the iphone, ipod, and ipad used in development are as follows:
Actual pixel of iphont4:
3.5 inch screens (320*480)
Actual pixel of iPhone T5:
4 inch screens (320*568)
Actual pixel of iPhone T6:
4.7 inch screens (375*667)
Actual pixel of iPhone 6 plus:
5.5 inch screens (414*736)
Actual ipod4 pixel:
4 inch screens (320*568)
The actual pixels of all Ipad images are the same:
768*1024
Vector image Rate
1-fold graph of iPhone T4
Ont4s 2x Diagram
IPhone T5 2x Diagram
Ont5s 2x Diagram
Iphont6 2x Diagram
3-fold diagram of iPhone 6 plus
Ipod4 2x Diagram

Copyright Disclaimer: This article is an original article by the blogger and cannot be reproduced without the permission of the blogger.