הזרקת תלות באמצעות Hilt

‫Hilt היא ספריית החדרת תלות ל-Android שמפחיתה את הקוד החוזר (boilerplate) של החדרת תלות ידנית בפרויקט. כדי לבצע הזרקת תלות ידנית, צריך לבנות כל מחלקה ואת יחסי התלות שלה באופן ידני, ולהשתמש בקונטיינרים כדי לנהל את יחסי התלות ולהשתמש בהם שוב.

‫Hilt מספקת דרך סטנדרטית להשתמש ב-DI באפליקציה, על ידי מתן קונטיינרים לכל מחלקת Android בפרויקט וניהול מחזורי החיים שלהם באופן אוטומטי. ‫Hilt מבוססת על ספריית ה-DI הפופולרית Dagger, כדי ליהנות מהתקינות בזמן הקימפול, מהביצועים בזמן הריצה, מהיכולת להתאים לעומס ומהתמיכה ב-Android Studio ש-Dagger מספקת. מידע נוסף זמין במאמר Hilt ו-Dagger.

במדריך הזה נסביר את המושגים הבסיסיים של Hilt והקונטיינרים שנוצרים על ידו. הוא כולל גם הדגמה של הוספת Hilt לאפליקציה קיימת.

הוספת יחסי תלות

קודם כול, מוסיפים את הפלאגין hilt-android-gradle-plugin לקובץ build.gradle ברמה הבסיסית (root) של הפרויקט:

Kotlin

plugins {
  ...
  id("com.google.dagger.hilt.android") version "2.57.1" apply false
}

מגניב

plugins {
  ...
  id 'com.google.dagger.hilt.android' version '2.57.1' apply false
}

לאחר מכן, מפעילים את הפלאגין של Gradle ומוסיפים את יחסי התלות האלה לקובץ app/build.gradle:

Kotlin

plugins {
  id("com.google.devtools.ksp")
  id("com.google.dagger.hilt.android")
}

android {
  ...
}

dependencies {
  implementation("com.google.dagger:hilt-android:2.57.1")
  ksp("com.google.dagger:hilt-android-compiler:2.57.1")
}

מגניב

...
plugins {
  id 'com.google.devtools.ksp'
  id 'com.google.dagger.hilt.android'
}

android {
  ...
}

dependencies {
  implementation "com.google.dagger:hilt-android:2.57.1"
  ksp "com.google.dagger:hilt-compiler:2.57.1"
}

כדי לוודא שהפרויקט מוגדר ל-Java 17, שנדרש לגרסאות של Jetpack Compose ו-Hilt, מוסיפים את הקוד הבא לקובץ app/build.gradle:

Kotlin

android {
  ...
  compileOptions {
    sourceCompatibility = JavaVersion.VERSION_17
    targetCompatibility = JavaVersion.VERSION_17
  }
}

מגניב

android {
  ...
  compileOptions {
    sourceCompatibility JavaVersion.VERSION_17
    targetCompatibility JavaVersion.VERSION_17
  }
}

מחלקה של אפליקציית Hilt

כל האפליקציות שמשתמשות ב-Hilt חייבות להכיל מחלקה של Application עם הערה של @HiltAndroidApp.

@HiltAndroidApp מפעיל את יצירת הקוד של Hilt, כולל מחלקה בסיסית לאפליקציה שמשמשת כמאגר יחסי התלות ברמת האפליקציה.

@HiltAndroidApp
class ExampleApplication : Application() { ... }

רכיב ה-Hilt שנוצר מצורף למחזור החיים של האובייקט Application ומספק לו יחסי תלות. בנוסף, זהו רכיב ההורה של האפליקציה, כלומר רכיבים אחרים יכולים לגשת ליחסי התלות שהוא מספק.

הזרקת יחסי תלות למחלקות ב-Android

אחרי שמגדירים את Hilt במחלקה Application ורכיב ברמת האפליקציה זמין, Hilt יכול לספק יחסי תלות למחלקות אחרות של Android עם ההערה @AndroidEntryPoint:

@AndroidEntryPoint
class ExampleActivity : ComponentActivity() { ... }

‫Hilt תומך כרגע במחלקות הבאות של Android:

• ‫Application (באמצעות @HiltAndroidApp)
• ‫ViewModel (באמצעות @HiltViewModel)
• Activity
• Service
• BroadcastReceiver

