How to properly write a good interface

The writing interface can be said to be the basic skill of every mobile app developer, and it's a hurdle for a qualified mobile app developer to go around. But just as not every developer can become a qualified developer, I found in different teams, very few people can write qualified UI code, and very strange, on many developer forums to see our mobile developers more focused on a control or animation, but rarely see the deep anatomy of the UI mechanism To guide the development of UI articles.

Due to the interface is too extensive, this article can not be exhaustive, one by one, so this article based on the point, in-depth analysis of the iOS UI system is not attached to the importance of the mechanism, to help the reader of the iOS UI system to understand the overall, and then Vitalize, Extend to the discussion of UI logic design and architecture design patterns; Finally read the text and had thinks, the design and development of an efficient, easy-to-use, smooth UI module.

This section reads as follows:

1. Fundamentals and Nature: The three modules that illustrate the universal UI system give the reader a clear understanding of the UI system as a whole.
2. View: The internal mechanism of deep view, the relationship between view and layer, and offscreen Render;
3. Viewcontroller: Explain the role of Viewcontroller in UI system, and Viewcontroller application and practice in UI architecture design;
4. MVC, MVP, MVVM: Simple analysis of three kinds of mainstream architecture design patterns and their similarities and differences, and simply put forward some architecture design ideas and ideas;
5. Summarize.

There is no definite link between the chapters, and readers can choose the chapters of interest to read.

1. Fundamentals and Nature

The biggest difference between terminal app development and backend development is that most of the logic of terminal development is to provide the user interface for human-computer interaction, the so-called UI (User Interface). So all the UI architecture focuses on three modules: interface layout management, rendering and animation, event response;

1.1 Layout Management

That is, in the specified coordinate system, according to a certain level order position size in the container. A UI system must have a coordinate-based layout management system, whether it's windows, Sysbian, or Andorid, IOS. The good layout management mechanism directly affects the difficulty degree of the interface logic realization;

The UI coordinate system of the app we're currently exposed to is two-dimensional, and the 3D game we're playing now is limited to two-dimensional display screens, so it's essentially a three-dimensional mapping projection on two dimensions. We have been moving towards a higher dimension: holograms, HoloLens, and so on. In this scenario, the layout management of our building interface is likely to be based on true three-dimensional coordinates in the future.

1.2 Animation and rendering

The UI is called User Interface because the UI provides information to the user through visual presentation. The presentation of this information requires a series of complex calculations, the final operation of the liquid crystal display on the display, this series of processes is rendering and animation;

Is the process of rendering the application interface to the presentation:

Quoted WWDC2014 #419 advanced Graphics and animations for IOS Apps

Here does not expand, the recommendation has not seen the students are serious to watch, can well understand the rendering process and interface optimization;

Recommended Information:

• WWDC2014 #419 Advanced Graphics and animations for IOS Apps
• Objc.io article: #Objc Issue 3:views-getting Pixels onto the screen

1.3 Event Response

In addition to the display of information, the UI also needs to receive and respond to user clicks, gestures, shaking and other events, after a series of actions to update the display information, display to the user, the correct and timely response to the user's actions and give feedback, is a good user experience guarantee. One of the main reasons why Android devices generally give people more sensation than iOS devices is that the iOS system will respond to user events by placing the highest priority on the primary thread.

1.4 UI System Architecture

From the overall understanding of the above three aspects, you will have a systematic understanding of the UI architecture. The UI system architecture in iOS is as follows:

Quoted WWDC2014 #419 advanced Graphics and animations for IOS Apps

2. View

UIView is the most basic control in Uikit, just as NSObject is basically the base class for all classes in the Cocoa Library, UIView is also the base class for all interface controls in Uikit. As long as you want, you can even use UIView to build your app (but iOS9 is bound, you must set Keywindow Rootviewcontroler).

Generally speaking, mastering commonly used UIView sub-class controls (such as UIButton, Uiimageview, Uilabel, etc.) is sufficient to cope with the 90% interface coding needs. But to write an efficient, graceful interface code requires a deeper understanding. In order to go deeper, this article assumes that you have a preliminary understanding of UIView, at least a few complete pages have been written, and based on this setting, the discussion focuses on the following points:

