Ricevere messaggi in un'app per Android

Le notifiche Firebase si comportano in modo diverso a seconda dello stato in primo piano/in background dell'app ricevente. Se vuoi che le app in primo piano ricevano messaggi di notifica o messaggi di dati, devi scrivere codice per gestire il callback onMessageReceived. Per una spiegazione della differenza tra messaggi di notifica e messaggi di dati, vedi Tipi di messaggi.

Gestione dei messaggi

Per ricevere messaggi, utilizza un servizio che estende FirebaseMessagingService. Il tuo servizio deve eseguire l'override dei callback onMessageReceived e onDeletedMessages.

onMessageReceived è fornito per la maggior parte dei tipi di messaggi, con le seguenti eccezioni:

• Messaggi di notifica inviati quando l'app è in background. In questo caso, la notifica viene recapitata nella barra delle applicazioni del dispositivo. Quando un utente tocca una notifica, per impostazione predefinita si apre Avvio app.

• Messaggi con payload di notifica e dati, quando ricevuti in background. In questo caso, la notifica viene inviata alla barra delle notifiche del dispositivo e il payload di dati viene inviato negli extra dell'intent dell'attività di avvio.

In sintesi:

Il callback onMessageReceived ha timeout che consentono di pubblicare semplicemente una notifica, ma i timer non sono progettati per consentire all'app di accedere alla rete o di svolgere ulteriori operazioni. Pertanto, se la tua app esegue operazioni più complesse, devi svolgere un lavoro aggiuntivo per assicurarti che possa completare la sua attività.

Se prevedi che la tua app potrebbe richiedere quasi 10 secondi per gestire un messaggio, devi pianificare un job WorkManager o seguire le indicazioni relative a WakeLock riportate di seguito. In alcuni casi, la finestra di tempo per la gestione di un messaggio potrebbe essere inferiore a 10 secondi a seconda dei ritardi subiti prima della chiamata a onMessageReceived, inclusi ritardi del sistema operativo, tempo di avvio dell'app, il thread principale bloccato da altre operazioni o chiamate onMessageReceived precedenti che richiedono troppo tempo. Al termine del timer, la tua app potrebbe essere soggetta a interruzione del processo o limiti di esecuzione in background. Tieni presente che le latenze per le transazioni di rete e l'avvio delle app possono essere significative, quindi in caso di dubbi, pianifica l'elaborazione dei messaggi in modo che duri a lungo se sono presenti dipendenze asincrone come l'accesso alla rete o requisiti di caricamento intensivo dei dati.

Modificare il manifest dell'app

Per utilizzare FirebaseMessagingService, devi aggiungere quanto segue nel manifest dell'app:

<service
    android:name=".java.MyFirebaseMessagingService"
    android:exported="false">
    <intent-filter>
        <action android:name="com.google.firebase.MESSAGING_EVENT" />
    </intent-filter>
</service>
AndroidManifest.xml

Inoltre, ti consigliamo di impostare i valori predefiniti per personalizzare l'aspetto delle notifiche. Puoi specificare un'icona predefinita personalizzata e un colore predefinito personalizzato che vengono applicati ogni volta che i valori equivalenti non vengono impostati nel payload della notifica.

Aggiungi queste righe all'interno del tag application per impostare l'icona predefinita personalizzata e il colore personalizzato:

