Get Notification Tray Seen
Unseen Status Detection
Determine whether there are unseen notifications in the tray
Cross-device Sync
Manage seen status across multiple client devices
Overview
ThegetNotificationTraySeen()
method allows your app to determine whether there are unseen notifications by retrieving the current isSeen
status of the notification tray.
This is particularly useful for reflecting read/unread indicators in the UI—such as toggling a bell icon badge—based on whether new notifications have arrived since the tray was last viewed.
The seen status is managed on the server and may be affected by actions from other devices. However, the state is not updated via real-time events, and thus requires manual refresh to stay current.
Refresh Strategies
🔁 On-demand Refresh (Recommended)
🔁 On-demand Refresh (Recommended)
The preferred approach for maintaining accurate seen status across clients:
UI-Triggered Updates
Invoke
getNotificationTraySeen()
whenever the Notification Tray UI is refreshedPull-to-Refresh
Implement pull-to-refresh gestures or dedicated refresh buttons for user-initiated updates
Implementation Pattern
⏱️ Polling Strategy (Use Sparingly)
⏱️ Polling Strategy (Use Sparingly)
Polling should be avoided unless absolutely necessary due to server rate limiting risks and battery drain concerns.
- Minimum interval: 120 seconds or more
- Use case: Critical real-time applications only
- Implementation: Include proper error handling and exponential backoff
Cross-device Update Behavior
🔄 Local vs Cross-device Updates
🔄 Local vs Cross-device Updates
Understanding how seen status synchronizes across different scenarios:
Same Client Updates
When
markNotificationTraySeen()
is called on the same client, the isSeen
value updates immediately if LiveObject is being observedCross-device Updates
No real-time sync between devices. Manual
getNotificationTraySeen()
call required to retrieve updated state📱 Multi-device Implementation
📱 Multi-device Implementation
Error Handling
Common Error Scenarios
Common Error Scenarios
Network Connectivity
Handle offline scenarios gracefully with cached states
Rate Limiting
Implement exponential backoff for frequent API calls
Authentication
Handle token expiration and re-authentication flows
Server Errors
Provide fallback UI states for server-side issues
Error Handling Implementation
Error Handling Implementation
Best Practices
🎯 Implementation Guidelines
🎯 Implementation Guidelines
Timing
When to Call
- App launch or resume
- Tray UI becomes visible
- User pull-to-refresh action
- After significant user inactivity
Frequency
Call Frequency
- On-demand only (recommended)
- Minimum 120s intervals if polling
- Avoid excessive API calls
- Implement rate limiting client-side
🔧 Performance Optimization
🔧 Performance Optimization
- Cache Results: Store last known state locally for immediate UI updates
- Batch Operations: Combine with other notification-related API calls when possible
- Background Processing: Perform network calls off the main thread
- Memory Management: Properly dispose of observers and callbacks
🎨 UI/UX Considerations
🎨 UI/UX Considerations
- Visual Indicators: Use clear badges, dots, or colors for unseen states
- Loading States: Show appropriate loading indicators during refresh
- Error States: Provide meaningful error messages and retry options
- Accessibility: Ensure notification states are accessible to screen readers
🔒 Security & Privacy
🔒 Security & Privacy
- Authentication: Verify user authentication before making calls
- Permissions: Request appropriate notification permissions
- Data Privacy: Handle notification data according to privacy policies
- Logging: Avoid logging sensitive notification content