How a Unified Popup SDK Streamlines Mobile App Dialog Management

Project Background

1.1 Background

Pop‑ups are a common interaction method in any app. As business scenarios increase, the main store app accumulates many pop‑ups with diverse styles, interactions, and priority levels, making maintenance painful. A unified technical solution was created to manage and reuse these pop‑ups efficiently.

1.2 Pain Points

Multiple pop‑up types, UI styles, tangled code logic, hard to maintain.

Asynchronous logic and unclear priority boundaries.

Rigid sequential dependencies requiring releases for adjustments.

Low reuse due to page‑specific pop‑ups.

Window layer level issues.

Data sources vary, leading to coupling and redundancy.

1.3 Scenario Example

Scenario‑1: A pop‑up appears, then B, then C… The question is whether B or C follows A, and how button events affect subsequent logic. Such cases are common and cause confusion across teams.

Project Goals

2.1 Before Improvement

Multiple parallel pop‑ups on the home page (upgrade, privacy, location) compete for screen space; priority needs redefining.

Pop‑ups are attached to a high‑level window, causing them to appear on non‑home pages and requiring hide‑show handling during navigation.

When pop‑ups have mutual exclusion or ordering requirements, code support is low, reducing acceptance rate and increasing maintenance difficulty.

Existing manager class is tightly coupled with the home page, requiring frequent calls in lifecycle methods.

All pop‑up click events are exposed externally, even when unnecessary (e.g., upgrade or privacy pop‑ups).

Each pop‑up has a different interface, some from network, some local.

2.2 Project Objectives

Unify pop‑up templates and logic, driving design standards and interaction consistency.

Integrate data, enable backend dynamic configuration, and schedule display across multiple dimensions.

Support customization to flexibly meet product needs.

Provide self‑contained network functionality, allowing business sides to use without handling data or requests.

Maintain a highly extensible, independent SDK with low‑cost integration for other business scenarios.

2.3 Industry Reference

Most solutions are template‑based without systematic unified management.

Dynamic data delivery exists but lacks page‑level queue management.

Solutions often prioritize business‑side needs, weakening front‑back co‑creation.

Technical Architecture

3.1 Architecture Design

3.1.1 SDK Panorama Architecture Diagram

3.1.2 Process Description

SDK provides a unified data model for external use; business assembles data.

Local pop‑ups directly construct data models to update the pop‑up queue.

Network, push, and interaction‑generated pop‑ups (e.g., surveys) fetch data based on business needs and insert into the appropriate page‑level queue.

SDK offers interfaces for app modules to trigger the scheduler.

Templates can be invoked via backend‑provided template IDs or custom UI.

Pop‑up actions trigger scheduler callbacks for business handling.

Blocking flags allow business to control automatic pop‑up sequencing.

Lifecycle binding ensures SDK manages pop‑up lifecycles internally.

3.2 Module Responsibilities

The design consists of four core modules: Network, Scheduler, Data Model, and Template Factory.

3.2.1 Network Module

Handles data requests for managed pop‑ups, consolidating logic and enabling dynamic delivery without business‑side API handling.

Provides a generic interface for business to implement; backend configuration drives minimal code changes.

Backend configuration architecture includes business line management and style management (images omitted).

<code>{
  "region": 1,
  "city": 1,
  "stationCode": "MRYX|mryx_lgy1",
  "userId": "666666",
  "business": "优鲜超市",
  "scene": "首页弹屏",
  "type": "pacaet",
  "channel": "iOS",
  "version": "9.9.27"
}</code>

<code>{
  "isShow": true,
  "data": [{
    "name": "天降红包",
    "link": "http://missfresh.cn",
    "type": "WINDOW",
    "image": "http://xxxx",
    "desc": "新人领取30元",
    "priority": 1,
    "popStytle": "centerPop",
    "systemResourceId": "系统模板Id",
    "sceneResourceId": "场景模板"
  }]
}</code>

3.2.2 Scheduler Module

The scheduler core manager maintains a pop‑up model queue, determines readiness based on network response and priority, and handles insertion, removal, and blocking logic.

3.2.3 Data Model

Each pop‑up’s data model unifies diverse backend data into a consistent structure for the SDK.

Priority determines display order.

Blocking flag can prevent automatic next pop‑up.

Template style selects predefined UI; custom templates allow richer designs.

SDK can either render the pop‑up or simply control order, delegating view creation to business.

3.2.4 Template Factory

Provides unified templates for business use and supports external custom UI.

Default templates cover common scenarios; custom templates can be injected as view objects.

