Opzioni dell'attività di trasferimento di dati in background

Molte app devono trasferire dati in background. Questa pagina ti aiuta a trovare l'approccio giusto per le tue esigenze.

Casi d'uso per la migrazione

Questa sezione descrive alcune situazioni comuni in cui è necessario trasferire le app da o verso il dispositivo e ti aiuta a scegliere lo strumento giusto la situazione.

Trasferimento di dati attraverso la rete

Se il trasferimento è stato avviato dall'utente e devi mantenere l'utente informati sull'avanzamento del trasferimento, utilizza il trasferimento di dati avviato dall'utente di terze parti. In caso contrario, utilizza WorkManager o un tipo di servizio in primo piano appropriato.

Se devi pianificare un download, puoi anche DownloadManager. DownloadManager gestisce il nome dell'app ciclo di vita del cliente e si occupa di ritentare i download dopo errori, riavvii del dispositivo e alla connettività. Tuttavia, DownloadManager non offre tutte le funzionalità di debug e test disponibili in WorkManager e JobScheduler.

Trasferimento di dati da o verso un dispositivo locale

Utilizza un'API specifica, se disponibile, (ad esempio il dispositivo associato) responsabile); altrimenti utilizza connectedDevice in primo piano Google Cloud.

Completare un'attività breve e critica

Utilizza un servizio in primo piano shortService.

Elaborazione di file (ad esempio, trasferimento di dati da o verso una scheda SD, ridimensionamento dei contenuti o crittografia o decriptazione dei dati)

Se l'attività può essere completata in meno di tre minuti, utilizza un shortService servizio in primo piano. In caso contrario, utilizza WorkManager.

Utilizza le API Data Transfer avviate dall'utente

Se la tua app deve trasferire i dati a un server remoto, ti consigliamo di utilizzare nuove API Data Transfer avviate dall'utente. Queste API sono appropriate se che segue è vero:

  • L'utente ha avviato il trasferimento dei dati
  • Devi informare l'utente dell'avanzamento del trasferimento di dati
  • L'interruzione del trasferimento da parte del sistema compromette l'esperienza utente

Se una di queste condizioni non è soddisfatta, devi utilizzare WorkManager .

Ad esempio, un'app multimediale potrebbe consentire agli utenti di scaricare album da riprodurre localmente. Se vuoi scaricare una playlist e riprodurla subito, ti consigliamo di utilizzare le API Data Transfer avviate dall'utente. Se invece l'utente vuole ha scaricato una playlist per aggiornarla periodicamente in background senza l'utente iniziale, WorkManager sarebbe la scelta migliore.

Per ulteriori informazioni, consulta la documentazione relativa alla migrazione dei servizi in primo piano alla job di trasferimento di dati avviati dall'utente.

Utilizzare WorkManager

Nella maggior parte dei casi, WorkManager è l'opzione migliore quando devi pianificare il lavoro. Le attività devono essere progettate in modo da poter essere interrotte o differite dal sistema. Per ulteriori informazioni, consulta la documentazione di WorkManager.

Di seguito sono riportate alcune note che potrebbero essere utili quando esegui la migrazione da una versione in primo piano a WorkManager:

  • Se devi eseguire il lavoro il prima possibile, puoi pianificare una richiesta di lavoro più rapida. Questa opzione è particolarmente utile programmare il lavoro in risposta a una trasmissione, a una sveglia esatta o messaggio FCM ad alta priorità.
  • Se hai bisogno che il lavoro venga eseguito periodicamente, puoi pianificare periodicamente al lavoro. Una richiesta di lavoro periodica ti consente di specificare approssimativamente la frequenza con cui verranno eseguite, ma non garantiscono un tempo specifico. Ciò consente per pianificare le richieste di lavoro da diverse app al fine di bilanciare le richieste sul dispositivo.
  • Devi definire i vincoli di lavoro per specificare le circostanze per eseguire il job. Ad esempio, se la tua app deve essere scaricata non urgenti, puoi specificare che il job deve essere eseguito mentre Il dispositivo è in carica e connesso a una rete unmetered. WorkManager può eseguire il job in un momento che bilancia il carico sul sistema.
  • WorkManager è libero di annullare e riprovare un job se necessario. Ad esempio: l'utente potrebbe spegnere il dispositivo mentre è in esecuzione un job; il sistema può e riprova quando il dispositivo sarà di nuovo disponibile. Assicurati di progettare e testare il flusso di lavoro per verificare che il ciclo di annullamento e riprova funzioni correttamente.

Utilizza un tipo di servizio in primo piano più specifico

Se non riesci a passare a un'altra modalità di lavoro in background, puoi comunque per utilizzare un servizio in primo piano. In questo caso, dovresti trovare una soluzione tipo di servizio da utilizzare al posto di dataSync. Dato che il tuo codice già utilizza un servizio in primo piano, la migrazione è semplice; devi solo scegliere il tipo di servizio in primo piano appropriato e assicurati che la tua app soddisfi questo in base ai requisiti del servizio.

Come sempre, se stai prendendo in considerazione l'utilizzo di un servizio in primo piano, dovresti Valuta se esiste un'API alternativa migliore su misura per il tuo utilizzo per verificare se è così.

Usa un servizio in primo piano a breve termine

Se la tua app deve eseguire un'attività breve e critica, shortService in primo piano è l'opzione migliore. Ecco alcune situazioni in cui un shortService potrebbe essere appropriato:

  • L'utente avvia un'azione (come la sincronizzazione dei dati con il server) e vuoi per essere certo che l'operazione termini anche se l'utente invia immediatamente il comando in background.
  • Salvataggio delle informazioni in memoria nell'archiviazione permanente.
  • Crittografia o decrittografia delle informazioni.

Per informazioni complete, consulta la documentazione di shortService.

Utilizzare un servizio in primo piano su un dispositivo connesso

Se devi trasferire i dati su un altro dispositivo locale, puoi usare una connectedDevice servizio in primo piano. Ecco alcune situazioni comuni in cui potrebbe essere necessario eseguire questa operazione:

  • Comunicare con un accessorio Bluetooth, ad esempio cuffie o smartwatch
  • Trasferimento di dati a un dispositivo connesso in locale tramite una connessione USB, NFC o una connessione a internet locale

Tuttavia, in queste situazioni potresti riuscire a utilizzare il dispositivo associato per connettersi al dispositivo invece di utilizzare un servizio in primo piano. Come sempre, se per il tuo caso d'uso è disponibile un'API per scopi speciali, di solito è una scelta migliore rispetto all'utilizzo di un servizio in primo piano.

Risorse aggiuntive

Per saperne di più su questa modifica ai servizi in primo piano, consulta quanto segue risorse aggiuntive: