Avvisare i tester in merito alle nuove build


Gli SDK facoltativi Firebase App Distribution per iOS e Android ti consentono di mostrare avvisi in-app ai tester quando sono disponibili nuove build della tua app da installare. Questa guida spiega come utilizzare gli SDK per iOS e Android per creare e personalizzare nuovi avvisi di build per i tuoi tester.App Distribution

Prima di iniziare

Se non l'hai ancora fatto, aggiungi Firebase al tuo progetto Android.

Passaggio 1: attiva l'API App Distribution Tester

  1. Seleziona il progetto nella Google Cloud console.

  2. In API Firebase App Testers, fai clic su Attiva.

Passaggio 2: aggiungi App Distribution alla tua app

L'SDK Android App Distribution è costituito da due librerie:

  • firebase-appdistribution-api: la libreria solo API, che puoi includere in tutte le varianti di build.
  • firebase-appdistribution: l'implementazione completa dell'SDK (facoltativa).

La libreria solo API consente al codice di effettuare chiamate all'SDK. Le chiamate non avranno alcun effetto se l'implementazione completa dell'SDK non è presente.

Dichiara la dipendenza per l'SDK Android App Distribution nel file Gradle del modulo (a livello di app) (solitamente <project>/<app-module>/build.gradle.kts o <project>/<app-module>/build.gradle). Per evitare di includere la funzionalità di aggiornamento automatico dell'implementazione completa dell'SDK nelle build Play, aggiungi la dipendenza della libreria solo API a tutte le varianti di build. Aggiungi l'implementazione completa dell'SDK solo alle varianti destinate esclusivamente al test pre-release.

dependencies {
    // ADD the API-only library to all variants
    implementation("com.google.firebase:firebase-appdistribution-api:16.0.0-beta16")

    // ADD the full SDK implementation to the "beta" variant only (example)
    betaImplementation("com.google.firebase:firebase-appdistribution:16.0.0-beta16")
}

Cerchi un modulo della libreria specifico per Kotlin? A partire dalla release di ottobre 2023, gli sviluppatori Kotlin e Java possono fare affidamento sul modulo della libreria principale (per maggiori dettagli, consulta le domande frequenti su questa iniziativa).

Passaggio 3: configura gli avvisi in-app

L'SDK Android App Distribution fornisce i seguenti modi per configurare gli avvisi di build in-app per i tester:

  • Una configurazione di avviso di base con finestre di dialogo predefinite per l'aggiornamento dell'app e l'accesso da mostrare ai tester.
  • Una configurazione avanzata degli avvisi che ti consente di personalizzare la tua interfaccia utente.

Se utilizzi l'SDK Android App Distribution per la prima volta, ti consigliamo di utilizzare la configurazione di base.

Configurazione di base

Utilizza updateIfNewReleaseAvailable per mostrare una finestra di dialogo predefinita per l'attivazione degli avvisi ai tester che non li hanno ancora attivati, quindi verifica se è disponibile una nuova build. Quando viene chiamato, il metodo esegue la seguente sequenza:

  1. Controlla se un tester ha attivato gli avvisi. Se il tester non ha ancora attivato gli avvisi, il metodo chiede al tester di accedere a App Distribution con il proprio Account Google.

  2. Verifica la presenza di nuove build disponibili per l'installazione da parte del tester.

  3. Mostra un avviso predefinito che chiede al tester di eseguire l'aggiornamento.

  4. Se la nuova build è un Android App Bundle (AAB), il tester viene reindirizzato a Google Play per completare la procedura di aggiornamento.

    Se la nuova build è un pacchetto dell'applicazione Android (APK), l'SDK scarica la nuova build in background e chiede al tester di installarla al termine del download. L'SDK invia notifiche di avanzamento del download all'utente utilizzando NotificationManager. Puoi anche aggiungere un indicatore di avanzamento personalizzato collegando un gestore onProgressUpdate all'attività updateIfNewReleaseAvailable.

Puoi chiamare updateIfNewReleaseAvailable in qualsiasi punto dell'app. Ad esempio, puoi chiamare updateIfNewReleaseAvailable durante il metodo onResume dell'attività principale dell'app.

Il seguente esempio verifica se il tester ha attivato gli avvisi e ha accesso a una nuova build. Se queste condizioni sono soddisfatte, viene visualizzata una finestra di dialogo quando la build è disponibile per l'installazione:

Kotlin 

// Copy and paste this into any part of your app - for example, in your main
// activity's onResume method.
val firebaseAppDistribution = FirebaseAppDistribution.getInstance()
firebaseAppDistribution.updateIfNewReleaseAvailable()
    .addOnProgressListener { updateProgress ->
      // (Optional) Implement custom progress updates in addition to
      // automatic NotificationManager updates.
    }
    .addOnFailureListener { e ->
      // (Optional) Handle errors.
      if (e is FirebaseAppDistributionException) {
        when (e.errorCode) {
          Status.NOT_IMPLEMENTED -> {
            // SDK did nothing. This is expected when building for Play.
          }
          else -> {
            // Handle other errors.
          }
        }
      }
    }

Java 

