How to Simplify Complex Message Client Data Processing in Mobile Apps

Complexity of Message Client Computation

In a typical client architecture the lower data service layer is stable while the upper UI layer is volatile, requiring extensive data processing before UI presentation.

Key challenges

Partial local data requiring request‑response streaming.

Change synchronization for push updates.

Multiple data sources (BC, CC, IMBA) needing merging.

Aggregating conversation, message, profile, group and member data.

Bidirectional pagination with state transitions.

Merging updates that replace existing items.

Complex list and tree structures with virtual nodes.

The message client logic covers six core models and accounts for about 25 000 lines of code (≈8 % of the total), creating high‑dimensional branching and recursion.

Objectives

Introduce an abstraction layer to unify data handling.

Reduce code volume by ~60 %.

Achieve bidirectional consistency of data.

Processing flow

The client is divided into data service, logic, and UI layers; the logic layer handles data requests, transformation, context maintenance, async handling, recursion, state management and change synchronization.

Core steps include:

Request conversation/message data and merge callbacks.

Establish relationships between primary data and auxiliary data to produce aggregated results.

Convert data to array/tree structures supporting partial updates.

Respond to insert/delete/update events and ensure consistency.

Handle entry/exit pagination loading and related state.

Support special ordering logic for real‑time data.

Manage exceptions, timeouts, thread synchronization, logging and monitoring.

These steps are classified as computational logic (steps 2‑6) and structured data fetching logic (steps 1 and 7).

Technical solution

Core modules: MergeDispatcher: structures data fetching, unifies changes, handles errors. Calculator: associates primary and auxiliary data, performs multi‑threaded synchronization and change reporting. DataStructure: computes primary data structures. Inject: provides request interfaces and change events for all data. ModelService: exposes load API to UI and orchestrates the modules.

The call chain is: UI → ModelService.load → MergeDispatcher.load (parallel primary data requests) → Inject.load for auxiliary data → Calculator (computation, timeout handling) → DataStructure (state update) → result reporting.

Results

Computation and data fetching are fully decoupled; calculation resides in Calculator, fetching in MergeDispatcher. The logic hierarchy is reduced from “model × interface × structure” to “event × structure”, simplifying maintenance and scaling to any model.

A high‑order function f :: (State1) → (State2, Result) abstracts the state transition, providing a solid theoretical basis for future extensions.

Overall, the approach cuts code size by 60 % and improves consistency, performance, and extensibility of the message client.