ב-Compose, לא צריך להוסיף הערות לפונקציות ה-composable הנפרדות. במקום זאת, הוסיפו הערה ל-ComponentActivity ברמה הבסיסית (root) באמצעות @AndroidEntryPoint. היא משמשת כנקודת הכניסה היחידה של ה-DI לכל היררכיית ממשק המשתמש, כך שתוכלו לגשת ל-ViewModels שהוזרקו ל-Hilt ישירות בתוך הפונקציות הקומפוזביליות.

הערה: Hilt תומך רק בפעילויות שמרחיבות את ComponentActivity, כמו AppCompatActivity.

‫@AndroidEntryPoint יוצר רכיב Hilt נפרד לכל מחלקת Android בפרויקט. הרכיבים האלה יכולים לקבל יחסי תלות מהמחלקות ההורה שלהם, כמו שמתואר בקטע היררכיית רכיבים.

כדי לקבל יחסי תלות מרכיב, משתמשים בהערה @Inject כדי לבצע החדרה לשדה:

@AndroidEntryPoint
class ExampleActivity : ComponentActivity() {

  @Inject lateinit var analytics: AnalyticsAdapter
  ...
}

הערה: שדות שמוחדרים על ידי Hilt לא יכולים להיות פרטיים. ניסיון להחדיר שדה פרטי באמצעות Hilt יוביל לשגיאת קומפילציה.

למחלקות ש-Hilt מחדיר יכולות להיות מחלקות בסיסיות אחרות שגם משתמשות בהחדרה. אם המחלקות האלה מופשטות, הן לא צריכות את ההערה @AndroidEntryPoint.

במאמר משך החיים של רכיבים מוסבר בהרחבה לאיזו קריאה חוזרת במחזור חיים מוזרקת מחלקת Android.

הגדרת קישורי Hilt

כדי לבצע החדרה לשדה, Hilt צריך לדעת איך לספק מופעים של יחסי התלות הנדרשים מהרכיב המתאים. קישור מכיל את המידע שנדרש כדי לספק מופעים של סוג כתלות.

אחת הדרכים לספק מידע על קישור ל-Hilt היא החדרה ל-constructor. משתמשים בהערה @Inject ב-constructor של מחלקה כדי להורות ל-Hilt איך לספק מופעים של המחלקה הזו:

class AnalyticsAdapter @Inject constructor(
  private val service: AnalyticsService
) { ... }

הפרמטרים של ה-constructor של המחלקה הם יחסי התלות של המחלקה הזו. בדוגמה, AnalyticsAdapter תלוי ב-AnalyticsService. לכן, Hilt צריך גם לדעת איך לספק מופעים של AnalyticsService.

הערה: בזמן ה-build, ‏Hilt יוצר רכיבי Dagger למחלקות של Android. אחר כך, Dagger עובר על הקוד ומבצע את השלבים הבאים:

• בונה ומאמת תרשימי תלות, כדי לוודא שאין תלויות שלא נענו ואין מחזורי תלות.
• יוצר את המחלקות שבהן הוא משתמש בזמן הריצה כדי ליצור את האובייקטים בפועל ואת יחסי התלות שלהם.

מודולים של Hilt

לפעמים אי אפשר להחדיר סוג ל-constructor. יכולות להיות לכך כמה סיבות. לדוגמה, אי אפשר להחדיר ממשק ל-constructor. בנוסף, אי אפשר להשתמש בהחדרה ל-constructor בסוג שלא בבעלותכם, כמו מחלקה מספרייה חיצונית. במקרים כאלה, אתם יכולים לספק ל-Hilt מידע על הקישור באמצעות מודולים של Hilt.

מודול Hilt הוא מחלקה שמסומנת ב-@Module. הוא מספק ל-Hilt הוראות ליצירת מכונות של סוגים שלא ניתן לספק באמצעות החדרה ל-constructor, כמו ממשקים או מחלקות של צד שלישי. צריך גם להוסיף לכל מודול הערה עם @InstallIn כדי לציין ל-Hilt באיזו מחלקת Android כל מודול ישמש או יותקן.

הערה: מודולים של Hilt שונים ממודולים של Gradle.

יחסי התלות שאתם מספקים במודולים של Hilt זמינים בכל הרכיבים שנוצרו ומשויכים למחלקת Android שבה אתם מתקינים את המודול של Hilt.

הערה: כדי ליצור קוד ב-Hilt, צריך גישה לכל המודולים של Gradle שמשתמשים ב-Hilt. לכן, המודול של Gradle שמקמפל את המחלקה Application צריך לכלול גם את כל המודולים של Hilt והמחלקות שהוחדרו ל-constructor ביחסי התלות הטרנזיטיביים שלו.

הזרקת מופעי ממשק באמצעות ‎ @Binds

לדוגמה, נניח שאתם רוצים להשתמש ב-AnalyticsService. אם AnalyticsService הוא ממשק, אי אפשר להחדיר אותו ל-constructor. במקום זאת, צריך לספק ל-Hilt את פרטי הקישור על ידי יצירת פונקציה מופשטת עם הערה @Binds בתוך מודול Hilt.

ההערה @Binds מציינת ל-Hilt באיזו הטמעה להשתמש כשהוא צריך לספק מופע של ממשק.

הפונקציה עם ההערה מספקת ל-Hilt את המידע הבא:

• סוג ההחזרה של הפונקציה מציין ל-Hilt איזה ממשק הפונקציה מספקת מופעים שלו.
• הפרמטר של הפונקציה מציין ל-Hilt איזו הטמעה לספק.

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
}

המודול AnalyticsModule של Hilt מסומן באמצעות ההערה @InstallIn(ActivityComponent.class) כי אתם רוצים ש-Hilt יוסיף את התלות הזו אל ExampleActivity. ההערה הזו מציינת שכל יחסי התלות ב-AnalyticsModule זמינים בכל הפעילויות של האפליקציה.

הזרקת מופעים באמצעות ‎ @Provides

ממשקים הם לא המקרה היחיד שבו אי אפשר להחדיר סוג ל-constructor. בנוסף, אי אפשר להשתמש בהחדרה ל-constructor אם המחלקה לא בבעלותכם כי היא מגיעה מספרייה חיצונית (מחלקות כמו Retrofit,‏ OkHttpClient או מסדי נתונים של Room), או אם צריך ליצור מופעים באמצעות תבנית ה-builder.

נחזור לדוגמה הקודמת. אם המחלקה AnalyticsService לא בבעלותכם הישירה, אתם יכולים להורות ל-Hilt איך לספק מופעים מהסוג הזה. כדי לעשות את זה, יוצרים פונקציה בתוך מודול Hilt ומוסיפים לפונקציה הזו את ההערה @Provides.

הפונקציה עם ההערה מספקת ל-Hilt את המידע הבא:

• סוג ההחזרה של הפונקציה מציין ל-Hilt את סוג המופעים שהפונקציה מספקת.
• הפרמטרים של הפונקציה מציינים ל-Hilt את יחסי התלות של הסוג המתאים.
• גוף הפונקציה מציין ל-Hilt איך לספק מופע של הסוג המתאים. ‫Hilt מפעיל את גוף הפונקציה בכל פעם שהוא צריך לספק מופע של הסוג הזה.

@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)
  }
}

לספק כמה קישורים לאותו סוג

במקרים שבהם אתם צריכים ש-Hilt יספק הטמעות שונות של אותו סוג כתלויות, אתם צריכים לספק ל-Hilt כמה קישורים. אפשר להגדיר כמה קישורים לאותו סוג באמצעות מגדירים.

מגדיר הוא הערה שמשמשת לזיהוי קישור ספציפי לסוג מסוים, כשלסוג הזה יש כמה קישורים מוגדרים.

לדוגמה: אם אתם צריכים ליירט קריאות ל-AnalyticsService, אתם יכולים להשתמש באובייקט OkHttpClient עם מיירט. בשירותים אחרים, יכול להיות שתצטרכו ליירט קריאות בדרך אחרת. במקרה כזה, צריך להגדיר ל-Hilt איך לספק שתי הטמעות שונות של OkHttpClient.

קודם כל, מגדירים את המאפיינים שבהם תשתמשו כדי להוסיף הערות ל-methods‏ @Binds או @Provides:

@Qualifier
@Retention(AnnotationRetention.BINARY)
annotation class AuthInterceptorOkHttpClient

@Qualifier
@Retention(AnnotationRetention.BINARY)
annotation class OtherInterceptorOkHttpClient

לאחר מכן, צריך להגדיר ל-Hilt איך לספק מופע של הסוג שתואם לכל מגדיר. במקרה כזה, אפשר להשתמש במודול Hilt עם @Provides. לשתי השיטות יש את אותו סוג החזרה, אבל המגדירים מתייגים אותן כשני קישורים שונים:

@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()
  }
}

כדי להחדיר את הסוג הספציפי שאתם צריכים, אתם יכולים להוסיף הערה לשדה או לפרמטר עם המאפיין המתאים:

// 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: ComponentActivity() {

  @AuthInterceptorOkHttpClient
  @Inject lateinit var okHttpClient: OkHttpClient
}

כשיטה מומלצת, אם מוסיפים מגדיר לסוג, צריך להוסיף מגדירים לכל הדרכים האפשריות לספק את התלות הזו. אם משאירים את ההטמעה הבסיסית או הנפוצה בלי מגדיר, עלולות להתרחש שגיאות ו-Hilt עלול להחדיר את התלות הלא נכונה.

מגדירים מוגדרים מראש ב-Hilt

‫Hilt מספק כמה מגדירים מוגדרים מראש. לדוגמה, יכול להיות שתצטרכו את המחלקה Context מהאפליקציה או מהפעילות, אז Hilt מספק את המאפיינים @ApplicationContext ו-@ActivityContext.

נניח שהמחלקה AnalyticsAdapter מהדוגמה צריכה את ההקשר של הפעילות. בדוגמת הקוד הבאה אפשר לראות איך מספקים את ההקשר של הפעילות ל-AnalyticsAdapter:

class AnalyticsAdapter @Inject constructor(
    @ActivityContext private val context: Context,
    private val service: AnalyticsService
) { ... }

למידע על קישורים מוגדרים מראש אחרים שזמינים ב-Hilt, קראו את המאמר קישורי ברירת המחדל של רכיבים.

רכיבים שנוצרו בשביל מחלקות ב-Android

לכל מחלקת Android שבה אפשר לבצע החדרה לשדה, יש רכיב Hilt משויך שאפשר להפנות אליו בהערה @InstallIn. כל רכיב Hilt אחראי להזרקת הקישורים שלו למחלקת Android המתאימה.

בדוגמאות הקודמות הראינו איך משתמשים ב-ActivityComponent במודולים של Hilt.

‫Hilt מספק את הרכיבים הבאים:

רכיב Hilt	מזרק עבור
SingletonComponent	Application
ActivityRetainedComponent	לא רלוונטי
ViewModelComponent	ViewModel
ActivityComponent	Activity
ServiceComponent	Service

הערה: Hilt לא יוצר רכיב למקלטי שידור כי Hilt מחדיר מקלטי שידור ישירות מ-SingletonComponent.

משך החיים של הרכיבים

‫Hilt יוצרת ומשמידה באופן אוטומטי מופעים של מחלקות רכיבים שנוצרו, בהתאם למחזור החיים של מחלקות Android התואמות.

רכיב שנוצר	תאריך ושעת יצירה	הושמד בתאריך
SingletonComponent	Application#onCreate()	‫Application הושמד
ActivityRetainedComponent	Activity#onCreate()	Activity#onDestroy()
ViewModelComponent	נוצרו ViewModel	‫ViewModel הושמד
ActivityComponent	Activity#onCreate()	Activity#onDestroy()
ServiceComponent	Service#onCreate()	Service#onDestroy()

הערה: ActivityRetainedComponent נשאר גם כשמשנים את ההגדרות, ולכן הוא נוצר ב-Activity#onCreate() הראשון ונהרס ב-Activity#onDestroy() האחרון.

היקפי הרכיבים

כברירת מחדל, כל הקישורים ב-Hilt הם ללא היקף. כלומר, בכל פעם שהאפליקציה מבקשת את הקישור, Hilt יוצרת מופע חדש של הסוג הנדרש.

בדוגמה, בכל פעם ש-Hilt מספק את AnalyticsAdapter כתלות לסוג אחר או באמצעות החדרה לשדה (כמו ב-ExampleActivity), Hilt מספק מופע חדש של AnalyticsAdapter.

עם זאת, Hilt מאפשר גם להגדיר את ההיקף של קישור לרכיב מסוים. ‫Hilt יוצר קישור מוגדר היקף רק פעם אחת לכל מופע של הרכיב שהקישור מוגדר בהיקף שלו, וכל הבקשות לקישור הזה משתפות את אותו מופע.

בטבלה הבאה מפורטות הערות היקף לכל רכיב שנוצר:

כיתת Android	רכיב שנוצר	היקף
Application	SingletonComponent	@Singleton
Activity	ActivityRetainedComponent	@ActivityRetainedScoped
ViewModel	ViewModelComponent	@ViewModelScoped
Activity	ActivityComponent	@ActivityScoped
Service	ServiceComponent	@ServiceScoped