1) UIView and Calayer: Discuss the calayer behind UIView, understand the relationship between Calayer and UIView and the rendering process;

2) offscreen Render: Describes what is offscreen render (off-screen rendering), and some ways to avoid off-screen rendering;

3) Uiresponser: Discusses the parent uiresponser of UIView and Uiviewcontroller, and analyzes the event response chain on iOS devices;

4) Design and practice: In combination with my own development practice experience, explain the good design practice rules in UIView application;

Reference: View Programming Guide for IOS

2.1 UIView and Calayer

We should all know that each uiview contains a calayer, even if you have not seen directly calayer, you should have used. For example, to a view cut a fillet: view.layer.cornerRadius = 5.0f; ; Add a border: view.layer.borderWidth = 1.0f; view.layer.borderColor = [UIColor darkGrayColor].CGColor; , the layer used here is calayer.

Calayer is the class in the Quartzcore library, which is the most basic drawing unit on iOS, and UIView is just the encapsulation on the Calyer, more accurately, UIView is a simplified version of Calyer, plus the collection class for event handling. Event handling we'll discuss in the next section, how does the Lite package understand, and why not use Calayer directly?

First of all, as described in the previous paragraph, Calayer is the most basic drawing unit, each uiview has a Calayer variable ( public var layer: CALayer { get } ), UIView rendering essence is the rendering of this layer. We can look at the class definition, there are many attributes (variables) and methods can be found in the almost identical correspondence, such as property variables frame , hidden methods, public func convertPoint(p: CGPoint, fromLayer l: CALayer?) -> CGPoint etc., but there are more property methods are not UIView, here are listed. We can see that uiview is actually exposing common interfaces (properties and methods), making uiview easier to use.

Secondly, we know that the iOS platform Cocoa Touch is originated from the OS X platform Cocoa), on the basis of Cocoa to add a mobile phone device for gesture recognition, animation and other features, but from the bottom-up, Cocoa Touch and Cocoa share a set of underlying libraries, This includes quartcore.framework, but Quartcore.framework was designed for OS X in the first place, so some of these features are not suitable for mobile device development, such as the most important coordinate system. Therefore, it is not difficult for us to understand why uiview/nsview a layer of encapsulation on calayer.

Above, is the main relationship of UIView in Calayer.

2.2 offscreen Render

When you are still ignorant of the development in the early days, in writing Uiscrollview and its subclasses (UITableView, Uicollectionview), will encounter rolling is not smooth, often lag situation; You study the code carefully and find that your logic code is put into an asynchronous thread, The main thread to do is the rendering interface of the live, why will Kaka? Then you want the veteran to ask for help, the veteran will let you get rid of the fillet, translucent and shadow, and so on, the app again silky smooth; you don't know why, ask the veteran, he may be very detailed to explain to you, and then you smattering place nodded, the brain is a vacant; Perhaps you vaguely remember a word: off-screen rendering (offscreen render). So what exactly is offscreen Render? Why does offscreen render cause stuttering?

In section 1.2 of the first chapter, we refer to the flowchart of rendering, so we'll go deeper and look at the most basic rendering channel flow:

Quoted WWDC2014 #419 advanced Graphics and animations for IOS Apps

注：iOS的GPU渲染机制是Tile-Based的，而Tile-Based GPU也是现在移动设备的主流；

Let's take a look at the render pass process that requires offscreen render:

Quoted WWDC2014 #419 advanced Graphics and animations for IOS Apps

In general, OpenGL will render the app to render server animation directly rendering (basic tile-based rendering process), but for some complex image animation rendering can not directly render overlay display, but need to command Buffer sub-channel after rendering and then combined, during this combination, some render channels are not directly displayed, compared to the basic render channel flow and masking render channel flowchart, we can see that masking rendering requires more rendering channels and merging steps These channels (such as pass 1 and pass 2) that are not directly displayed on the screen are offscreen Rendering pass.

offscreen render why lag, from We can know, offscreen render need more render channel, and different render channel between the time spent a certain period of time, the GPU will be idle, when the channel reached a certain number, the performance will have a greater impact ；

What are the conditions that will offscreen render?

1) drawRect2) layer.shouldRasterize = true;3) 有mask或者是阴影(layer.masksToBounds, layer.shadow*)；4）Text（UILabel, CATextLayer, Core Text, etc）...

