Dependency Injection (Hilt)

Relevant source files

The following files were used as context for generating this wiki page:

• app/src/main/java/com/musagenius/ocrapp/di/AppModule.kt
• app/src/main/java/com/musagenius/ocrapp/di/CameraModule.kt
• app/src/main/java/com/musagenius/ocrapp/di/OCRModule.kt
• app/src/main/java/com/musagenius/ocrapp/OCRApplication.kt
• app/src/main/java/com/musagenius/ocrapp/MainActivity.kt
• app/src/main/java/com/musagenius/ocrapp/domain/usecase/DeleteLanguageUseCase.kt
• ROADMAP.md
• TODO.md

The application uses Hilt, a dependency injection library for Android, to manage dependencies and follow Clean Architecture principles. Hilt reduces the boilerplate of manual dependency injection by providing containers for every Android class in the project and managing their lifecycles automatically. The setup is designed to be modular, testable, and scalable.

The core of the Hilt implementation is centered around modules that provide instances of classes like services, repositories, and utilities. These dependencies are then injected into Android components such as Activities, ViewModels, and Application classes. The project roadmap indicates a comprehensive DI strategy, with plans for DatabaseModule, RepositoryModule, and ViewModel injection.

Sources: README.md, ROADMAP.md, TODO.md

Core Hilt Setup

Hilt is initialized in the OCRApplication class and used to inject dependencies into the MainActivity.

Application Entry Point

The OCRApplication class is annotated with @HiltAndroidApp, which triggers Hilt's code generation and creates a dependency container attached to the application's lifecycle.

Sources: app/src/main/java/com/musagenius/ocrapp/OCRApplication.kt:8-9

// app/src/main/java/com/musagenius/ocrapp/OCRApplication.kt:8
@HiltAndroidApp
class OCRApplication : Application() {
    // ...
}

Activity Entry Point

The MainActivity is annotated with @AndroidEntryPoint, making it a container for dependencies. This allows Hilt to inject objects into the activity, such as ViewModels or other required classes.

Sources: app/src/main/java/com/musagenius/ocrapp/MainActivity.kt:20-21

// app/src/main/java/com/musagenius/ocrapp/MainActivity.kt:20
@AndroidEntryPoint
class MainActivity : ComponentActivity() {
    // ...
}

The following diagram illustrates the basic Hilt entry point setup.

Hilt Modules

Dependencies are provided through Hilt modules, which are classes annotated with @Module. Each module is installed in a specific Hilt component, defining the scope and lifecycle of the provided dependencies.

Module	Component	Scope	Provided Dependencies	Source File
AppModule	SingletonComponent	@Singleton	Context, CoroutineDispatchers	AppModule.kt
OCRModule	SingletonComponent	@Singleton	ImagePreprocessor, OCRService	OCRModule.kt
CameraManagerModule	ActivityRetainedComponent	@ActivityRetainedScoped	CameraManager	CameraModule.kt
UtilityModule	SingletonComponent	@Singleton	ImageCompressor, StorageManager	CameraModule.kt

Sources: app/src/main/java/com/musagenius/ocrapp/di/AppModule.kt, app/src/main/java/com/musagenius/ocrapp/di/OCRModule.kt, app/src/main/java/com/musagenius/ocrapp/di/CameraModule.kt

AppModule

AppModule provides application-wide dependencies that are available throughout the app's lifecycle. It is installed in the SingletonComponent.

Sources: app/src/main/java/com/musagenius/ocrapp/di/AppModule.kt:15-16

Provided Dependencies

• Context: Provides the application context, annotated with @ApplicationContext.
• CoroutineDispatchers: Provides standard dispatchers (IO, Main, Default) for managing coroutines. These are distinguished using custom qualifiers (@IoDispatcher, @MainDispatcher, @DefaultDispatcher) to allow for specific injection where needed.

Sources: app/src/main/java/com/musagenius/ocrapp/di/AppModule.kt:18-36

The diagram below shows the dependencies provided by AppModule.

OCRModule

OCRModule is responsible for providing all dependencies related to the OCR functionality. It is also installed in the SingletonComponent, making its dependencies available as singletons.

Sources: app/src/main/java/com/musagenius/ocrapp/di/OCRModule.kt:15-16

Provided Dependencies

• ImagePreprocessor: A singleton utility class for preparing images before they are sent to the OCR engine.
• OCRService: The main service for performing OCR. The module provides the OCRServiceImpl implementation, which itself depends on Context and ImagePreprocessor. Hilt automatically provides these dependencies to create the OCRService instance.

This diagram shows the dependency graph within OCRModule.

Camera & Utility Modules

The CameraModule.kt file contains two separate modules with different scopes.

CameraManagerModule

This module provides the CameraManager. It is installed in the ActivityRetainedComponent and scoped with @ActivityRetainedScoped. This ensures that the CameraManager instance survives configuration changes (like screen rotation) but is destroyed when the activity is finished, preventing resource leaks.

Sources: app/src/main/java/com/musagenius/ocrapp/di/CameraModule.kt:15-24

UtilityModule

This module provides stateless utility classes like ImageCompressor and StorageManager. Since these can be safely shared across the entire application, the module is installed in the SingletonComponent and the providers are scoped with @Singleton.

Sources: app/src/main/java/com/musagenius/ocrapp/di/CameraModule.kt:31-47

Dependency Injection in Use Cases

Dependencies provided by Hilt modules are injected directly into other classes, such as use cases, using constructor injection. For example, DeleteLanguageUseCase requests the application Context in its constructor.

// app/src/main/java/com/musagenius/ocrapp/domain/usecase/DeleteLanguageUseCase.kt:13
class DeleteLanguageUseCase @Inject constructor(
    @ApplicationContext private val context: Context
) {
    // ...
}

Hilt's AppModule fulfills this dependency request by providing the context it configured.

Sources: app/src/main/java/com/musagenius/ocrapp/domain/usecase/DeleteLanguageUseCase.kt:13-15, app/src/main/java/com/musagenius/ocrapp/di/AppModule.kt:20-23

Planned Modules

The project's ROADMAP.md and TODO.md outline plans for additional Hilt modules to complete the architecture. These include:

• DatabaseModule: To provide the Room Database instance and Data Access Objects (DAOs).
• RepositoryModule: To bind repository interfaces (from the domain layer) to their implementations (in the data layer).
• ViewModel Injection: To inject use cases and other dependencies into ViewModel classes using the @HiltViewModel annotation.

Sources: TODO.md:112-136, ROADMAP.md:88-106

Summary

The dependency injection setup using Hilt is a cornerstone of the application's architecture. It establishes a clear separation of concerns, improves testability, and manages dependency lifecycles effectively. By organizing dependencies into logical modules with appropriate scopes (@Singleton, @ActivityRetainedScoped), the application ensures that resources are used efficiently and are easily replaceable or mockable for testing. The current implementation provides a solid foundation for application-wide services, OCR functionality, and camera management, with a clear path forward for incorporating data persistence and business logic layers.