בדוגמה, אם מגדירים את ההיקף של AnalyticsAdapter ל-ActivityComponent באמצעות @ActivityScoped, ‏Hilt מספק את אותו מופע של AnalyticsAdapter לאורך כל משך החיים של הפעילות התואמת:

@ActivityScoped
class AnalyticsAdapter @Inject constructor(
  private val service: AnalyticsService
) { ... }

הערה: הגדרת היקף של קישור לרכיב יכולה להיות יקרה כי האובייקט שסופק נשאר בזיכרון עד שהרכיב הזה נהרס. צמצמו את השימוש בקישורים ברמת ההיקף באפליקציה. כדאי להשתמש בקישורים ברמת הרכיב לקישורים עם מצב פנימי שדורש שימוש באותו מופע בטווח מסוים, לקישורים שצריכים סנכרון או לקישורים שבדקתם וגיליתם שהיצירה שלהם יקרה.

נניח של-AnalyticsService יש מצב פנימי שדורש שימוש באותו מופע בכל פעם – לא רק ב-ExampleActivity, אלא בכל מקום באפליקציה. במקרה כזה, מתאים להגדיר את ההיקף של AnalyticsService ל-SingletonComponent. התוצאה היא שבכל פעם שהרכיב צריך לספק מופע של AnalyticsService, הוא מספק את אותו מופע.

בדוגמה הבאה מוסבר איך להגדיר את ההיקף של קישור לרכיב במודול Hilt. ההיקף של הקישור חייב להתאים להיקף של הרכיב שבו הוא מותקן. לכן, בדוגמה הזו צריך להתקין את AnalyticsService ב-SingletonComponent במקום ב-ActivityComponent:

// 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)
  }
}

מידע נוסף על היקפי הרכיבים של Hilt זמין במאמר Scoping in Android and Hilt.

הערה: למידע נוסף על ההבדלים בין הגדרת היקף באמצעות @ActivityRetainedScoped או @ViewModelScoped, אפשר לעיין בקטע @ViewModelScoped במסמך השילובים של Hilt ו-Jetpack.

היררכיית הרכיבים

כשמתקינים מודול ברכיב, אפשר לגשת לקישורים שלו כתלות של קישורים אחרים באותו רכיב או בכל רכיב צאצא שמתחתיו בהיררכיית הרכיבים.

איור 1. ההיררכיה של הרכיבים שנוצרים על ידי Hilt.

קישורי ברירת המחדל של הרכיב

כל רכיב Hilt מגיע עם קבוצה של קישורים שמוגדרים כברירת מחדל, ש-Hilt יכול להחדיר כתלויות לקישורים בהתאמה אישית. שימו לב שהקישורים האלה תואמים לסוג הפעילות הכללי ולא לתת-מחלקה ספציפית. הסיבה לכך היא ש-Hilt משתמש בהגדרה של רכיב פעילות אחד כדי להחדיר את כל הפעילויות. לכל פעילות יש מופע שונה של הרכיב הזה.

רכיב Android	קישורים שמוגדרים כברירת מחדל
SingletonComponent	Application
ActivityRetainedComponent	Application
ViewModelComponent	SavedStateHandle
ActivityComponent	Application, Activity
ServiceComponent	Application, Service

אפשר גם להשתמש ב-@ApplicationContext כדי לקשר את ההקשר של האפליקציה. לדוגמה:

class AnalyticsServiceImpl @Inject constructor(
  @ApplicationContext context: Context
) : AnalyticsService { ... }

// The Application binding is available without qualifiers.
class AnalyticsServiceImpl @Inject constructor(
  application: Application
) : AnalyticsService { ... }

אפשר גם להשתמש ב-@ActivityContext כדי לקשר את הקשר הפעילות. לדוגמה:

class AnalyticsAdapter @Inject constructor(
  @ActivityContext context: Context
) { ... }

// The Activity binding is available without qualifiers.
class AnalyticsAdapter @Inject constructor(
  activity: ComponentActivity
) { ... }

הזרקת יחסי תלות במחלקות שלא נתמכות על ידי Hilt

בפיתוח נייטיב, התבנית הרגילה היא להחדיר יחסי תלות ל-@HiltViewModel באמצעות החדרת constructor, ואז להשתמש ב-hiltViewModel() בתוך ה-composable כדי לגשת ל-ViewModel. למרות ש-Hilt תומכת במחלקות הנפוצות ביותר של Android, עדיין יכול להיות שתיתקלו במחלקות לא נתמכות שבהן תצטרכו לבצע החדרה לשדה.

