Cross-Platform Rich Text and Editor Solutions

This article, authored by the Vivo Internet Frontend Team, discusses the need for and implementation of cross‑platform rich‑text and editor solutions.

Why cross‑platform? Modern products must serve Web (PC and mobile browsers), native mobile (iOS, Android), and desktop (Windows, macOS) environments. Maintaining separate codebases for each platform leads to duplicated effort and higher resource consumption. A unified editing ecosystem enables data interoperability and consistent user experience across devices.

Two typical scenarios are presented:

Social applications (e.g., posting on Weibo via Web, then editing on a mobile app).

Note‑taking applications where data is stored in the cloud and accessed from multiple devices.

These examples illustrate why a cross‑platform rich‑text editor is essential.

Rich‑text cross‑platform focuses on rendering the same HTML‑based rich‑text output consistently on Android and mini‑programs. Directly using HTML can cause compatibility issues, so two approaches are considered:

Force HTML to a universally parsable structure (limited scalability).

Adopt a universal data model (JSON or XML) that each platform can interpret natively.

The article favors the second approach, defining a data model that describes document hierarchy, enforces nesting rules, and provides filtering mechanisms. Advantages of JSON vs. XML are compared, and a JSON‑based model is detailed with illustrative diagrams.

Editor cross‑platform describes how a Web editor can be embedded in a native app via a WebView, while native UI components (toolbar, status indicators) are provided by the host app. The Android note‑taking app is used as a concrete example.

Key implementation points include:

Page initialization: after the editor loads, the native app switches from a loading to a ready state and may inject draft data via setData .

Data communication: bidirectional interaction between native and editor, illustrated with an emoji‑insertion workflow.

Media embedding: native app uploads images, informs the editor of the upload status, and the editor updates the placeholder accordingly.

Practical pitfalls are shared:

Keyboard control : because contenteditable automatically triggers the soft keyboard, the article proposes two safeguards: Temporarily disable editing before inserting content: editor.setAttribute('contenteditable', 'false') setTimeout(() => { editor.setAttribute('contenteditable', 'true') }, 150) Invoke a native bridge to explicitly show/hide the keyboard: JsBridge.call('updateKeyBoardState', { keyBoardState: true/false })

Resource retry : when an upload fails, the native app must retain the local file path and provide mechanisms for re‑upload and error handling.

The article concludes that the discussed strategies apply not only to Android but also to desktop clients (e.g., using CEF). Readers are encouraged to experiment with the presented concepts.

References

rich‑text | 微信开放文档

有道云笔记跨平台富文本编辑器的技术演进