Basic Knowledge (2): Starting with the design UI framework

Say UI can extend a lost thing, light Java has swing,swt/jface and even JavaFX and so on UI toolkit, on the desktop they are not even mainstream, on the web side has canvas, SVG and so on.

Based on these UI toolkit \ Frameworks, there are also a number of common or business UI frameworks, such as draw2d, GEF, Easyui and even domestic echart, egrets, and so on.

These frameworks have different business scope, a programmer's time and energy is limited, you can not grasp all, and can not predict which future will be cavatina, even the current most popular, enough to hit a mouth cannon.

So, what should we learn?

In this section, if we have only one GC (graphic creator\capability), how to design a set of UI frameworks, which we understand, will be easier to learn when learning a new UI framework. At the same time, the analytical ideas mentioned here can also be applied to other types of frameworks, assisted learning.

Remember,1, complex by simple composition, 2, the Constitution has the law .

It can be imagined that the complex framework, scratched to the bottom of the time, but also you should have mastered the basic knowledge. The basic knowledge that different frameworks need may not be the same, but the rules (ideas) are mostly close.

Let's start by defining what a GC is.

Every programmer who has used the UI toolkit mentioned above should have noticed that many of them offer "draw" functionality. In SWT, the ability is Org.eclipse.swt.graphics.GC, and in H5 canvas, it is canvasrender (the object that the canvas Element#getcontext (' 2d ') obtains.

What do they have in common?

You can set ARGB information that can be called to draw pictures, segments, shapes, and so on.

For convenience, this is known as a GC, which is the foundation of the UI framework.

To think about a question, what would you do if you were to draw a GC by itself, as shown in the interface?

Do not think too much, the complete implementation is unscientific, write to decadent, decadent to bald. Let's look at the most common solutions:

The various parts of the interface are taken apart, the same characteristics are grouped together, and each class provides a method for drawing, such as a button, which requires the GC to draw four edges, hatching lines, and the text therein.

Then, let's iterate through all the widgets so that the text is returned to the text, and the button's return button.

Did it suddenly feel simple? This is what the so-called UI framework is doing.

How do I build this UI framework? This article takes the idea is: Object-oriented modeling.

With object-oriented knowledge, you should be able to analyze the following conclusions: controls, the layout of controls, and the handling of various events, these three elements form a basic UI framework.

1. Controls

buttons, text boxes, and other operable objects, and the containers that wrap them, are called controls.

So, we need to create the following objects, which are represented in a tree-shaped structure:

Where parent-child expressions only represent inheritance relationships, control, and composite their entity diagrams, it might look like this:

Of these, control provides two methods:

The Paint (GC) is responsible for invoking the GC to draw itself.

GetBounds () is responsible for providing position, size information for the current control, typically including X,y,width,height.

Composite as a composite control, it has the control of the two methods for the correct drawing itself, but also has a children list, which all contain control, when its paint method calls, should iterate all of their children, Their paint is called.

With this structure, does any UI interface become some sort of single-root structure?

The root node is a root Composite, and the leaf node is a specific control. And then Lenovo's previous print window, its solid structure would probably be like this:

Let's go to activity thinking, what is this data structure? What is the order of the paint () method calls for each control?

2. Layout

Obviously there is a bounds, why also need "layout"?

In fact, bounds (x,y,width,height) can also be regarded as a kind of layout, I call free layout, this layout is not good, the conclusion is too rough to accept it? Probably explain:

you need very precise control of the X,y,width,height four variables , imagine you want to make a two-row four-column table, each cell you have to control their location, bounds information is as follows:

[0,0,100,20],[100,0,100,20],[200,0,100,20],[300,0,100,20],

[0,20,100,20],[100,40,100,20],[200,60,100,20],[300,80,100,20]

So you can deduce a formula, set I to line number, J for column number, single cell bounds information formula for [I*width,j*height,width,height], notice the problem is not, you need to maintain a nested loop for each cell to assign a value.

It takes a lot of effort to control the relative position . It is clear that in this "free layout", the child's range is likely to go beyond the parent's border (since bounds X, Y is currently referring to X, y of the GC used, that is, the base point of the entire canvas), unless you change each child's calculation formula to [i* Width+offsetx,j*height+offsety,width,height], where offset represents the absolute position of the parent.

It is difficult to control scaling . For example, if you want to scale the above table, you need to modify the bounds information, to determine the scaling strategy, such as the overall reduction of a zoom value, the list of formulas will probably become like this [I*width*zoom,j*height*zoom,width*zoom, Height*zoom]

Just stating that one way is not good, does not prove the other way well, a lot of people already think that we can pull out these "formulas" above and sort out reusable code. If there are other layout options, you can also sort out the corresponding reusable code, before the paint application up, not good?

Yes, actually, this reusable scheme \ Strategy, that is, "layout".

The implementation method is described by pseudo code:

define Composite{layoutmanager LayoutManager;/** * Draw*/voidPaint () {layout (); //DoPaint}/** * Execution Layout*/voidlayout () {Layoutmanager.layout ( This);}} Define layoutmanager{voidlayout (Composite parent) {intindex=0; //Traverse all the children, get their layoutdata, modify their position 　　 foreach(Control Child:parent.getChildren ()) {//calculates the offset based on the child's index and layout configurationoffset=Computeoffset (index); //Get Layout data for childLayoutdata Data=Child.getlayoutdata (); //Modify child's bounds information using layout data 　　 data.computebounds (Child,index,offset); Index++;}}}

From the pseudo code above we can see that the control has layoutdata this member function, the container (composite control) has the layout of this member function.

layout is used to specify the types of layouts inside the container (such as the grid type GridLayout), the overall layout plan (the offset object embodied in the code above, providing an offset for the next child needing the layout).

Layoutdata is responsible for the specific arrangement of a child in the whole.

Since the packages in layout and layoutdata are all algorithms (embodied in the Computexxx method), we can flexibly prescribe and take different combinations, such as putting a control in the container's overall center position.

With this done, your UI framework can be used to show the various views.

3. Event Distribution

It's not enough to just show nature, otherwise the UI framework can be called a view frame, and the UI framework should be able to receive various types of keyboard and mouse input.

Take H5 's canvas as an example, we know that canvas can be added mouse \ Keyboard monitoring, you complete the control and layout, click the button control, response to the event is a button or canvas?

Nature is canvas, where the browser knows you have written a "button" out.

For those unfamiliar with the MVC pattern, there may be some confusion about how to respond to an event by "drawing" a fake button.

Let's see this tree again:

The inference is as follows:

1. The bounds of the root container is equal to the position size of the canvas.

2. If the canvas receives a mouse event, the mouse must be located at a control location under one of the root containers.

3, the tree traversal control, you can quickly find out when the event occurs, the mouse on which control.

Given the efficiency of JS's execution on some browsers (I'm not saying), we can also do more optimizations. Here's a point:

1, the introduction of layers (layer) concept, the tree structure to do a horizontal division, the first to find a high layer of control, you can also let some layers of the control do not participate in the search.

2, the control itself set clickable properties , after all, if the speed of the judgment is more than the calculation (x, y) is located in the bounds range faster.

Next I say, how to make the game animation frame, and then should not talk about the UI related things, after all, I do not do this.

Basic Knowledge (2): Starting with the design UI framework