feature request: in-app notification sound

Abierto
  • ¿Algo no está bien?
#7,192 2 comentarios 2 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@psrsingh ya está trabajando en esto.

Desde el 16/5/2026.

  • #7327 de @psrsingh — cerrado sin fusionar

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
react-native, typescript
Área
mobile

Línea de trabajo

Comienza rastreando cómo la configuración de las salas proporciona audioNotificationValue desde rooms.saveNotification y dónde se activan las notificaciones dentro de la aplicación en el cliente móvil. Revisa los recursos de sonido existentes y el flujo de notificaciones antes de decidir cómo encajan los presets, las descargas locales, la selección y la reproducción. Se considera terminado cuando el sonido seleccionado de una sala se reproduce para notificaciones válidas dentro de la aplicación, con un fallback incluido cuando sea necesario.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

🎉 feature type: feature
Feature Description

Currently, the mobile application allows users to select a notification sound (audioNotificationValue) which is successfully saved on the backend via rooms.saveNotification . However, this preference is not respected by the mobile client when in-app notifications are triggered.

This feature proposes enabling the mobile app to play the selected notification sound for in-app messages, ensuring that user preferences are fully applied.

The implementation should:

  • Read the audioNotificationValue from room settings
  • Map it to corresponding sound asset
  • Trigger playback when a valid notification event occurs
Motivation and Use Case

Why this matters

Users expect their notification settings to actually affect behavior. Right now:

  • Changing notification sound has no effect in the mobile app
  • This creates confusion and inconsistency between backend settings and user experience

Use cases

  • A user sets different sounds for different rooms → helps identify message source instantly
  • A user prefers subtle vs loud sounds → improves usability in different environments
  • Teams relying on notifications → need quick auditory distinction

Impact

  • Fixes a broken UX expectation
  • Aligns mobile behavior with backend/web capabilities
  • Improves personalization and usability
Implementation Ideas

  1. Fetch Presets — Backend returns a list of preset sound names (e.g. ["chime", "bell", "ping"]). Each name maps to a downloadable URL, either constructed on the client or returned directly by the API.

  2. Download on Demand — Each preset is shown with a Download button. On tap, the file is downloaded to documentDirectory/notification_sounds/<name>.mp3 via expo-file-system. Download is skipped if the file already exists locally.

  3. UI States — Each preset tracks its own state: not downloaded → downloading → downloaded → selected. User can also preview before selecting.

  4. Private Storage — Files are saved to documentDirectory, which is sandboxed to the app on both iOS and Android. Not visible to other apps or the device media library.

  5. Persist Selection — Active sound preference is saved to AsyncStorage or the existing room settings store as the local file path.

  6. Playback — On in-app notification trigger, resolve the saved path and play via expo-av. Falls back to a bundled default if the file is missing or not yet downloaded.

Is this feature available in the API or web version?

Available in Web Version

Rocket.Chat Server Version

No response

Rocket.Chat App Version

No response

Device Name

No response

OS Version

No response

Additional Context

No response

Lenguaje dominante
TypeScript
Estrellas
2.4k
Forks
1.5k
Merge medio
1 d 15 h
PR fusionados (30 d)
29

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de RocketChat/Rocket.Chat.ReactNative

Todos los issues de RocketChat/Rocket.Chat.ReactNative

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.