Note: Layer.cornerradius,layer.borderwidth,layer.bordercolor does not offscreen Render, as these do not need to be added to mask.

For more information on offscreen render and animation graphics optimization, please watch WWDC carefully.

Reference:

• WWDC2011 #121 Understanding UIKit Rendering
• WWDC2014 #419 Advanced Graphics and animations for IOS Apps

2.3 Design and practice

The above sections discuss concepts that are often encountered during the development process, but are not easy to understand in depth. Next, I want to break away from the specific concept of view, I talk about my view design and development of some practical experience;

2.3.1 Thin, flat view hierarchy

Complex view hierarchy results not only affect rendering efficiency, but also cause code bloat, which can cause unpredictable problems and difficult to locate; how about maintaining a thin, flat view hierarchy? The principles are as follows:

1) Use the system's native controls as much as possible;

If you implement an icon and title up and down the layout of the button, many people are accustomed to using a view contains a UIButton and a uilabel. In fact, the more recommended way is to adjust the Uibuton of the Contentinset/titleinset/imageinset three parameters to achieve this effect, very simple, and the title has UIButton on the way and characteristics of the display, such as can be set highlighting color, etc.;

Another example of a complex layout structure of the scrolling interface, some developers will feel that the use of Uitableview/uicollectionview implementation will be more complex, some effects may not be achieved, with their base class Uiscrollview to achieve, Having built a large set of wheels, the code may also become very complex; in fact, according to my experience, it is possible to use Uitableview/uicollectionview to achieve this effect by rewriting or adjusting internal properties, after all UITableView/ Uicollectionview is a subclass of Uiscrollview that does not decrease in functionality and is more powerful, and we can also use the existing data source and delegate mechanisms to achieve design decoupling.

Other common also have Uinavigationbar, Uitabbar, Uitoolbar and so on;

2) Reasonable Add/remove dynamic view;

Some view is dynamic, is occasionally displayed, occasionally hidden. There are two ways to handle this type of view: adding or deleting, or showing/hiding. There is no standard answer, the individual is more recommended to add and remove the processing method, that is, when necessary to be added to the corresponding Containerview, when not needed to delete it. This can be combined with lazy loading, and can also avoid the interaction of two dynamic view, such as Tablefooterview, or the wrong load view. But this is not the only way, if the view level of the dynamic view is relatively simple, and need to animate dynamic display, then using show/Hide is also a good way to handle.

2.3.2 Universal control;

Every programmer can build their own code base, and in the same vein, every mobile development programmer can build their own common control code base. The controls within this library can be written by yourself, or they can be excellent third-party open source controls. The creation of a control library, in addition to avoiding the ability to reinvent the wheel, greatly improves our development efficiency, and is more important: Mastering interface design decoupling, even architecture knowledge and experience in application, transformation, and refactoring.

The UI design, interaction, layout, and color-matching of each app are often very diverse, but it's not always possible to get out of the realm of mobile apps, and it's decided that some of the common controls will be consistent in their interactions, so that users can use them quickly and easily based on their experience with mobile apps, which is the mobility of the app. So the general purpose of the control of the scenario is often very "generic". For example, drop-down refresh, load more, Tab Bar, tip tips, load error reload, and so on. When you apply these controls to a new app or function module, you'll think about how to make the controls more generic--without affecting the old logic and applying the new requirements, which is a great workout for the architectural design of the interface.

2.3.3 Rational use of VC in alternative view combination of complex interface;

In the interface development process, we often encounter complex interface, such as multi-page interface, a variety of layout to display multi-service home page, etc., but because a lot of developers have been "a screen is a VC" this beginner's habit of serving as dogma, write a pang large view, coupled with complex logic code, This piece of code is likely to evolve into a restricted area where no one dares to move. A VC can manage multiple VC, so the rational use of VC to replace the view of complex interface combination, not only can be cut into a complex interface smaller granularity, logical code is also reasonable division of logic, easy to maintain and reconstruct, and rely on the mechanism of VC, but also view and data dynamic loading management.

The discussion of light VC in the next chapter is the extension of this section of knowledge.

3. Viewcontroller

