How to show messages without folding

In mobile app push scenarios, the message folding issue directly impacts user experience and message delivery efficiency. This article, based on the AppPush service, explains in detail how to achieve unfolded message display using both Notification and Custom Message types.

1. Message Types and Display Rules Comparison

Notification Messages

• System Default Behavior:

• Use Case: Standard push messages that need to reach users via the system notification bar.

Custom Messages

• Key Advantage:
  Regardless of whether the app is in the foreground, background, or has been cleared from memory, the client-side code can fully control how the message is displayed (e.g., popup position, folding logic).

• Use Case:
  High-priority messages requiring customized interaction (e.g., order status updates, instant messaging).

2. Two Solutions to Prevent Message Folding

Solution 1: Use Notification Messages

(FCM requires app to be in the foreground; EngageLab works regardless of app state)

Principle

Use the group_id field to control message grouping:

• To prevent folding: assign a unique group_id to each message.

Implementation Steps

Supported from Android SDK version V5.0.1 and above

Sample Push API Payload:

              
              {
  "notification": {
    "android": {
      "group_id": "UNIQUE_GROUP_123"  // Unique value prevents folding
    }
  }
}

            

Compatibility Notes

• Only supports FCM and EngageLab push channels.
• Messages may still be affected by system restrictions when the app is in the background.

Solution 2: Use Custom Messages (All-scenario Support)

Principle

Client actively calls showNotification API to render messages and bypass system restrictions.

Implementation Steps

1. Send Custom Message

              
              {
  "message": {
    "msg_content": "Your order has been shipped",
    "content_type": "text",
    "extras": {
      "type": "priority_alert",
      "style": "popup_bottom"  // Custom display style
    }
  }
}

            

2. Client Handles Message (Android Example)

              
              public class UserReceiver extends MTCommonReceiver {
    @Override
    public void onCustomMessage(Context context, CustomMessage customMessage) {
        ExampleLogger.i(TAG, "onCustomMessage:" + customMessage.toString());
        showNotification(context, customMessage); // Trigger display
    }
}

            

3. Custom Display Logic (Prevent Folding)

              
              public void showNotification(Context context, CustomMessage customMessage) {
    NotificationMessage notificationMessage = new NotificationMessage()
        .setMessageId(customMessage.getMessageId())
        .setNotificationId("Your own ID; each notification should be unique")
        .setTitle(customMessage.getTitle())
        .setContent(customMessage.getContent())
        .setgroup_id(customMessage.getMessageId()); // Key field to prevent folding

    MTPushPrivatesApi.showNotification(context, notificationMessage);
}

            

Capability Comparison

3. Notes

• Channel Compatibility

  • group_id functionality currently only supports FCM and EngageLab channels.

• Performance Optimization

  • When sending high-frequency messages with unique group_id, monitor notification bar cache pressure (suggested limit: ≤30 messages per device per hour).

4. Summary

• Lightweight Needs: Prefer using group_id to control folding in Notification messages — low development cost.
• Highly Customizable Needs: Choose Custom Message — allows full control of display behavior via client logic.
• Hybrid Strategy: Use Custom Message for important messages (e.g., successful payment), and manage standard messages via group_id.

By choosing the right strategy, you can significantly improve message visibility and user engagement.