One, foreword

In the previous article “Rich Text Editor: Game Character Upgrade ING”, I shared with you the development history of rich text editor, selection techniques and expansion plan. Today I will talk to you about “rich text and editor cross-platform solutions”.

You’ll notice that the title says “rich text and Editors,” not “rich text Editors.” This means that this paper will focus on rich text cross-platform and editor cross-platform two parts of the introduction.

Through the sharing of cross-platform solutions, I hope to bring some help to partners who have cross-platform requirements of rich text editors.

Why cross-platform

For a product, the degree of user demand reflects the value of the product to a certain extent. For rich text editors, the ecosystem of WEB (PC browser, mobile browser), mobile (IOS application, Android application), and desktop (Windows, macOS) can no longer meet users’ needs. At the same time, for the research and development personnel, each end needs a large amount of resource investment to develop repeatability, which is undoubtedly a resource consumption. Therefore, more and more teams begin to seek breakthroughs, establish cross-platform editing ecology, realize data communication on different platforms and different terminals, and show the editing ability with consistent experience.

(Photo from Internet)

Here are some general concepts:

Social type apps

Take the micro-blog scenario as an example: Suppose you post a long article on a computer web version of micro-blog, and then share it with your friends, and find that the content may need to be edited. At this point, the question arises, do you prefer to put down your phone and turn on your computer to edit, or do you prefer to go straight to your phone’s Twitter to edit. I guess most of you will choose to use mobile weibo for editing. Then we can find that in this process, we have gone through several stages: publishing on the Web side, viewing on wechat mini program, and editing on the APP side. The circulation of this process is actually cross-platform operation.

Application of record types

Take notepad applications on mobile phones for example: More and more users are accustomed to using notepad applications to record some life events. Are these records only stored on local devices? NO! If it is only stored locally, the data cannot be retrieved after changing phones or erasing data, which is definitely not in line with the needs of the public. Most of the data of recording applications is stored in the cloud. Using the cloud storage can not only meet the requirements of cross-device data migration, but also bring the added value of cross-platform browsing, editing and deletion.

Above, two application scenarios of rich text editor cross-platform are briefly introduced. It can be seen that rich text editor cross-platform has become an inevitable need. Now that it’s clear why cross-platform is necessary, let’s take a look at how to do it.

Rich text cross-platform

Rich text, which in this case means “data output by the editor.” In essence, the cross-platform approach of rich text allows rich text to display the same effect in its native way across different platforms.

Note: The scenarios explored in this section focus on how rich text HTML on the WEB can present native effects in Android and applets.

HTML can be parsed and displayed in Rich text in Android using html.fromhtml. Wechat applets can also be directly rendered by rich-text rich text components. Since HTML can be displayed across platforms, why do we need to separate a chapter to discuss it? To solve this problem, I will first show you the problems that may occur with HTML data rendering on different platforms:

As you can see from the figure above, HTML has the advantage of being feature-rich and flexible. Because of this, it is difficult to define data rigorously. Therefore, if HTML is used as the data flow, it is easy to have parsing compatibility issues across different platforms.

In order to achieve a consistent display effect across different platforms, there are two schemes for reference:

  • Plan 1: Force HTML into a hierarchy that all platforms can adapt to.

  • Scheme 2: use a common data model that can be parsed by each side, and each side parses the rendering with native components.

Although scheme 1 can transform the source data into HTML that can be parsed by all platforms by enumerating incompatible scene regular replacements, it is not realistic from the perspective of scalability. In that case, let’s take a look at plan two.

A common data model

Given the problems in HTML transformation, a generic data model needs to satisfy the following conditions:

  • Describes the document hierarchy

  • Strictly define the nesting rules

  • Develop data filtering mechanisms

The following figure compares the advantages and disadvantages of using JSON and XML as data models. You can choose according to your project needs:

In the previously shared article, the data model of rich text editor in L2 stage is mostly JSON structure. This section introduces how the JSON data model meets the above three conditions by directly using the previous examples:

After the conditional specification is followed and the data model is defined, the data flow between platforms is shown in the figure below:

The whole process is summed up as follows: take the general data model as the media, get through the data communication between the WEB end and Android, small programs, render pages with native components in each platform, and finally achieve the cross-platform rich text.

This section addresses the problem of how to get the most original display effect of rich text content produced on the WEB side on various platforms. So how do you ensure that all platforms output the same data model? This brings us to the next section, cross-platform editors.

4. Cross-platform editor

The cross-platform editor means that each platform provides functional modules, the WEB side provides typesetting and editing capabilities, and finally runs in the platform-specific browser environment. This section takes the editor implementation of the Android App as an example. The implementation principles of editors on other platforms are the same.

Take note APP as an example, the rich text content editing module runs in the Webview environment provided by Native APP, and its toolbar menu and status display parts are composed of Native APP Native controls.

Why not use a Native editor or a Web editor instead?

First of all, there are more or less some problems if you choose a single editor, such as:

  • The development cost of Native editor to realize complex rich text structure is high, and many functional modules need to be customized.

  • Web editor has limited operation ability in Native APP, and the interactive experience is not as good as Native controls.

So the two “take the essence”, choose to retain the rich text rich flexible typesetting ability of the Web side, and use Native controls to associate user operations, and finally achieve the effect of 1+1>2. Specifically reflected in:

  • Flexible presentation of rich text content;

  • The core editing code of different platforms can be reused to reduce the development cost of cross-platform editor;

  • With system-level control permissions, greatly expanding the ability of the editor composition (voice, picture editing, etc.);

4.1 How to implement a cross-platform editor?