The previous section on view has discussed the iOS interface mechanism, which is mainly to talk about design problems and basic specifications in the process of writing interfaces;

Viewcontroller is a very important concept in IOS, which is the most common module we interact with in the development of the interface, its role in an app, and the clear and accurate description of View Controller Programming Guide for iOS:

1) View Management: Manage view;

2) Data marshalling: manage the information;

3) User Interactions: Responds to users ' interactions;

4) Resource Management: Management resources;

5) Adaptivity: Adaptation to different screen size space changes;

As you can see, Viewcontroller has so many things to do that it causes Viewcontroller to become very prone to code bloat, logic confusion, and so on, according to personal experience, a Viewcontroller class has a valid code of more than 500 lines, This viewcontroller will become difficult to maintain, but in fact, in the development process, often encountered on the 1K line, or even 2~3k line Viewcontroller class, when a Viewcontroller class reached the 2~3k row, It means that the other developers take over the module to modify things, has been unable to scroll to locate the code, only through the search;

Therefore, in the interface development, Viewcontroller need to pay special attention to the module design, the different modules in accordance with the logic of a certain split, that is, decoupling, but also to prevent the Viewcontroller module code expansion. This is the concept of light VC;

3.1 Light VC

The light VC is a very hot noun for the last two years and now seems to have become an industry norm or convention. As mentioned above, a VC class, if the valid code is more than 500 lines, it means that the class is becoming bloated and difficult to maintain, to reach 800 lines, only through the search to locate the code, refactoring is imperative;

About Light Vc,objc.io The first chapter #issue 1:lighter View Controllers, which reflects the importance of this concept. Mastering the concept of light VC is basically an iOS developer from beginner to advanced essential skills. #Issue 1:lighter View Controllers describes several common ways to build a light VC:

1) The data source and other complex interface from the VC stripping;

2) Abstract The business logic code into the model layer;

3) abstract complex view into a separate class;

4) Using VC containment features, a VC in the logical separation of the interface module into a number of sub-VC;

To design a reasonable and easy to understand and maintain the light VC structure, need to master the knowledge of light VC and have some practical experience. In the following cases, you might consider designing a VC or re-structuring more modules for a light VC structure with more classes:

1) as described above, the code exceeds 500 lines;

2) The data source of view in VC comes from many different places;

3) VC has a number of complex view, need to display data entity class is more complex;

In short, when you feel that your VC has become bloated, then you can try the practice of light VC, practice only harvest.

Design of 3.2 VC

The VC is more focused on design and management than the view focus on layout and presentation. This section provides an example of a VC design in a complete app.

Let's look at a common example of UI architecture design:

This figure should be very easy to understand: the bottom is a slide drawer control, the drawer contains the app content to show the Tabbarcontroller and set the Vc;tabbarcontroller sub item VC contains the corresponding business list VC, click List VC into the details of the view; some of the details of VC is to use Webviewcontroller to display content. Very simple, isn't it? The following is a description of the design's insights:

1) root Viewcontroller, is the root of the entire app window VC, which is a lifecycle and app the same VC, that window Rootviewcontroller is the only and always exist, Need to switch the scene is the use of this root VC control sub-VC switch to achieve (common in the scene: the need for strong login, that is, after the login to use the app, login after the success from the login interface switch to the main interface, the login VC and the main interface VC should be the root VC sub-VC, by Root VC control to switch). This Rootviewcontroller recommendation is a uinavigationcontroller that ensures sufficient extensibility and provides a richer interface for interactive selection. This root VC life cycle is consistent with the app, such a burst of flexible branch interface can be very good display on the root VC, such as the global loading hint, OpenURL branch adjustment, etc.;

2) Main viewcontroller: Main interface, is the root interface of the main business presentation interface. The VC and ROOTVC function will be easily coincident together, but it should be noted that the VC does not always exist, but when switching to some specific branch, the VC will remove from the root VC, such as the above-mentioned strong login app, login interface and the main interface will need to switch. In addition, the VC isolated the main business display interface VC and root VC, easy to complete the application of the overall interface style revision and reconstruction. For example, the present is a slide drawer +tabbar combination, then to the next version of the sliding drawer removed, then only need to use Tabbar replacement Drawermenu VC location in the main VC, It does not affect the interface (such as push, etc.) displayed by other branches in ROOTVC.

