CometChat Flutter UIKit

In production, never include the authKey in your client-side code. The authKey grants full administrative access (logging in as any user, creating/updating users) and can be easily extracted from a decompiled APK or IPA.

The Secure Workflow

1. Server-Side Token Generation: Your backend should generate a server-minted authToken for the user.
2. Client Login: Use CometChatUIKit.loginWithAuthToken() instead of CometChatUIKit.login().
3. User Management: All user creation and profile updates must be performed server-side, not via the Flutter client.

Handling Token Expiry

If you have configured token expiry in the CometChat dashboard, handle the error in the onError callback to trigger a token refresh from your backend.

// ✅ SECURE: Use server-minted tokens in production
final settings = (UIKitSettingsBuilder()
      ..appId = appId
      ..region = region
      ..subscriptionType = CometChatSubscriptionType.allUsers)
    .build();

// Login using the token
CometChatUIKit.loginWithAuthToken(authToken, 
  onSuccess: (user) {
    // Proceed
  },
  onError: (e) {
    if (e.code == 'ERR_AUTH_TOKEN_NOT_FOUND' || e.code == 'AUTH_ERR_AUTH_TOKEN_NOT_FOUND') {
      // Token expired or invalid — fetch a new one from your backend
      refreshAndRetryLogin();
    }
  },
);

Every integration test follows a standardized five-phase lifecycle to ensure consistency and isolation. This pattern uses dedicated helpers to manage the app state and peer interactions.

1. Launch + Login: Uses AppLauncher.launchAndLogin(tester) to wipe the iOS Keychain, seed credentials, and log in as User A.
2. Navigate: Uses NavigationHelper (e.g., goToTab, openUserBConversation) to move to the target screen.
3. Act: Performs actions via the UI (using MessageHelper for User A) or via REST (using SdkUserB / UserBMessaging for User B).
4. Wait: Uses realtime-aware helpers like pumpForRealtime or AssertionHelper.waitForMessage to wait for WebSocket events (avoid using pumpAndSettle).
5. Assert: Verifies the UI using AssertionHelper. Structural assertions (presence of messages, navigation state) are fatal, while timing-dependent UI details (colors, exact presence text) are logged as non-fatal.
6. Cleanup: Uses CleanupHelper.fullReset() to restore state (unblock users, delete conversations) so subsequent tests start clean.

testWidgets('RT-MSG-001: Receive text message', (WidgetTester tester) async {
  await CleanupHelper.fullReset();                      // clean state
  await AppLauncher.launchAndLogin(tester);             // launch + login as User A

  await NavigationHelper.openUserBConversation(tester); // navigate to B's chat

  await SdkUserB.login();                               // make B "online"
  await UserBMessaging.sendTextToA('Hello from User B'); // B acts via REST

  await AssertionHelper.waitForMessage(                 // wait for the WebSocket event
    tester, 'Hello from User B',
  );
  AssertionHelper.expectMessageVisible(                 // fatal structural assertion
    tester, 'Hello from User B',
  );

  await CleanupHelper.fullReset();                      // cleanup
});

The E2E integration test suite uses a single-device model to simulate realtime interactions. While the Flutter SDK (User A) runs on the device/emulator, a second user (User B) is driven entirely via the CometChat REST API from within the test process using integration_test/sdk_user_b/.

The Realtime Flow:

1. User B makes a REST call (e.g., sending a message) using the onBehalfOf: userB header.
2. The CometChat server receives the request.
3. The server broadcasts a WebSocket event to User A.
4. User A's SDK listener receives the event, triggering a UIKit update.
5. The WidgetTester asserts that the UI reflects the change.

Key Components:

• SdkUserB (sdk_user_b.dart): An HTTP client used to drive User B. Calling login() or logout() manages User B's auth token to trigger presence events. Every request uses an onBehalfOf header to act as User B.
• Capabilities of User B: Can drive messaging, reactions, threads, presence, blocking, receipts, calls, and group operations via specific action files (e.g., messaging_actions.dart, reaction_actions.dart).
• Receipt Logic: Since User A's UI doesn't capture message IDs immediately, User B uses UserBMessaging.fetchLatestMessageIdFromA() to find the latest message authored by A to mark it as delivered or read.
• Cumulative Receipts: markAsRead(id) marks all messages with an ID $\le$ id as read. To optimize API calls, markAllAsRead(list) should only target the highest ID in the list.
• Isolation: Tests use CleanupHelper.seedConversation in setUpAll to prepare state and CleanupHelper.fullReset() in tearDown/setUp to unblock users and delete conversations, ensuring test isolation.