Hilt è una libreria di dipendenza per Android che riduce il codice boilerplate necessario per eseguire l'iniezione di dipendenze manuale nel progetto. L'iniezione di dipendenze manualmente richiede di creare manualmente ogni classe e le relative dipendenze e di utilizzare i contenitori per riutilizzare e gestire le dipendenze.
Hilt fornisce un modo standard per utilizzare l'iniezione di dipendenze nella tua applicazione fornendo contenitori per ogni classe Android del progetto e gestendo automaticamente i relativi cicli di vita. Hilt è basato sulla popolare libreria DI Dagger per trarre vantaggio dalla correttezza in fase di compilazione, dalle prestazioni in fase di esecuzione, dalla scalabilità e dal supporto di Android Studio offerti da Dagger. Per ulteriori informazioni, consulta Hilt and Dagger.
Questa guida illustra i concetti di base di Hilt e dei relativi contenitori generati. Include anche una dimostrazione di come avviare un'app esistente per utilizzare Hilt.
Aggiunta di dipendenze
Innanzitutto, aggiungi il plug-in hilt-android-gradle-plugin
al file build.gradle
principale del progetto:
Groovy
plugins { ... id 'com.google.dagger.hilt.android' version '2.51.1' apply false }
Kotlin
plugins { ... id("com.google.dagger.hilt.android") version "2.51.1" apply false }
Dopodiché, applica il plug-in Gradle e aggiungi queste dipendenze nel file app/build.gradle
:
Groovy
... plugins { id 'kotlin-kapt' id 'com.google.dagger.hilt.android' } android { ... } dependencies { implementation "com.google.dagger:hilt-android:2.51.1" kapt "com.google.dagger:hilt-compiler:2.51.1" } // Allow references to generated code kapt { correctErrorTypes true }
Kotlin
plugins { id("kotlin-kapt") id("com.google.dagger.hilt.android") } android { ... } dependencies { implementation("com.google.dagger:hilt-android:2.51.1") kapt("com.google.dagger:hilt-android-compiler:2.51.1") } // Allow references to generated code kapt { correctErrorTypes = true }
Hilt utilizza le funzionalità di Java 8. Per attivare Java 8 nel
tuo progetto, aggiungi quanto segue al file app/build.gradle
:
Groovy
android { ... compileOptions { sourceCompatibility JavaVersion.VERSION_1_8 targetCompatibility JavaVersion.VERSION_1_8 } }
Kotlin
android { ... compileOptions { sourceCompatibility = JavaVersion.VERSION_1_8 targetCompatibility = JavaVersion.VERSION_1_8 } }
Classe dell'applicazione Hilt
Tutte le app che utilizzano Hilt devono contenere una classe
Application
annotata con
@HiltAndroidApp
.
@HiltAndroidApp
attiva la generazione di codice di Hilt, inclusa una classe di base per la tua applicazione che funge da contenitore delle dipendenze a livello di applicazione.
Kotlin
@HiltAndroidApp class ExampleApplication : Application() { ... }
Java
@HiltAndroidApp public class ExampleApplication extends Application { ... }
Questo componente Hilt generato è associato al ciclo di vita dell'oggetto Application
e fornisce le relative dipendenze. Inoltre, è il componente principale dell'app, il che significa che gli altri componenti possono accedere alle dipendenze che fornisce.
Iniettare dipendenze nelle classi Android
Una volta configurato Hilt nella classe Application
e disponibile un componente a livello di applicazione, Hilt può fornire dipendenze ad altre classi Android con l'annotazione @AndroidEntryPoint
:
Kotlin
@AndroidEntryPoint class ExampleActivity : AppCompatActivity() { ... }
Java
@AndroidEntryPoint public class ExampleActivity extends AppCompatActivity { ... }
Al momento Hilt supporta le seguenti classi Android:
Application
(utilizzando@HiltAndroidApp
)ViewModel
(utilizzando@HiltViewModel
)Activity
Fragment
View
Service
BroadcastReceiver
Se annoti una classe Android con @AndroidEntryPoint
, devi anche annotare le classi Android che dipendono da essa. Ad esempio, se annoti un frammento, devi annotare anche le attività in cui lo utilizzi.
@AndroidEntryPoint
genera un singolo componente Hilt per ogni
classe Android nel progetto. Questi componenti possono ricevere dipendenze dalle rispettive classi principali, come descritto nella Gerarchia dei componenti.
Per ottenere le dipendenze da un componente, utilizza l'annotazione @Inject
per eseguire l'iniezione di campo:
Kotlin
@AndroidEntryPoint class ExampleActivity : AppCompatActivity() { @Inject lateinit var analytics: AnalyticsAdapter ... }
Java
@AndroidEntryPoint public class ExampleActivity extends AppCompatActivity { @Inject AnalyticsAdapter analytics; ... }
Le classi iniettate da Hilt possono avere altre classi di base che utilizzano anche l'iniezione.
Questi tipi di classi non richiedono l'annotazione @AndroidEntryPoint
se sono astratti.
Per scoprire di più sul richiamo del ciclo di vita in cui viene iniettata una classe Android, consulta la sezione Cicli di vita dei componenti.
Definisci le associazioni Hilt
Per eseguire l'iniezione di campo, Hilt deve sapere come fornire istanze delle dipendenze necessarie dal componente corrispondente. Una associazione contiene le informazioni necessarie per fornire istanze di un tipo come dipendenza.
Un modo per fornire informazioni di associazione a Hilt è l'iniezione del costruttore. Utilizza
l'annotazione @Inject
sul costruttore di una classe per indicare a Hilt come fornire le istanze di quella classe:
Kotlin
class AnalyticsAdapter @Inject constructor( private val service: AnalyticsService ) { ... }
Java
public class AnalyticsAdapter { private final AnalyticsService service; @Inject AnalyticsAdapter(AnalyticsService service) { this.service = service; } ... }
I parametri di un costruttore annotato di una classe sono le dipendenze di quella classe. Nell'esempio, AnalyticsAdapter
ha AnalyticsService
come
dipendenza. Pertanto, Hilt deve anche sapere come fornire istanze di
AnalyticsService
.
Moduli Hilt
A volte un tipo non può essere iniettato tramite il costruttore. Questo può accadere per diversi motivi. Ad esempio, non puoi iniettare un'interfaccia tramite il costruttore. Inoltre, non puoi eseguire l'iniezione di un tipo che non possiedi, ad esempio una classe di una libreria esterna. In questi casi, puoi fornire a Hilt le informazioni di associazione utilizzando i moduli Hilt.
Un modulo Hilt è una classe annotata con @Module
. Come un modulo Dagger, informa Hilt su come fornire istanze di determinati tipi. A differenza dei moduli Dagger,
devi annotare i moduli Hilt con @InstallIn
per indicare a Hilt in quale
classe Android verrà utilizzato o installato ciascun modulo.
Le dipendenze fornite nei moduli Hilt sono disponibili in tutti i componenti generati associati alla classe Android in cui installi il modulo Hilt.
Esegui l'iniezione di istanze di interfaccia con @Binds
Considera l'esempio AnalyticsService
. Se AnalyticsService
è un'interfaccia, non puoi iniettarlo tramite il costruttore. Fornisci invece a Hilt le informazioni di associazione creando una funzione astratta annotata con @Binds
all'interno di un modulo Hilt.
L'annotazione @Binds
indica a Hilt quale implementazione utilizzare quando deve fornire un'istanza di un'interfaccia.
La funzione annotata fornisce le seguenti informazioni a Hilt:
- Il tipo di ritorno della funzione indica a Hilt di quale interfaccia fornisce la funzione le istanze.
- Il parametro della funzione indica a Hilt quale implementazione fornire.
Kotlin
interface AnalyticsService { fun analyticsMethods() } // Constructor-injected, because Hilt needs to know how to // provide instances of AnalyticsServiceImpl, too. class AnalyticsServiceImpl @Inject constructor( ... ) : AnalyticsService { ... } @Module @InstallIn(ActivityComponent::class) abstract class AnalyticsModule { @Binds abstract fun bindAnalyticsService( analyticsServiceImpl: AnalyticsServiceImpl ): AnalyticsService }
Java
public interface AnalyticsService { void analyticsMethods(); } // Constructor-injected, because Hilt needs to know how to // provide instances of AnalyticsServiceImpl, too. public class AnalyticsServiceImpl implements AnalyticsService { ... @Inject AnalyticsServiceImpl(...) { ... } } @Module @InstallIn(ActivityComponent.class) public abstract class AnalyticsModule { @Binds public abstract AnalyticsService bindAnalyticsService( AnalyticsServiceImpl analyticsServiceImpl ); }
Il modulo Hilt AnalyticsModule
è annotato con
@InstallIn(ActivityComponent.class)
perché vuoi che Hilt inietti questa
dipendenza in ExampleActivity
. Questa annotazione indica che tutte le dipendenze in AnalyticsModule
sono disponibili in tutte le attività dell'app.
Iniettare istanze con @Provides
Le interfacce non sono l'unico caso in cui non puoi iniettare un tipo tramite il costruttore.
L'iniezione del costruttore non è possibile anche se non possiedi la classe perché proviene da una libreria esterna (classi come Retrofit, OkHttpClient
o database Room) o se le istanze devono essere create con il pattern di compilatore.
Considera l'esempio precedente. Se non possiedi direttamente la classe AnalyticsService
, puoi indicare a Hilt come fornire istanze di questo tipo creando una
funzione all'interno di un modulo Hilt e annotandola con @Provides
.
La funzione annotata fornisce le seguenti informazioni a Hilt:
- Il tipo di ritorno della funzione indica a Hilt il tipo di istanze fornito dalla funzione.
- I parametri della funzione indicano a Hilt le dipendenze del tipo corrispondente.
- Il corpo della funzione indica a Hilt come fornire un'istanza del corrispondente tipo. Hilt esegue il corpo della funzione ogni volta che deve fornire un'istanza di quel tipo.
Kotlin
@Module @InstallIn(ActivityComponent::class) object AnalyticsModule { @Provides fun provideAnalyticsService( // Potential dependencies of this type ): AnalyticsService { return Retrofit.Builder() .baseUrl("https://example.com") .build() .create(AnalyticsService::class.java) } }
Java
@Module @InstallIn(ActivityComponent.class) public class AnalyticsModule { @Provides public static AnalyticsService provideAnalyticsService( // Potential dependencies of this type ) { return new Retrofit.Builder() .baseUrl("https://example.com") .build() .create(AnalyticsService.class); } }
Fornire più associazioni per lo stesso tipo
Se hai bisogno che Hilt fornisca implementazioni diverse dello stesso tipo come dipendenze, devi fornire a Hilt più associazioni. Puoi definire più associazioni per lo stesso tipo con i qualificatori.
Un qualificatore è un'annotazione che utilizzi per identificare una specifica associazione per un tipo quando sono definite più associazioni per quel tipo.
Considera l'esempio. Se devi intercettare le chiamate a AnalyticsService
, puoi utilizzare un oggetto OkHttpClient
con un intercettatore. Per
altri servizi, potresti dover intercettare le chiamate in modo diverso. In questo caso, devi dire a Hilt come fornire due implementazioni diverse di OkHttpClient
.
Innanzitutto, definisci i qualificatori che utilizzerai per annotare i metodi @Binds
o
@Provides
:
Kotlin
@Qualifier @Retention(AnnotationRetention.BINARY) annotation class AuthInterceptorOkHttpClient @Qualifier @Retention(AnnotationRetention.BINARY) annotation class OtherInterceptorOkHttpClient
Java
@Qualifier @Retention(RetentionPolicy.RUNTIME) private @interface AuthInterceptorOkHttpClient {} @Qualifier @Retention(RetentionPolicy.RUNTIME) private @interface OtherInterceptorOkHttpClient {}
Poi, Hilt deve sapere come fornire un'istanza del tipo corrispondente a ciascun qualificatore. In questo caso, puoi utilizzare un modulo Hilt con @Provides
.
Entrambi i metodi hanno lo stesso tipo di ritorno, ma i qualificatori li etichettano come due
legame diverso:
Kotlin
@Module @InstallIn(SingletonComponent::class) object NetworkModule { @AuthInterceptorOkHttpClient @Provides fun provideAuthInterceptorOkHttpClient( authInterceptor: AuthInterceptor ): OkHttpClient { return OkHttpClient.Builder() .addInterceptor(authInterceptor) .build() } @OtherInterceptorOkHttpClient @Provides fun provideOtherInterceptorOkHttpClient( otherInterceptor: OtherInterceptor ): OkHttpClient { return OkHttpClient.Builder() .addInterceptor(otherInterceptor) .build() } }
Java
@Module @InstallIn(ActivityComponent.class) public class NetworkModule { @AuthInterceptorOkHttpClient @Provides public static OkHttpClient provideAuthInterceptorOkHttpClient( AuthInterceptor authInterceptor ) { return new OkHttpClient.Builder() .addInterceptor(authInterceptor) .build(); } @OtherInterceptorOkHttpClient @Provides public static OkHttpClient provideOtherInterceptorOkHttpClient( OtherInterceptor otherInterceptor ) { return new OkHttpClient.Builder() .addInterceptor(otherInterceptor) .build(); } }
Puoi inserire il tipo specifico di cui hai bisogno annotando il campo o il parametro con il qualificatore corrispondente:
Kotlin
// As a dependency of another class. @Module @InstallIn(ActivityComponent::class) object AnalyticsModule { @Provides fun provideAnalyticsService( @AuthInterceptorOkHttpClient okHttpClient: OkHttpClient ): AnalyticsService { return Retrofit.Builder() .baseUrl("https://example.com") .client(okHttpClient) .build() .create(AnalyticsService::class.java) } } // As a dependency of a constructor-injected class. class ExampleServiceImpl @Inject constructor( @AuthInterceptorOkHttpClient private val okHttpClient: OkHttpClient ) : ... // At field injection. @AndroidEntryPoint class ExampleActivity: AppCompatActivity() { @AuthInterceptorOkHttpClient @Inject lateinit var okHttpClient: OkHttpClient }
Java
// As a dependency of another class. @Module @InstallIn(ActivityComponent.class) public class AnalyticsModule { @Provides public static AnalyticsService provideAnalyticsService( @AuthInterceptorOkHttpClient OkHttpClient okHttpClient ) { return new Retrofit.Builder() .baseUrl("https://example.com") .client(okHttpClient) .build() .create(AnalyticsService.class); } } // As a dependency of a constructor-injected class. public class ExampleServiceImpl ... { private final OkHttpClient okHttpClient; @Inject ExampleServiceImpl(@AuthInterceptorOkHttpClient OkHttpClient okHttpClient) { this.okHttpClient = okHttpClient; } } // At field injection. @AndroidEntryPoint public class ExampleActivity extends AppCompatActivity { @AuthInterceptorOkHttpClient @Inject OkHttpClient okHttpClient; ... }
Come best practice, se aggiungi un qualificatore a un tipo, aggiungi i qualificatori a tutti i modi possibili per fornire la dipendenza. Lasciare l'implementazione di base o comune senza un qualificatore è soggetto a errori e potrebbe comportare l'iniezione da parte di Hilt della dipendenza sbagliata.
Qualificatori predefiniti in Hilt
Hilt fornisce alcuni qualificatori predefiniti. Ad esempio, poiché potresti aver bisogno della classe Context
dall'applicazione o dall'attività, Hilt fornisce i qualificatori @ApplicationContext
e @ActivityContext
.
Supponiamo che la classe AnalyticsAdapter
dell'esempio abbia bisogno del contesto dell'attività. Il codice seguente mostra come fornire il contesto dell'attività a AnalyticsAdapter
:
Kotlin
class AnalyticsAdapter @Inject constructor( @ActivityContext private val context: Context, private val service: AnalyticsService ) { ... }
Java
public class AnalyticsAdapter { private final Context context; private final AnalyticsService service; @Inject AnalyticsAdapter( @ActivityContext Context context, AnalyticsService service ) { this.context = context; this.service = service; } }
Per altre associazioni predefinite disponibili in Hilt, consulta Associazioni predefinite del componente.
Componenti generati per le classi Android
Per ogni classe Android in cui puoi eseguire l'iniezione di campo, è presente un componente Hilt associato a cui puoi fare riferimento nell'annotazione @InstallIn
.
Ogni componente Hilt è responsabile dell'iniezione delle relative associazioni nella classe Android corrispondente.
Gli esempi precedenti hanno dimostrato l'utilizzo di ActivityComponent
nei moduli Hilt.
Hilt fornisce i seguenti componenti:
Componente Hilt | Iniettore per |
---|---|
SingletonComponent |
Application |
ActivityRetainedComponent |
N/D |
ViewModelComponent |
ViewModel |
ActivityComponent |
Activity |
FragmentComponent |
Fragment |
ViewComponent |
View |
ViewWithFragmentComponent |
View annotato con @WithFragmentBindings |
ServiceComponent |
Service |
Durata dei componenti
Hilt crea e distrugge automaticamente le istanze delle classi di componenti generate in base al ciclo di vita delle classi Android corrispondenti.
Componente generato | Ora di creazione: | Eliminata il giorno |
---|---|---|
SingletonComponent |
Application#onCreate() |
Application distrutta |
ActivityRetainedComponent |
Activity#onCreate() |
Activity#onDestroy() |
ViewModelComponent |
ViewModel creato |
ViewModel distrutta |
ActivityComponent |
Activity#onCreate() |
Activity#onDestroy() |
FragmentComponent |
Fragment#onAttach() |
Fragment#onDestroy() |
ViewComponent |
View#super() |
View distrutta |
ViewWithFragmentComponent |
View#super() |
View distrutta |
ServiceComponent |
Service#onCreate() |
Service#onDestroy() |
Ambiti dei componenti
Per impostazione predefinita, tutte le associazioni in Hilt sono senza ambito. Ciò significa che ogni volta che la tua app richiede la convalida, Hilt crea una nuova istanza del tipo necessario.
Nell'esempio, ogni volta che Hilt fornisce AnalyticsAdapter
come dipendenza a un altro tipo o tramite l'iniezione di campo (come in ExampleActivity
), fornisce una nuova istanza di AnalyticsAdapter
.
Tuttavia, Hilt consente anche di limitare l'ambito di una associazione a un determinato componente. Hilt crea una associazione basata sugli ambiti solo una volta per istanza del componente a cui è associata e tutte le richieste per quell'associazione condividono la stessa istanza.
La tabella seguente elenca le annotazioni dell'ambito per ogni componente generato:
Classe Android | Componente generato | Ambito |
---|---|---|
Application |
SingletonComponent |
@Singleton |
Activity |
ActivityRetainedComponent |
@ActivityRetainedScoped |
ViewModel |
ViewModelComponent |
@ViewModelScoped |
Activity |
ActivityComponent |
@ActivityScoped |
Fragment |
FragmentComponent |
@FragmentScoped |
View |
ViewComponent |
@ViewScoped |
View annotato con @WithFragmentBindings |
ViewWithFragmentComponent |
@ViewScoped |
Service |
ServiceComponent |
@ServiceScoped |
Nell'esempio, se limiti AnalyticsAdapter
all'ambito ActivityComponent
utilizzando @ActivityScoped
, Hilt fornisce la stessa istanza di AnalyticsAdapter
durante l'intero ciclo di vita dell'attività corrispondente:
Kotlin
@ActivityScoped class AnalyticsAdapter @Inject constructor( private val service: AnalyticsService ) { ... }
Java
@ActivityScoped public class AnalyticsAdapter { private final AnalyticsService service; @Inject AnalyticsAdapter(AnalyticsService service) { this.service = service; } ... }
Supponiamo che AnalyticsService
abbia uno stato interno che richiede di utilizzare sempre la stessa istanza, non solo in ExampleActivity
, ma in qualsiasi punto dell'app. In questo caso, è opportuno limitare AnalyticsService
a SingletonComponent
. Il risultato è che ogni volta che il componente deve fornire un'istanza di AnalyticsService
, fornisce sempre la stessa istanza.
L'esempio seguente mostra come definire l'ambito di una associazione a un componente in un modulo Hilt. L'ambito di un'associazione deve corrispondere all'ambito del componente in cui è installata, quindi in questo esempio devi installare AnalyticsService
in SingletonComponent
anziché in ActivityComponent
:
Kotlin
// If AnalyticsService is an interface. @Module @InstallIn(SingletonComponent::class) abstract class AnalyticsModule { @Singleton @Binds abstract fun bindAnalyticsService( analyticsServiceImpl: AnalyticsServiceImpl ): AnalyticsService } // If you don't own AnalyticsService. @Module @InstallIn(SingletonComponent::class) object AnalyticsModule { @Singleton @Provides fun provideAnalyticsService(): AnalyticsService { return Retrofit.Builder() .baseUrl("https://example.com") .build() .create(AnalyticsService::class.java) } }
Java
// If AnalyticsService is an interface. @Module @InstallIn(SingletonComponent.class) public abstract class AnalyticsModule { @Singleton @Binds public abstract AnalyticsService bindAnalyticsService( AnalyticsServiceImpl analyticsServiceImpl ); } // If you don't own AnalyticsService. @Module @InstallIn(SingletonComponent.class) public class AnalyticsModule { @Singleton @Provides public static AnalyticsService provideAnalyticsService() { return new Retrofit.Builder() .baseUrl("https://example.com") .build() .create(AnalyticsService.class); } }
Per scoprire di più sugli ambiti dei componenti Hilt, consulta Scoping in Android and Hilt.
Gerarchia dei componenti
L'installazione di un modulo in un componente consente di accedere alle relative associazioni come dipendenza di altre associazioni nel componente o in qualsiasi componente secondario sottostante nella gerarchia dei componenti:
Associazioni predefinite dei componenti
Ogni componente Hilt è dotato di un insieme di associazioni predefinite che Hilt può iniettare come dipendenze nelle tue associazioni personalizzate. Tieni presente che queste associazioni corrispondono ai tipi di attività e frammenti generali e non a una sottoclasse specifica. Questo perché Hilt utilizza una singola definizione del componente dell'attività per iniettare tutte le attività. Ogni attività ha un'istanza diversa di questo componente.
Componente Android | Associazioni predefinite |
---|---|
SingletonComponent |
Application |
ActivityRetainedComponent |
Application |
ViewModelComponent |
SavedStateHandle |
ActivityComponent |
Application , Activity |
FragmentComponent |
Application , Activity e Fragment |
ViewComponent |
Application , Activity e View |
ViewWithFragmentComponent |
Application , Activity , Fragment , View |
ServiceComponent |
Application , Service |
Il binding del contesto dell'applicazione è disponibile anche utilizzando @ApplicationContext
.
Ad esempio:
Kotlin
class AnalyticsServiceImpl @Inject constructor( @ApplicationContext context: Context ) : AnalyticsService { ... } // The Application binding is available without qualifiers. class AnalyticsServiceImpl @Inject constructor( application: Application ) : AnalyticsService { ... }
Java
public class AnalyticsServiceImpl implements AnalyticsService { private final Context context; @Inject AnalyticsAdapter(@ApplicationContext Context context) { this.context = context; } } // The Application binding is available without qualifiers. public class AnalyticsServiceImpl implements AnalyticsService { private final Application application; @Inject AnalyticsAdapter(Application application) { this.application = application; } }
Il binding del contesto dell'attività è disponibile anche utilizzando @ActivityContext
. Per
esempio:
Kotlin
class AnalyticsAdapter @Inject constructor( @ActivityContext context: Context ) { ... } // The Activity binding is available without qualifiers. class AnalyticsAdapter @Inject constructor( activity: FragmentActivity ) { ... }
Java
public class AnalyticsAdapter { private final Context context; @Inject AnalyticsAdapter(@ActivityContext Context context) { this.context = context; } } // The Activity binding is available without qualifiers. public class AnalyticsAdapter { private final FragmentActivity activity; @Inject AnalyticsAdapter(FragmentActivity activity) { this.activity = activity; } }
Iniettare dipendenze in classi non supportate da Hilt
Hilt supporta le classi Android più comuni. Tuttavia, potresti dover eseguire l'iniezione di campo nei classi non supportati da Hilt.
In questi casi, puoi creare un punto di contatto utilizzando l'annotazione @EntryPoint
. Un punto di contatto è il confine tra il codice gestito da Hilt
e quello non gestito. È il punto in cui il codice entra per la prima volta nel grafico degli oggetti gestiti da Hilt. I punti di contatto consentono a Hilt di utilizzare il codice di cui non riesce a fornire le dipendenze all'interno del grafo delle dipendenze.
Ad esempio, Hilt non supporta direttamente i fornitori di contenuti. Se vuoi che un fornitore di contenuti utilizzi Hilt per ottenere alcune dipendenze, devi definire un'interfaccia annotata con @EntryPoint
per ogni tipo di associazione che ti interessa e includere i qualificatori. Aggiungi @InstallIn
per specificare il componente in cui installare il punto di contatto come segue:
Kotlin
class ExampleContentProvider : ContentProvider() { @EntryPoint @InstallIn(SingletonComponent::class) interface ExampleContentProviderEntryPoint { fun analyticsService(): AnalyticsService } ... }
Java
public class ExampleContentProvider extends ContentProvider { @EntryPoint @InstallIn(SingletonComponent.class) interface ExampleContentProviderEntryPoint { public AnalyticsService analyticsService(); } ... }
Per accedere a un punto di contatto, utilizza il metodo statico appropriato di
EntryPointAccessors
. Il parametro deve essere l'istanza del componente o
l'oggetto @AndroidEntryPoint
che funge da contenitore del componente. Assicurati che il componente passato come parametro e il metodo statico EntryPointAccessors
corrispondano entrambi alla classe Android nell'annotazione @InstallIn
dell'interfaccia @EntryPoint
:
Kotlin
class ExampleContentProvider: ContentProvider() { ... override fun query(...): Cursor { val appContext = context?.applicationContext ?: throw IllegalStateException() val hiltEntryPoint = EntryPointAccessors.fromApplication(appContext, ExampleContentProviderEntryPoint::class.java) val analyticsService = hiltEntryPoint.analyticsService() ... } }
Java
public class ExampleContentProvider extends ContentProvider { @Override public Cursor query(...) { Context appContext = getContext().getApplicationContext(); ExampleContentProviderEntryPoint hiltEntryPoint = EntryPointAccessors.fromApplication(appContext, ExampleContentProviderEntryPoint.class); AnalyticsService analyticsService = hiltEntryPoint.analyticsService(); } }
In questo esempio, devi utilizzare ApplicationContext
per recuperare il punto di ingresso perché è installato in SingletonComponent
. Se la associazione che volevi recuperare si trovasse in ActivityComponent
, dovresti utilizzare ActivityContext
.
Hilt and Dagger
Hilt è basato sulla libreria di dipendenza Dagger e fornisce un modo standard per incorporare Dagger in un'applicazione Android.
Rispetto a Dagger, gli obiettivi di Hilt sono i seguenti:
- Per semplificare l'infrastruttura relativa a Dagger per le app Android.
- Per creare un insieme standard di componenti e ambiti per semplificare la configurazione, la leggibilità e la condivisione del codice tra le app.
- Per fornire un modo semplice per eseguire il provisioning di associazioni diverse a vari tipi di build, come test, debug o release.
Poiché il sistema operativo Android esegue l'inizializzazione di molte delle sue classi di framework, l'utilizzo di Dagger in un'app per Android richiede di scrivere una quantità sostanziale di codice boilerplate. Hilt riduce il codice boilerplate necessario per utilizzare Dagger in un'applicazione Android. Hilt genera automaticamente e fornisce quanto segue:
- Componenti per l'integrazione delle classi del framework Android con Dagger che altrimenti dovresti creare manualmente.
- Annotazioni dell'ambito da utilizzare con i componenti generati automaticamente da Hilt.
- Associazioni predefinite per rappresentare classi Android come
Application
oActivity
. - Qualificatori predefiniti per rappresentare
@ApplicationContext
e@ActivityContext
.
Il codice di Dagger e Hilt può coesistere nella stessa base di codice. Tuttavia, nella maggior parte dei casi è meglio utilizzare Hilt per gestire tutto l'utilizzo di Dagger su Android. Per eseguire la migrazione di un progetto che utilizza Dagger a Hilt, consulta la guida alla migrazione e il codelab Migrazione della tua app Dagger a Hilt.
Risorse aggiuntive
Per scoprire di più su Hilt, consulta le seguenti risorse aggiuntive.
Campioni
Codelab
Blog
- Dependency Injection su Android con Hilt
- Scoping in Android e Hilt
- Aggiunta di componenti alla gerarchia di Hilt
- Eseguire la migrazione dell'app Google I/O a Hilt