3) Tabbaritem viewcontroller: As Tabbar controller's child item VC, usually designed as Navigationcontroller, to manage the VC stacks within each tabbaritem. Note: If you need to hide tabbar when push enters Level two interface (Detail VC), only need to set two-level VC, hidesBottomBarWhenPushed = true if you want more flexible control tabbar, such as in the three-level page to show Tabbar (this scene should be very rare), Or your tabbar is custom, can refer to I write an open source control mznavtab;

The UI structure of the example in this section is a very general UI structure where more than 60% of the apps in the market are similar UI interactions (statistics come from a personal phone) and if your UI interaction is similar and your UI structure is confusing, try this UI architecture design.

4. MVC, MVP, MVVM

MVC:

MVP:

MVVM:

Note: Dashed arrows: Indicates a non-strong dependency between the two. Like the MVC diagram, view is not directly linked to model.

Dashed rectangle: Indicates the implicit existence of the module in the corresponding architecture design. The general architecture does not have this role, but based on the iOS platform, this is an indispensable part;

This article does not intend to describe the concepts of MVC, MVP, MVVM, and several common architectural design patterns here, and the above three graphs are basically able to clearly compare the differences between the three. It may not be the same as what you see online, because the above three charts are more based on the iOS platform.

4.1 MVC

The MVC design pattern diagram We first saw might look like this:

Quoted from [Msdn#asp.net-single-page Applications:build Modern, responsive Web Apps with ASP (https://msdn.microsoft.com/ en-us/magazine/dn463786.aspx)

And Apple's official MVC design pattern diagram is this:

Which of these graphs is really MVC? My answer can only be: all of it.

MVC has been developed from the Xerox Parker Lab and has been applied to a variety of application development areas: Web apps can be used with mvc,ios/android/windows client applications as well as Mvc,web front-end and MVC, and so on, which covers almost all of our common areas of development, So MVC has actually gone beyond his original design, based on the fact that all the applications involved in the show can be MVC, except that the different platforms differ slightly in design. and the MVP and MVVM, is just a derivative of MVC, in addition to the two, there are we have not seen how hmvc, MVA and so on.

4.2 Model Layer

Before I talk about MVP and MVVM, I want to first identify a concept that is often misunderstood: Model. Because the word model is too generalized, such as data model, database model, which leads to the concept of model this understanding of differentiation, simply said, is to be played bad. Aside from the rest, let's take a look at the common definitions:

Wikipedia's definition :

The central component of MVC, the model, captures the behavior of the application in terms of its problem domain, independent of the user interface.[11] The model directly manages the data, logic and rules of the application.

the definition in MSDN (https://msdn.microsoft.com/en-us/library/ff649643.aspx) :

Model. The model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller).

The above two definitions are basically the same: Model, which manages the behavior and data of the application.

Then look at the definition of Apple's official document Model-view-controller :

Model Objectsmodel objects encapsulate the data specific to a application and define the logic and computation that Manip Ulate and process that data. For example, a-model object might represent a character in a game or a contact with an address book. A model object can has To-one and to-many relationships with other model objects, and so sometimes the model layer of a Application effectively is one or more object graphs.  Much of the persistent state of the application (whether, persistent state are stored in files or databases) should reside in the model objects after the data was loaded into the application. Because model objects represent knowledge and expertise related to a specific problem domain, they can is reused in Simila R problem domains. Ideally, a model object should has no explicit connection to the view objects that present it data and allow users to Ed It is data-it should not being concerned with user-interface and presentation issues.communicAtion:user actions in the view layer that create or modify data is communicated through a controller object and result I n the creation or updating of a model object. When a model object changes (for example, new data was received over a network connection), it notifies a controller object , which updates the appropriate view objects.

Although Apple's official document defines the model Objects, it is also meant to encapsulate the data and to manage the logical calculations associated with the data;

So here's a clear idea: in the MVC design pattern, the model is a layer, not just a data model class. In general, the model Layer contains data models and logical calculations related to managing those data, such as local data changes, data caching, and business logic such as requesting data from the network. For this question, you can also refer to this article: "iOS application architecture on view layer organization and invocation scheme." But one thing to note: This article is more inclined to think about model from the model object, because the example in the model is to extend the business interface from the data model, and I prefer to think about the model from the model layer. The model is not limited to data models, it can be data management classes (various manager), request queue management, and so on.

4.3 MVP VS MVVM

Previous section on the model layer recommended article "iOS Application architecture talk about the organization and invocation of the View layer" the MVC and MVVM are very detailed discussion, is a very good article, recommend you read, then this section to say MVP, And why I'm more inclined to choose MVP as the design framework in the app architecture design.

What is the difference between the MVP and the MVVM two graphs that were presented at the beginning of this chapter?

MVVM's VM (view Model) to V (view), more data binding than MVP P (Presenter) to V (view). That is

MVP: is a variant of MVC, where the definition of model and view is consistent with MVC, the difference is that the controller of MVC is the management of a set of model and view of the interaction between the logic, is a manager , while the presenter (the display) is the model in the view between the connector, the specific module for the view to provide the corresponding formatted model data, the view in the behavior of feedback into model. So the controller in MVC typically manages one or more model and one or more view, while the presenter is a m-p-v-to-single, finer granularity and better decoupling.

From the definition of MVP, you will find that MVP is very similar to MVVM, and the role of presenter with view model is basically no different, except for the binding mechanism mentioned earlier. But the binding mechanism has both obvious and powerful advantages-automatic connection to view and model, and obvious drawbacks-higher coupling and more complex code logic; but it's a sigh of uncertainty: MVVM is hot on the iOS platform with Reativecocoa, The MVP on the iOS platform is almost standard on Android (Android5.0 introduces data binding support, and MVVM has a new development on the Android platform).

Why do I tend to be MVP? It's just the convenience of two-way binding with MVVM, and I'd rather have more flexibility and extensibility in my app design. There is no perfect architecture design pattern, only the design patterns that apply to your app business scenarios and teams. For example, the data logic is not complex, more attention to visual display of the application, the original MVC is often the best solution. All of the variants derived from MVC are for Solve the problem.

4.4 Architectural Design Pattern Application

Whether MVC, MVP or MVVM is a model that guides our architecture design, it is not mechanically, and in practical applications, there is always a different understanding of these design patterns and the need to make the necessary adjustments to the needs of the project, and more importantly in the architecture of our app. Dealing with the relationship between Model-view-controller is only the foundation, and the main challenge comes from complex business logic and scenarios, which is where the architect's capabilities lie.

A recent article written by Don Qiao, "Misunderstood MVC and the deified MVVM", discusses the practice of MVC and MVVM, which should reflect the idea of the mainstream architecture of mobile, in which the 网络请求层、ViewModel 层、Service 层、Storage 层等其它类 extraction design determines the merits and demerits of an app architecture design.

For the architecture design, I am ready in the next article, combined with my design experience at both ends of ios/android, to do an in-depth discussion, and give their own design examples, for your discussion reference. Here are some of the most frequently thought-out points in architecture design as a primer for the next article:

1) architecture is to understand the decoupling, the more loose coupling represents the more parts of the layer, but people's thinking is always more willing to accept linear thinking, how to solve this contradiction?

2) in one app, a unified (consistent) architecture design can make logical code more robust, more conducive to team members communication and project maintenance, but how to solve the contradiction between it and flexibility?

3) Does the architecture design contain only logical hierarchies? Need to design data flow and multithreading?

4) Several major principles in the design pattern;

5 Summary

The above four chapters, first from the UI as a whole, to analyze uiview several important mechanisms, and then discuss how to use good VC this UI important management role, and finally ramble about MVC/MVVM/MVP several architectural design patterns of similarities and differences and practical application, want to pass vitalize, Let's take a closer look at the concrete implementation and get out of the picture, looking down at our app to develop a more holistic core.

Reference reading:

• WWDC2011 #121 Understanding UIKit Rendering
• WWDC2014 #419 Advanced Graphics and animations for IOS Apps
• IOS Developer Library#view and Window Architecture
• IOS Developer Library#uikit Framework
• IOS Developer library#getting Started with Graphics & Animation
• #Objc 3-view

• #Objc 1:lighter View Controllers

• Misunderstood MVC and the deified MVVM

• Application architecture of iOS on view Layer organization and invocation scheme

How to properly write a good interface