home / skills / hoangnguyen0403 / agent-skills-standard / di

di skill

safe

This skill guides Android Hilt setup, modules, and constructor injection to enforce best practices and reduce boilerplate.

npx playbooks add skill hoangnguyen0403/agent-skills-standard --skill di

Review the files below or copy the command above to add this skill to your agents.

Files (2)

SKILL.md

1.1 KB

---
name: Android Dependency Injection (Hilt)
description: Standards for Hilt Setup, Scoping, and Modules
metadata:
  labels: [android, di, hilt, dagger]
  triggers:
    files: ['**/*Module.kt', '**/*Component.kt']
    keywords: ['@HiltAndroidApp', '@Inject', '@Provides', '@Binds']
---

# Android Dependency Injection (Hilt)

## **Priority: P0**

## Implementation Guidelines

### Setup

- **App**: Must annotate `Application` class with `@HiltAndroidApp`.
- **Entries**: Annotate Activities/Fragments with `@AndroidEntryPoint`.

### Modules

- **Binding**: Use `@Binds` (abstract class) over `@Provides` when possible (smaller generated code).
- **InstallIn**: Be explicit (`SingletonComponent`, `ViewModelComponent`).

### Construction

- **Constructor Injection**: Prefer over Field Injection (`@Inject constructor(...)`).
- **Assisted Injection**: Use for runtime parameters (`@AssistedInject`).

## Anti-Patterns

- **Component Manual Creation**: `**No Manual Dagger**: Use Hilt Standard.`
- **Field Inject in Logic**: `**No Field Inject**: Only in Android Components.`

## References

- [Module Templates](references/files.md)

Overview

This skill documents standards for setting up and using Hilt for dependency injection in Android projects. It focuses on correct annotations, module design, scoping choices, and anti-patterns to avoid. The goal is predictable, testable, and efficient DI wiring across Activities, Fragments, ViewModels, and application-level components.

How this skill works

The guidance enforces Hilt entry points by annotating the Application with @HiltAndroidApp and Android components with @AndroidEntryPoint. Modules should prefer @Binds for interface bindings and explicitly declare InstallIn scopes (e.g., SingletonComponent, ViewModelComponent). Constructor injection is the default; use Assisted Injection for runtime parameters.

When to use it

Starting a new Android app that needs structured DI and lifecycle-aware scoping.
Migrating from manual Dagger components to Hilt for simpler setup and fewer boilerplate files.
When sharing instances between ViewModels, Activities, or the whole app using clear scopes.
Writing unit tests or integration tests that require predictable injection boundaries.
Building features that need runtime parameters passed into injected classes (use Assisted Injection).

Best practices

Annotate Application with @HiltAndroidApp and Activities/Fragments with @AndroidEntryPoint.
Prefer @Binds in abstract modules for interface-to-implementation bindings to reduce generated code.
Always specify InstallIn component scope explicitly (SingletonComponent, ViewModelComponent, etc.).
Favor constructor injection for classes; reserve field injection only for Android framework types.
Use @AssistedInject for objects that require runtime parameters instead of workarounds.

Example use cases

Provide a singleton networking client bound in a Module installed in SingletonComponent.
Bind an interface to a test implementation when running unit tests by swapping modules.
Inject ViewModel dependencies scoped to ViewModelComponent to ensure correct lifecycle.
Replace manual Dagger component creation with Hilt annotations for simpler app bootstrap.
Use Assisted Injection for a factory that constructs objects with runtime IDs or config.

FAQ

Can I still use @Provides methods?

Yes — use @Provides when you need custom construction logic or cannot use @Binds, but prefer @Binds when binding interfaces to implementations.

When is field injection acceptable?

Only in Android framework classes (Activities, Fragments, Services) where constructor injection is not possible; keep business logic classes constructor-injected.