Current template styles (A‑G) cover system dialogs, high‑priority agreements, custom containers, bottom sheets, push messages, and splash ads (images omitted).

Technical Implementation

4.1 Integration Flowchart

Introduce and invoke the SDK, registering modules by ID with lazy loading.

Each module creates a pop‑up queue identified by its name.

Queues hold all pop‑ups for the module; built‑in templates receive model data, while custom UI is passed as objects.

After registration, the scheduler takes over (see scheduler flow diagram).

4.2 SDK Core Classes

UnityPopups.h

Exposes header files for external reference.

MFUnityPopupsManager

Core scheduler class; all public methods are defined here.

<code>/** 1 */
+ (instancetype)shareInstance;
/** 2 (reserved) */
- (void)regiestApp;
/** 3 */
- (void)mfRegisteUnityPopupsModuleName:(NSString *)moduleName popupsArray:(NSArray<MFUnityPopupsModel *> *)queue;
/** 4 */
- (void)mfUpdateQueueWaitShow:(MFUnityPopupsModel *)model showBlock:(void(^)())block clickCallBack:(void(^)(MFPopupsBusinessClickType clickType, NSDictionary * _Nullable dic))clickBlock;
/** 5 */
- (void)mfInsertModelWaitShow:(MFUnityPopupsModel *)model showAlert:(void(^)())block clickCallBack:(void(^)(MFPopupsBusinessClickType clickType, NSDictionary * _Nullable dic))clickBlock;
/** 6 */
- (void)mfDissmissPopups;
/** 7 */
- (void)mfUnityPopupsViewDidAppear:(NSString *)moduleName;
/** 8 */
- (void)mfUnityPopupsViewDidDisappear:(NSString *)moduleName;
/** 9 */
- (void)mfUnityPopupsViewDealloc:(NSString *)moduleName;
/** 10 */
- (void)mfUnityPopupsRemoveDiscardObjectPopupsId:(NSString *)popupsId;</code>

Interface

Unified delegate class MFUnityPopupsInterface.h.

<code>- (void)mf_dissmiss;
- (void)mf_customDissmiss;</code>

Macro

Defines enums and module macros such as MFPopupsUIType, MFPopupsPopStytle, MFPopupsPopPriority, etc.

<code>typedef NS_ENUM(NSInteger, MFPopupsUIType) {
  MFPopupsTypeCustom = 0,
  MFPopupsTypeImageAndClose,
  MFPopupsTypeTextAndButton,
  MFPopupsTypeScrollListAndClose,
  MFPopupsTypeAttribute
};

typedef NS_ENUM(NSInteger, MFPopupsPopStytle) {
  CenterPop,
  BottomPop,
  PopPop
};

typedef NS_ENUM(NSInteger, MFPopupsPopPriority) {
  MFPopNormal = 0,
  MFPopHigh
};

typedef NS_ENUM(NSInteger, MFPopupsBusinessClickType) {
  MFSureButtonClick,
  MFCancleButtonClick,
  MFCloseButtonClick,
  MFBlankClick,
  MFPopviewImageClick,
  MFH5LinkClick,
  MFCustomDissmiss
};</code>

Models

Data model properties for pop‑ups.

<code>@property (nonatomic, copy) NSString *title;
@property (nonatomic, copy) NSString *subTitle;
@property (nonatomic, copy) NSString *content;
@property (nonatomic, copy) NSString *image;
@property (nonatomic, copy) NSString *link;
@property (nonatomic, assign) CGFloat width;
@property (nonatomic, assign) CGFloat height;
@property (nonatomic, assign) MFPopupsPopPriority priority;</code>

Project Usage and Results

5.1 Using Built‑in Templates

1. Obtain the module name and inject the pop‑up into its queue.

2. Build the data model with title, style (text+button), priority, and set callbacks for display and click handling.

5.2 Custom Business Pop‑ups

1. Subclass the SDK’s template base view MFUnityPopupsTemplateBaseView to create a custom UI.

2. Implement the delegate to handle click types and perform business‑specific actions.

5.3 Benefits

Development efficiency for pop‑up related features increased by 50%.

Pop‑up code size reduced by 50%.

Clearer logic eliminates historical issues, simplifying maintenance.

Template coverage supports flexible styling.

Unique solution with no comparable industry alternatives.

Project Planning

Future versions will extend support to Flutter, enhance network robustness, enrich templates, and open‑source the SDK (details omitted).

Thoughts and Acknowledgements

Considerations include minimizing code changes for integration and whether to centralize analytics via exposed APIs.

Special thanks to the main store client team for valuable feedback and to the backend team for resource support.