There are two issues that need to be addressed with cross-platform editors:

How does the Native App communicate with the editor running in webView?

How does Native toolbar display different states following cursor position?

First, a look at the cross-platform editor and how modules interact with each other.

  • The editor will open some interfaces, such as setData, getData and execCommand, for Native APP to call and add content to the editor.

  • Native apps also provide interfaces to the editor, such as viewLoad, requestMedia, and updateBtnStatus. The editor can transfer some data or signals to the APP through these interfaces according to its own state, so that the state of various controls in the APP can be refreshed.

  • The Web editor only establishes communication with Native APP, and the data interaction with the server is completed by Native APP.

Below, a few core scenario implementations of cross-platform editors are introduced for your reference.

4.1.1 Page Initialization

The editing page of the cross-platform Editor is composed of the Native APP and the Web Editor in the Webview, which means that the initialization of the page needs the cooperation of two modules.

In general, the rendering speed of Native controls in Native APP is faster than that of Webview. Here, initialization methods provided by Native APP can be called after Editor loaded. Switch the Native APP from the Loading state to the finished state.

Assuming you have a draft saved at this point, you can call the setData method exposed by the Editor directly after the page Load to initialize the Editor data.

4.1.2 Data communication

In the editing process, there is bound to be two-way communication between Native APP and editor. Taking simple expression insertion as an example, the whole operation process is divided into the following steps:

1. Click the emoticon button to switch from the keyboard state to the emoticon selection panel, which is the internal operation process of Native APP.

2. When an expression is clicked, the Native APP is required to actively establish communication with the editor to inform the editor of the operation of inserting the expression.

3. After receiving the instruction to insert the expression, the editor inserts the expression data transferred from the Native APP, and at the same time triggers the internal state refresh of the editor, such as word count and historical record refresh.

4. Since the undo and redo buttons are no longer in the editor, when the history is refreshed, the state of the buttons needs to be reset. In this case, the editor needs to call the state refresh method provided by Native APP to inform Native APP to update the button state.

This completes the two-way data communication between the two modules.

4.1.3 Media Embedding

Media embedding is an essential part of rich text editors, and it is mentioned here separately because cross-platform rich text editors do not normally upload resources to the server through the editor itself. So what’s the processing logic?

The process of selecting Native APP pictures is not described in detail, but directly entered into the part uploaded after selection. After selecting a picture, Native APP directly invokes the interface of the server to upload the picture, and meanwhile carries the selected picture information (local path, width and height information, etc.) to the editor.

As there is a certain time difference between image uploading and image insertion, the editor, after receiving the command of image insertion at the beginning, will process as loading state by default and wait for the signal of the completion of uploading of Native APP.

When the server interface returns the information that the image loading is complete, the Native APP calls the interface provided by the editor in advance to control the refreshing of a certain image in the editor to complete tense. In this way, resources are uploaded and inserted:

4.2 Step on the pit practice to understand!

Of course, not everything has been smooth sailing. In the process of development, I also stepped on some pits, to share with you.

4.2.1 Keyboard control

Warning: Because the Web editor I use still relies on the contenteditable features of the browser, the examples below are not universal and are for your reference only.

The Contenteditable editor automatically calls up the input keyboard on the phone when the cursor is inserted. In some scenarios, such as after inserting an image, the keyboard is expected to be off. However, in practice, the keyboard is invoked by default, meaning that the system keyboard is not controlled by the editor.

For this situation, I tried some solutions and finally chose to adopt a two-pronged approach to add double insurance:

  • Before the Editor insertion operation is executed, the switch between disable editing and enable editing is added, and the automatic recall mechanism of the system keyboard is invalid by taking advantage of the time difference between the switch.
editor.setAttribute('contenteditable'.'false')
setTimeout(() => {
  editor.setAttribute('contenteditable'.'true')},150)
Copy the code
  • Native APP provides the method to control the keyboard to pop up and fold up, and the Editor calls the system capability to achieve freedom of control when needed.
JsBridge.call('updateKeyBoardState',
{ keyBoardState: true/false })JsBridge.call('updateKeyBoardState',{ keyBoardState: true/false })
Copy the code

4.2.2 Resource Failure Retry

In the editor, resource upload failures are equipped with a re-upload mechanism. In a cross-platform editor, re-uploading needs to be triggered in the WEB editor and sent to the Native APP for re-uploading. The premise of uploading a picture by Native APP is to get the local path of the picture. Therefore, in the early design, we need to focus on the following points:

  • When the Native APP calls the interface of inserting pictures in the editor, it needs to inform the corresponding local path of the picture, which is also used as the reference condition for subsequent state refresh and failed retry.

  • Add local path exception failure handling (local image deletion, moving, etc.).

Now that you’ve read this, you have a good idea of how to implement a cross-platform rich text editor. This section only discusses the scenario of Android APP, but it is also true for other platforms. For example, Chromium Embedded FrameWork (CEF) can be used to provide browser environment in the client of desktop platform (Windows, Mac). Interested partners can start to try.

Five, the summary

This article focuses on the rich text cross-platform and editor cross-platform, analyzes why to achieve the rich text editor through cross-platform scheme, and how to achieve the two kinds of cross-platform, which focuses on the core process and practice of cross-platform editor.

At this point, we are nearing the end of sharing rich text editors. Through the introduction of this content, I hope that when we meet such needs, we can learn by analogy and smoothly land the plan.

The resources

1. Rich-text | wechat opens new Window

2. Technical evolution of Youdao Cloud Note cross-platform rich text editor

Author: Tian Yuhan, Vivo Internet Front-end team