Ja izstrādājat Android lietojumprogrammas, iespējams, esat saskāries ar nepieciešamību labāk organizēt savas klases, lai novērstu projekta ieslīgšanu pilnīgā haosā. Šeit noder atkarību injekcija — dizaina modelis, kas, lai gan sākotnēji varētu šķist kā melnā maģija, būtībā ir veids, kā nodrošināt katru klasi ar tai nepieciešamajiem objektiem, klasei pašai tos neveidojot.
Hilt ierodas, lai glābtu mūs no Dagger sarežģītības, piedāvājot augšējo slāni, kas standartizē atkarību ievietošanu . Integrējoties ar Jetpack, Hilt automātiski pārvalda konteinerus un dzīves ciklus, ļaujot mums koncentrēties uz biznesa loģiku, nevis pārvietot objektus, it kā mēs pārceltos uz citu māju.
Sākotnējā vides konfigurācija
Lai sāktu darbu ar Hilt, pirmais solis ir sagatavot Gradle vidi. Ir svarīgi pievienot hilt-android-gradle-spraudni projekta līmeņa konfigurācijas failam. Pēc tam lietojumprogrammas moduļa failā jālieto spraudnis un jāpievieno atbilstošās atkarības, nodrošinot, ka kompilators (neatkarīgi no tā, vai tiek izmantots kapt vai KSP) ir pareizi konfigurēts.
Viena būtiska detaļa ir tā, ka, lai viss noritētu nevainojami, projektam jābūt konfigurētam Java 17 (vai Java 8 vecākām versijām) izmantošanai, jo tas ir priekšnoteikums Hilt un Jetpack Compose netraucētai sadarbībai. Ja pamanāt, ka programma nekompilējas, aktivizējot spraudni, vēlreiz pārbaudiet, vai Kotlin un KSP versijas precīzi sakrīt, jo pat neliela neatbilstība var sabojāt visu kompilācijas procesu.
Hilt sirds: Lietojumprogrammu klase
Jebkurai lietotnei, kas vēlas izmantot šo bibliotēku, ir jābūt pielāgotai lietojumprogrammas klasei. Ar tās vienkāršu izveidi nepietiek; tā ir jāatzīmē ar anotāciju @HiltAndroidApp . Šī rinda aktivizē Hilt koda ģenerēšanu un izveido lietojumprogrammas saknes konteineru.
Šis augstākā līmeņa komponents ir vitāli svarīgs, jo tas ir saistīts ar lietotnes kopējo dzīves ciklu un kalpo par pamatu visiem pārējiem komponentiem , lai piekļūtu šajā līmenī definētajām atkarībām. Protams, neaizmirstiet reģistrēt šo klasi failā AndroidManifest.xml, izmantojot atribūtu name, pretējā gadījumā Hilt paliks pilnīgi nepamanīts.
Atkarību ievadīšana Android komponentos
Kad lietojumprogramma ir gatava, mēs varam sākt injicēt atkarības aktivitātēs, fragmentos, skatos vai pakalpojumos. Lai to izdarītu, mēs izmantojam anotāciju @AndroidEntryPoint . Tas norāda Hilt, ka šī klase ir ieejas punkts un ka tai jāģenerē īpašs komponents.
Kad aktivitātes ietvaros vēlamies iegūt noteiktu atkarību, izmantojam lauka injekciju, izmantojot anotāciju @Inject. Ir ļoti svarīgi atcerēties, ka šie lauki nevar būt privāti ; ja mēģināsiet izmantot privāto modifikatoru, kompilators bez vilcināšanās izmetīs kļūdu. Jetpack Compose gadījumā, vienkārši anotējot saknes aktivitāti, mēs varam piekļūt ViewModel modeļiem tieši komponējamajās funkcijās.
Saikņu definēšanas stratēģijas
Hiltam ir jāzina, kā izveidot pieprasītos objektus. Tiešākais veids ir konstruktora injekcija , kur mēs ievietojam `@Inject` tieši pirms klases konstruktora. Tas ļauj Hiltam analizēt parametrus un noteikt, kā nodrošināt katru no šīm atkarībām.
Tomēr ir gadījumi, kad mums nav pilnīgas kontroles pār klasi, piemēram, izmantojot ārējās bibliotēkas, piemēram, Retrofit vai OkHttpClient. Šeit noder Hilt moduļi . Modulis ir klase, kas anotēta ar @Module, un tajā jāiekļauj @InstallIn, lai norādītu, kurā komponentā jāatrodas šai atkarībai.
- @Provides izmantošana: Tas tiek izmantots, ja klase ir trešās puses vai tai ir nepieciešams sarežģīts konstrukcijas modelis. Šeit mēs definējam funkciju, kas atgriež nepieciešamo instanci.
- Izmantojot @Binds: Šī ir ideāla iespēja, ja vēlamies sasaistīt saskarni ar konkrētu ieviešanu. Tā ir definēta kā abstrakta funkcija, kas norāda Hiltam: "kad kāds pieprasa šo saskarni, sniegt viņam šo ieviešanu."
Darbības joma un dzīves cikla pārvaldība
Pēc noklusējuma Hilt izveido jaunu instanci katru reizi, kad tiek pieprasīta atkarība. Tomēr dažreiz mums ir nepieciešams, lai objekts paliktu nemainīgs visā lietotnes vai ekrāna darbības laikā. Šim nolūkam mēs izmantojam komponentu tvērumus.
Ja atzīmēsim klasi ar @Singleton un instalēsim to SingletonComponent objektā, mums būs viena globāla instance. Ja vēlamies, lai objekts pastāvētu tikai aktivitātes laikā, ActivityComponent ietvaros izmantosim @ActivityScoped . Ir svarīgi nepārspīlēt ar tvērumu izmantošanu, jo objektu pārāk ilga glabāšana atmiņā var negatīvi ietekmēt lietojumprogrammas veiktspēju.
Īpaši gadījumi un kvalifikācijas
Dažreiz mums ir jāinjicē divas dažādas viena un tā paša interfeisa implementācijas. Lai nepārslogotu kompilatoru, mēs izmantojam kvalifikatorus . Kvalifikators būtībā ir pielāgota anotācija, ko izmanto, lai apzīmētu konkrētu saistījumu, ļaujot mums, piemēram, atšķirt HTTP klientu autentifikācijai no klienta vispārīgiem pieprasījumiem.
Turklāt Hilt vienkāršo lietas ar iepriekš definētiem kvalifikatoriem, piemēram, @ApplicationContext un @ActivityContext, kas ļauj iegūt Android kontekstu, manuāli nekonfigurējot moduļus. Visbeidzot, klasēm, kuras Hilt neatbalsta (piemēram, ContentProviders), mēs varam izmantot @EntryPoint anotāciju , izveidojot manuālu tiltu atkarību iegūšanai no Hilt grafika. Kopīgojiet šo informāciju, lai par to uzzinātu vairāk lietotāju.