<!-- Set custom default icon. This is used when no icon is set for incoming notification messages.
     See README(https://goo.gl/l4GJaQ) for more. -->
<meta-data
    android:name="com.google.firebase.messaging.default_notification_icon"
    android:resource="@drawable/ic_stat_ic_notification" />
<!-- Set color used with incoming notification messages. This is used when no color is set for the incoming
     notification message. See README(https://goo.gl/6BKBk7) for more. -->
<meta-data
    android:name="com.google.firebase.messaging.default_notification_color"
    android:resource="@color/colorAccent" />
AndroidManifest.xml

Android visualizza l'icona predefinita personalizzata per

• Tutti i messaggi di notifica inviati dal composer delle notifiche.
• Qualsiasi messaggio di notifica che non imposta esplicitamente l'icona nel payload della notifica.

Android utilizza il colore predefinito personalizzato per

• Tutti i messaggi di notifica inviati dal composer delle notifiche.
• Qualsiasi messaggio di notifica che non imposta esplicitamente il colore nel payload della notifica.

Se non è impostata alcuna icona predefinita personalizzata e non è impostata alcuna icona nel payload di notifica, Android visualizza l'icona dell'applicazione visualizzata in bianco.

Override onMessageReceived

Eseguendo l'override del metodo FirebaseMessagingService.onMessageReceived, puoi eseguire azioni in base all'oggetto RemoteMessage ricevuto e ottenere i dati del messaggio:

override fun onMessageReceived(remoteMessage: RemoteMessage) {
    // TODO(developer): Handle FCM messages here.
    // Not getting messages here? See why this may be: https://goo.gl/39bRNJ
    Log.d(TAG, "From: ${remoteMessage.from}")

    // Check if message contains a data payload.
    if (remoteMessage.data.isNotEmpty()) {
        Log.d(TAG, "Message data payload: ${remoteMessage.data}")

        // Check if data needs to be processed by long running job
        if (needsToBeScheduled()) {
            // For long-running tasks (10 seconds or more) use WorkManager.
            scheduleJob()
        } else {
            // Handle message within 10 seconds
            handleNow()
        }
    }

    // Check if message contains a notification payload.
    remoteMessage.notification?.let {
        Log.d(TAG, "Message Notification Body: ${it.body}")
    }

    // Also if you intend on generating your own notifications as a result of a received FCM
    // message, here is where that should be initiated. See sendNotification method below.
}
MyFirebaseMessagingService.kt

@Override
public void onMessageReceived(RemoteMessage remoteMessage) {
    // TODO(developer): Handle FCM messages here.
    // Not getting messages here? See why this may be: https://goo.gl/39bRNJ
    Log.d(TAG, "From: " + remoteMessage.getFrom());

    // Check if message contains a data payload.
    if (remoteMessage.getData().size() > 0) {
        Log.d(TAG, "Message data payload: " + remoteMessage.getData());

        if (/* Check if data needs to be processed by long running job */ true) {
            // For long-running tasks (10 seconds or more) use WorkManager.
            scheduleJob();
        } else {
            // Handle message within 10 seconds
            handleNow();
        }

    }

    // Check if message contains a notification payload.
    if (remoteMessage.getNotification() != null) {
        Log.d(TAG, "Message Notification Body: " + remoteMessage.getNotification().getBody());
    }

    // Also if you intend on generating your own notifications as a result of a received FCM
    // message, here is where that should be initiated. See sendNotification method below.
}
MyFirebaseMessagingService.java

Mantenere attivo il dispositivo durante la gestione dei messaggi FCM

Se la tua app deve mantenere attivo il dispositivo durante l'elaborazione di un messaggio FCM, deve mantenere un WakeLock durante questo periodo o creare un job WorkManager. WakeLock funziona bene per attività di elaborazione brevi che potrebbero superare i timeout predefiniti di onMessageReceived. Per flussi di lavoro estesi, ad esempio l'invio di più RPC seriali ai server, l'utilizzo di un job WorkManager è più appropriato di un WakeLock. In questa sezione ci concentriamo su come utilizzare WakeLock. Un WakeLock impedisce al dispositivo di entrare in modalità Sospensione mentre l'app è in esecuzione, il che può comportare un maggiore consumo della batteria, pertanto l'utilizzo di WakeLock deve essere riservato ai casi in cui l'app non deve essere sospesa durante la gestione del messaggio, ad esempio:

• Notifiche all'utente che richiedono un intervento tempestivo.
• Interazioni con qualcosa al di fuori del dispositivo che non deve essere interrotto (ad esempio trasferimenti di rete o comunicazioni con un altro dispositivo, come uno smartwatch accoppiato).

Innanzitutto, devi assicurarti che la tua app richieda l'autorizzazione WakeLock (l'SDK FCM la include per impostazione predefinita, quindi normalmente non è necessario aggiungere nulla).

<uses-permission android:name="android.permission.WAKE_LOCK" />

L'app dovrà quindi acquisire un WakeLock all'inizio del callback FirebaseMessagingService.onMessageReceived() e rilasciarlo alla fine del callback.

FirebaseMessagingService personalizzato dell'app:

@Override
public void onMessageReceived(final RemoteMessage message) {
  // If this is a message that is time sensitive or shouldn't be interrupted
  WakeLock wakeLock = getSystemService(PowerManager.class).newWakeLock(PARTIAL_WAKE_LOCK, "myApp:messageReceived");
  try {
    wakeLock.acquire(TIMEOUT_MS);
    // handle message
    ...
  finally {
    wakeLock.release();
  }
}

Override onDeletedMessages

Gestire i messaggi di notifica in un'app in background

Quando l'app è in background, Android indirizza i messaggi di notifica alla barra delle applicazioni. Quando un utente tocca la notifica, per impostazione predefinita si apre Avvio app.

Sono inclusi i messaggi che contengono sia il payload di notifica che quello di dati (e tutti i messaggi inviati dalla console Notifiche). In questi casi, la notifica viene inviata alla barra delle notifiche del dispositivo e il payload di dati viene inviato negli extra dell'intent dell'attività del launcher.

Per informazioni sulla distribuzione dei messaggi alla tua app, consulta la dashboard dei report FCM, che registra il numero di messaggi inviati e aperti su dispositivi Apple e Android, insieme ai dati relativi alle "impressioni" (notifiche visualizzate dagli utenti) per le app per Android.

Ricevere messaggi FCM in modalità di avvio diretto

Gli sviluppatori che vogliono inviare messaggi FCM alle app anche prima che il dispositivo venga sbloccato possono attivare un'app per Android per ricevere messaggi quando il dispositivo è in modalità di avvio diretto. Ad esempio, potresti voler che gli utenti della tua app ricevano notifiche di allarme anche su un dispositivo bloccato.

Quando sviluppi questo caso d'uso, rispetta le best practice e le limitazioni generali per la modalità di avvio diretto. È particolarmente importante considerare la visibilità dei messaggi con avvio diretto abilitato. Qualsiasi utente con accesso al dispositivo può visualizzare questi messaggi senza inserire le credenziali utente.

Prerequisiti

• Il dispositivo deve essere configurato per la modalità di avvio diretto.
• Sul dispositivo deve essere installata una versione recente di Google Play Services (19.0.54 o versioni successive).
• L'app deve utilizzare l'SDK FCM (com.google.firebase:firebase-messaging) per ricevere i messaggi FCM.

Attivare la gestione dei messaggi in modalità di avvio diretto nell'app

1. Nel file Gradle a livello di app, aggiungi una dipendenza dalla libreria di supporto dell'avvio diretto di FCM:

   implementation 'com.google.firebase:firebase-messaging-directboot:20.2.0'
   

2. Rendi l'avvio diretto di FirebaseMessagingService dell'app consapevole aggiungendo l'attributo android:directBootAware="true" nel manifest dell'app:

   <service
       android:name=".java.MyFirebaseMessagingService"
       android:exported="false"
       android:directBootAware="true">
       <intent-filter>
           <action android:name="com.google.firebase.MESSAGING_EVENT" />
       </intent-filter>
   </service>
   

È importante assicurarsi che questo FirebaseMessagingService possa essere eseguito in modalità di avvio diretto. Verifica i seguenti requisiti:

• Il servizio non deve accedere allo spazio di archiviazione protetto dalle credenziali durante l'esecuzione in modalità di avvio diretto.
• Il servizio non deve tentare di utilizzare componenti, ad esempio Activities, BroadcastReceivers o altri Services che non sono contrassegnati come compatibili con l'avvio diretto durante l'esecuzione in modalità di avvio diretto.
• Anche le librerie utilizzate dal servizio non devono accedere allo spazio di archiviazione protetto dalle credenziali né chiamare componenti non compatibili con l'avvio diretto durante l'esecuzione in modalità di avvio diretto. Ciò significa che qualsiasi libreria utilizzata dall'app e chiamata dal servizio dovrà essere compatibile con l'avvio diretto oppure l'app dovrà verificare se è in esecuzione in modalità di avvio diretto e non chiamarle in questa modalità. Ad esempio, gli SDK Firebase funzionano con l'avvio diretto (possono essere inclusi in un'app senza causarne l'arresto anomalo in modalità di avvio diretto), ma molte API Firebase non supportano le chiamate in modalità di avvio diretto.
• Se l'app utilizza un Application personalizzato, anche questo dovrà essere compatibile con l'avvio diretto (nessun accesso allo spazio di archiviazione protetto da credenziali in modalità di avvio diretto).Application

Per indicazioni sull'invio di messaggi ai dispositivi in modalità di avvio diretto, consulta Inviare messaggi abilitati per l'avvio diretto.