במקרים כאלה, אפשר ליצור נקודת כניסה באמצעות ההערה @EntryPoint. נקודת כניסה היא הגבול בין קוד שמנוהל על ידי Hilt לבין קוד שלא מנוהל על ידי Hilt. זו הנקודה שבה הקוד נכנס לראשונה לתרשים האובייקטים ש-Hilt מנהלת. נקודות כניסה מאפשרות ל-Hilt להשתמש בקוד ש-Hilt לא מנהל כדי לספק יחסי תלות בתוך תרשים יחסי התלות.

לדוגמה, Hilt לא תומך ישירות בספקים לניהול גישה. אם אתם רוצים שספק לניהול גישה ישתמש ב-Hilt כדי לקבל יחסי תלות מסוימים, אתם צריכים להגדיר ממשק עם הערה @EntryPoint לכל סוג קישור שאתם רוצים, ולכלול מגדירים. לאחר מכן מוסיפים את @InstallIn כדי לציין את הרכיב שבו רוצים להתקין את נקודת הכניסה, באופן הבא:

class ExampleContentProvider : ContentProvider() {

  @EntryPoint
  @InstallIn(SingletonComponent::class)
  interface ExampleContentProviderEntryPoint {
    fun analyticsService(): AnalyticsService
  }

  ...
}

כדי לגשת לנקודת כניסה, צריך להשתמש בשיטה הסטטית המתאימה מ-EntryPointAccessors. הפרמטר צריך להיות המופע של הרכיב או האובייקט @AndroidEntryPoint שפועל כמחזיק הרכיב. חשוב לוודא שהרכיב שמעבירים כפרמטר והשיטה הסטטית EntryPointAccessors תואמים למחלקת Android בהערה @InstallIn בממשק @EntryPoint:

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()
    ...
  }
}

בדוגמה הזו, צריך להשתמש ב-ApplicationContext כדי לאחזר את נקודת הכניסה כי היא מותקנת ב-SingletonComponent. אם הקישור שרציתם לאחזר היה ב-ActivityComponent, הייתם צריכים להשתמש ב-ActivityContext.

Hilt ו-Dagger

‫Hilt היא הספרייה המומלצת באופן רשמי להזרקת תלויות ב-Android. הוא מספק דרך סטנדרטית, מוגדרת מראש ויעילה להטמיע הזרקת תלות באפליקציה, שעברה אופטימיזציה ספציפית לארכיטקטורות של Jetpack Compose ושל פעילות אחת.

אלה המטרות של Hilt:

• כדי ליצור קבוצה סטנדרטית של רכיבים והיקפים, שתקל על ההגדרה, הקריאוּת ושיתוף הקוד בין אפליקציות.
• כדי לספק דרך קלה להקצות קישורים שונים לסוגי build שונים, כמו בדיקה, ניפוי באגים או הפצה.

מכיוון שמערכת ההפעלה Android יוצרת מופעים של הרבה ממחלקות ה-framework שלה, כדי להשתמש ב-Dagger באפליקציה ל-Android צריך לכתוב כמות משמעותית של קוד סטנדרטי. ‫Hilt מצמצם את הקוד שחוזר על עצמו (boilerplate) שמעורב בשימוש ב-Dagger באפליקציה ל-Android. ‫Hilt יוצר ומספק באופן אוטומטי את הרכיבים הבאים:

• רכיבים לשילוב של מחלקות מסגרת של Android עם Dagger, שאחרת הייתם צריכים ליצור באופן ידני.
• הערות היקף לשימוש עם הרכיבים ש-Hilt יוצר באופן אוטומטי.
• קישורים מוגדרים מראש לייצוג מחלקות של Android כמו Application או Activity.
• מגדירים מראש שמייצגים את @ApplicationContext ו-@ActivityContext.

קוד Dagger וקוד Hilt יכולים להתקיים יחד באותו בסיס קוד. עם זאת, ברוב המקרים מומלץ להשתמש ב-Hilt כדי לנהל את כל השימוש ב-Dagger ב-Android. כדי להעביר פרויקט שמשתמש ב-Dagger ל-Hilt, עיינו במדריך להעברת נתונים.

מקורות מידע נוספים

איפה אפשר למצוא מידע נוסף על Hilt?

דוגמאות

בלוגים

• Dependency Injection on Android with Hilt
• היקף ב-Android וב-Hilt
• הוספת רכיבים להיררכיה של Hilt
• איך מעבירים את אפליקציית Google I/O ל-Hilt

צפייה בתוכן

• החדרת תלות באמצעות Hilt (תצוגות)