Uno dei motivi principali per utilizzare qualsiasi dei client REST (retrofit, pallavolo, ecc.) È che riducono la quantità di dettagli gestita a livello di applicazione. Uno di questi dettagli è assicurarsi che le richieste di rete avvengano fuori dal thread principale. Perché si dovrebbe usare uno AsyncTask quando una libreria che già stanno utilizzando per altre funzionalità fornisce la stessa funzionalità con meno cerimonie? L'unica ragione per cui posso pensare è - non pensi che il threading della biblioteca sia molto buono. Tale preoccupazione non si applica al retrofit 2, utilizza OkHttp per inviare chiamate asincrone. OkHttp è in uso da un po 'e ampiamente utilizzato, gestisce il proprio pool di thread per eseguire richieste asincrone ed è solido.
Quindi, l'aspetto positivo dell'utilizzo di aggiornamento asincrono è un codice più pulito, e non esiste uno svantaggio rispetto a AsyncTask con le chiamate di sincronizzazione di aggiornamento. L'unica volta che utilizzo le chiamate di sincronizzazione è quando il mio codice è già in esecuzione in un thread in background per un altro motivo. Non creo mai un thread separato o asynctask solo per la chiamata di rete e utilizzo invece enqueue.