What is Plaster

We often meet such demands in the daily operation of apps. We hope to quickly adjust the page structure and layout, especially for apps with heavy operations, such as shopping malls, which need to be adjusted in real time to meet the online operation strategy at any time. At this time, dynamic layout comes into being. Plaster developed a new solution to such problems. Plaster means the Plaster for the sculpture, and we wanted the frame to be able, like Plaster, to create the pages you wanted to copy according to the product’s appeal.

Design concept

We are all familiar with dynamic design. From the original H5 page, to Facebook’s ReactNative(RN), to wechat’s mini-program, and to the recent Google Flutter, App developers have never stopped pursuing the design and performance of existing solutions. In certain contexts, they do represent the appeal of dynamic developers in certain scenarios. However, these solutions have a common limitation, that is, in order to pursue the completeness of the problem, they are usually relatively heavyweight. Some of the solutions lack performance experience due to the loading and rendering mechanism, so that they are more used to carry the functions of secondary pages.

1. The card atlas on the home page

Is probably in the six months ago, the app launched room card style of the home page, the original design of the above card collection, running process, the adjustment and the demand of the new card style uninterrupted, iterative development can only follow version to adjust, even if it is only minor changes will go step by step development, testing, steps, such as gray level the process down to little more than half a month, More than a month.

Later, the operation students came to the development and asked if they had the ability to put new cards on the home page at any time or adjust the style of existing cards according to the operation strategy, rather than flexibly adjust them only by issuing the client version. We investigated the current commonly used dynamic plan, found that whether the H5 or RN solutions of a class, their dynamic capability is the key code can be released at any time, is geared to the needs of development of dynamic plan, release code means development, testing, gray, and a series of process to complete all run through, obviously is difficult to meet the demands of products and operations.

Therefore, we thought, is there such a dynamic solution: 1. It can be simply developed and tested and put on line without following version iterations; 2. 2, its performance is good, can be put on the home page run; 3. Can be displayed on the same page with developed native cards. Hence Plaster, an operational and product-oriented solution whose dynamic ability is to dynamically adjust page layouts by adding or modifying style Xml and background data without making any changes to the client code. A simple comparison is as follows:

It should be noted that, for Plaster, the lightness of dynamic layout does not mean that dynamic capability is weak, and the amount of dynamic capability depends on the richness of the components registered with the client. 2. Comparison of several dynamic techniques

Positioning technology

To meet this demand, we have defined Plaster’s technical positioning:

  • Dynamic page layout. You can adjust the layout by delivering the layout file and background data.
  • Layout elements are componentized, and the power of dynamic layout depends on the richness of the components supported by the client. Layout elements include basic elements such as text, images, buttons, and composite components such as banners and players.
  • Areas of the page that use dynamic layouts must be flexible with native layouts. That is to say, the scope of dynamic layout can be the whole page, or a single Item of RecyclerView, or just part of the area within the Item.
  • Support dual – end unified layout for Android and iOS.

Ii. The conceptual model in Plaster

To understand how Plaster works, you need to look at some of Plaster’s basic conceptual models.

Page structure

In our daily App development, the list page based on multi-type layout (Android called multi-type Item RecyclerView) occupies a very important position. It is the layout basis of many complex pages, and is also the most common and most used in App. Therefore, most pages can be abstracted into the following structure:

3. Page structure model

Changing or adding an Item to a list is very common in daily development and it is most urgent to implement dynamic layout. Therefore, based on this structural model, we defined Plaster’s two-step technical route: In the first phase, we first supported dynamic layout of item level (including local area) and made it compatible with native layout. In the second phase, we will support the dynamic of the entire Page, which needs to be based on the dynamic of Item.

4. Technical route

Component system