// Copy and paste this into any part of your app - for example, in your main
// activity's onResume method.
FirebaseAppDistribution firebaseAppDistribution = FirebaseAppDistribution.getInstance();
firebaseAppDistribution.updateIfNewReleaseAvailable()
    .addOnProgressListener(updateProgress -> {
      // (Optional) Implement custom progress updates in addition to
      // automatic NotificationManager updates.
    })
    .addOnFailureListener(e -> {
      // (Optional) Handle errors.
      if (e instanceof FirebaseAppDistributionException) {
        switch (((FirebaseAppDistributionException)e).getErrorCode()) {
          case NOT_IMPLEMENTED:
            // SDK did nothing. This is expected when building for Play.
            break;
          default:
            // Handle other errors.
            break;
        }
      }
    });

Configurazione avanzata

Configurazione avanzata dell'accesso

I metodi signInTester e isTesterSignedIn ti offrono maggiore flessibilità per personalizzare l'esperienza di accesso dei tester, in modo che possa corrispondere meglio all'aspetto della tua app.

L'esempio seguente controlla se il tester ha già eseguito l'accesso al proprio account tester App Distribution. In questo modo puoi scegliere di mostrare l'interfaccia utente (UI) di accesso solo ai tester che non hanno ancora eseguito l'accesso. Dopo che il tester ha eseguito l'accesso, puoi chiamare updateIfNewReleaseAvailable per verificare se il tester ha accesso a una nuova build.

Kotlin 

// Only show sign-in UI if this is the "beta" variant (example).
if (BuildConfig.BUILD_TYPE == "beta" && !firebaseAppDistribution.isTesterSignedIn) {
    // Start your sign-in UI here.
}

// Only check for updates if the tester is already signed in (do not prompt).
if (firebaseAppDistribution.isTesterSignedIn) {
    firebaseAppDistribution.updateIfNewReleaseAvailable().addOnFailureListener {
        // Handle failed update.
    }
}

Java 

// Only show sign-in UI if this is the "beta" variant (example).
if (BuildConfig.BUILD_TYPE == "beta" && !firebaseAppDistribution.isTesterSignedIn()) {
    // Start your sign-in UI here.
}

// Only check for updates if the tester is already signed in (do not prompt).
if (firebaseAppDistribution.isTesterSignedIn()) {
    firebaseAppDistribution.updateIfNewReleaseAvailable().addOnFailureListener( e -> {
        // Handle failed update.
    });
}

Dall'interfaccia utente di accesso, quando il tester sceglie di procedere, chiama signInTester():

Kotlin 

firebaseAppDistribution.signInTester().addOnSuccessListener {
  // Handle successful sign-in.
}.addOnFailureListener {
  // Handle failed sign-in.
});

Java 

firebaseAppDistribution.signInTester().addOnSuccessListener( unused -> {
  // Handle successful sign-in.
}).addOnFailureListener(e -> {
  // Handle failed sign-in.
});

Configurazione avanzata degli aggiornamenti

I metodi checkForNewRelease e updateApp offrono maggiore flessibilità per personalizzare il momento in cui viene richiesto all'utente che esegue il test di eseguire l'aggiornamento. Puoi anche personalizzare la finestra di dialogo di aggiornamento predefinita e l'indicatore di avanzamento del download in modo che corrispondano meglio all'aspetto della tua app.

Tieni presente che updateApp non fornisce l'indicazione dell'avanzamento del download. Ciò significa che devi implementare la tua indicazione di avanzamento utilizzando NotificationManager, una sorta di visualizzazione dello stato in-app o un altro approccio.

Il seguente esempio verifica se è disponibile una nuova release e poi visualizza una UI personalizzata. Prima di chiamare checkForNewRelease e updateApp, assicurati che il tester abbia eseguito l'accesso utilizzando la configurazione di accesso avanzata.

Kotlin 

firebaseAppDistribution.checkForNewRelease().addOnSuccessListener { release ->
    if (release != null) {
        // New release available. Start your update UI here.
    }
}.addOnFailureListener {
    // Handle failed check for new release. Fails with Status#NOT_IMPLEMENTED
    // if built for Play.
}

Java 

firebaseAppDistribution.checkForNewRelease().addOnSuccessListener(release -> {
    if (release != null) {
        // New release available. Start your update UI here.
    }
}).addOnFailureListener(e -> {
    // Handle failed check for new release. Fails with Status#NOT_IMPLEMENTED
    // if built for Play.
});

Quando il tester sceglie di procedere con l'aggiornamento dall'UI di aggiornamento, chiama updateApp():

Kotlin 

firebaseAppDistribution.updateApp()
    .addOnProgressListener { updateState ->
      // Use updateState to show update progress.
    }

Java 

firebaseAppDistribution.updateApp()
    .addOnProgressListener(updateState -> {
      // Use updateState to show update progress.
    });

Passaggio 4: crea e testa l'implementazione

Crea la tua app e testa l'implementazione distribuendo la build ai tester utilizzando la console Firebase.

Visita la App Distribution Guida alla risoluzione dei problemi per ricevere assistenza per problemi comuni, ad esempio:

  • Il tester non riceve avvisi in-app
  • Al tester viene chiesto di accedere a Google più di una volta