Plaster breaks all the page layouts into components and produces complex pages from any combination of components. Components fall into three categories: basic components, composite components, and streaming components.

  • Base component is the basic unit of the page, which has a single function, including atomic component (similar to Android View) and layout component (similar to Android ViewGroup);
  • Composite component is a custom component for realizing complex functions, whose functions can not be realized by a single basic component. For example, the Video component includes the player View and the control View covering it.
  • The streaming component is a concept abstracted from Plaster. It is a container containing other layouts that implement an MVC-based design pattern and whose display is determined by the delivery data in the background, including the style and number of layouts. The data may be fields directly delivered by the parent layout, or the parent layout may simply deliver the request interface through which the client asynchronously loads the data.

It should be noted that, in addition to the streaming components built into Plaster’s framework, there are currently three general categories of basic and composite components, the most common ones built into Plaster and the less common ones built into Plaster-widget. Components that are not generic are implemented externally by the developers themselves and registered with Plaster. Its components are classified as follows:

5. Layout component system

Third, technical implementation

Xml-based DSL definition

Whether H5 or RN, being dynamic requires a language that describes the structure of the page. H5 and RN have each defined a general programming language (GPL) for completeness of development patterns. Plaster’s technical positioning was not to pursue a complete development model, so instead he defined a lightweight domain-specific language (DSL). There are two main forms of dynamic DSL definition: one is described in the form of Json, the other is described in the form of Xml. Json, because it’s familiar, is cheaper to use, while Xml is more intuitive to organize pages, more concise to describe complex pages, and closer to the Android development model. Therefore, compared with Xml, JSON method has no other advantages except low cost, so we finally adopted XML-based DSL description.

Plaster’s DSL is split into two parts: the layout DSL and the expression DSL. The following figure shows a partial sample of the current layout description of the home page. Flexbox, Image, and Text all belong to the layout DSL domain, while the operation expression with the @ sign in the attribute belongs to the expression DSL.

6. Sample dynamic layout files

Virtual node tree

From an XML file to a page UI layout tree is essentially a mapping process, and for layout performance and reuse reasons, such mapping is not done directly, requiring an intermediary data structure: a virtual node tree. Virtual node tree. It should contain hierarchical information about the tree structure, Flex property information, content after data parsing, and basic rendering information.

7. Node flow

Two – end layout component selection

To maximise consistency in a two-ended layout, Plaster chose Flexbox as the container for the layout based on the following considerations:

  • Flexbox provides maximum flexibility for box model, cross-platform solution, dual end unified;
  • There is localization of good open source libraries in open source environments. IOS end Facebook Yoga open source has been through 10+release iteration, 13.8K + Star, (ComponentKit is also dependent on Yoga), after a long time in the production environment;
  • Android terminal finally choose Google’s FlexboxLayout framework to parse, the framework is also very mature, and iOS Yoga with only a few dual-end adaptation.

The implementation process

The picture above shows the basic concept of Plaster, which is to figure out what Plaster is and what it does. Here’s how Plaster did it. There are no implementation details here, of course, but to give you a general idea in principle.

8. Dynamic implementation principle

The main process consists of several core modules: core engine, download module, expression engine, layout framework, and the whole process is mainly connected by these modules. The process is as follows:

  • The core component loads all registered components at initialization and builds the component tree.
  • The background delivers data bound to the layout ID. The download module compares the local layout cache information to decide whether to download the latest layout file, and if necessary, downloads the file locally.
  • The core module parses the Xml file and builds a template node tree corresponding to the component tree.
  • The core module collects the expression attributes in the node tree of the template, and passes the expression and the data delivered from the background into the expression engine for evaluation. After evaluation, the entity node tree is generated.
  • Entity node tree generates native layout node tree according to the one-to-one correspondence between entity node tree and native component.
  • The layout framework generates the corresponding page according to the page organization mode of the platform based on the native layout node tree, so as to create a complete dynamic layout.

Four, business pilot

Plaster has already tried plasteron on the home page of the Android client, and the official room card shown in the picture below has been implemented with Plaster, which has verified its extensive application prospects, including Xml download, node tree building, express-based data binding, layout framework and other functions.

9. App home page

Five, the summary

This paper describes Plaster’s technical scheme and some implementation principles in a comprehensive way. As there are so many details to be considered in the concrete implementation, many of them can only be described in the overall idea, and we will gradually share some details.