Technical Specification: Enterprise-Grade Dagger DI, SSOT Data Layer, & Firebase Integration

This document outlines the implementation strategy for transitioning Rho Studio UI to a production-hardened state. The focus is on Transactional Integrity, Strict Session Isolation, and Scalable Infrastructure tailored for high-stakes fintech environments.

---

1. Dagger Dependency Injection: Component Dependency & Scoped Orchestration

We will implement a Pure Dagger architecture using Component Dependencies to maintain strict module encapsulation and explicit lifecycle control.

1.1 Multi-Module Component Topology

To preserve the "Clean Architecture" boundaries, we avoid Subcomponents and instead use Component Dependencies.

• CoreComponent (in :core:data):
  • Scope: @Singleton.
  • Exposure: Explicitly exposes AuthRepository, SessionManager, and Json infrastructure.
  • Responsibility: Houses stateless or global-state services.
• UserComponent (in :app or :core:data):
  • Scope: @UserScope.
  • Dependency: CoreComponent.
  • Lifetime: Created upon successful login; invalidated immediately upon logout.
  • Responsibility: Hosts session-sensitive interactors and transient state for flows like Loan Wizards.
• FeatureComponents (in :features:*):
  • Dependency: CoreComponent (and UserComponent for authenticated features).
  • Responsibility: Provides feature-specific ViewModels via multibinding.

1.2 Scoped Component Management

We will implement a ComponentManager at the :app level to orchestrate the lifecycle of the UserComponent. This ensures that when a user logs out, the entire session-scoped graph is garbage collected, fulfilling fintech requirements for Secure Session Isolation.

1.3 ViewModel Multibinding & Factory

• Implement a DaggerViewModelFactory in :core:ui that leverages a Map<Class<? extends ViewModel>, Provider<ViewModel>>.
• Use @IntoMap and @ViewModelKey in feature modules to decouple the UI from the instantiation of business logic.

---

2. Data Layer: SSOT & Secure Transactional Integrity

Refining the Data Layer to ensure a Single Source of Truth (SSOT) and secure persistence.

2.1 SessionManager & Repository Refactoring (Architectural Split)

• Repository Abstraction: Refactor SessionRepository to follow Clean Architecture by splitting it into its respective modules:
  • :core:domain: Houses the SessionRepository interface.
  • :core:data: Houses the SessionRepositoryImpl implementation.
• DI Integration: Remove Singleton boilerplate from SessionManager. It becomes a standard injectable class managed by Dagger.
• Reactive State Flow: Transition to a sealed-class-based state (SessionState.Uninitialized, Authenticated(User), etc.) to prevent invalid state transitions.
• Transactional Integrity: Ensure that updateSession() and clearSession() are atomic operations, coordinating the StateFlow update with the DataStore write.

2.2 Secure Persistence with Encrypted DataStore

• Replace SharedPreferences with Jetpack DataStore (Proto or Preferences).
• Implement Tink-based encryption (via EncryptedSharedPreferences or a custom SecurityDataStore) to protect session tokens and PII (Personally Identifiable Information) on disk.

---

3. Firebase Authentication: Robust Integration & SDK Decoupling

Integrating Firebase while maintaining a generic, testable domain.

3.1 Remote Data Source Abstraction

• FirebaseRemoteDataSource: A wrapper around the Firebase SDK. This class will be the only point of contact with Firebase, allowing us to swap it with a Fake for unit tests without hitting the real SDK.
• Error Mapping: Implement a FirebaseErrorMapper to transform SDK exceptions into domain-level AppFailure types (e.g., InvalidCredentials, AccountLocked).

3.2 AuthRepository Implementation

• Coordinates between FirebaseRemoteDataSource and SessionManager.
• Implements an "Offline-First" awareness: ensuring the local session is updated only after successful remote verification.

---

4. Performance & Scalability Strategy

As the volume of UseCases and business logic grows, we mitigate overhead:

• dagger.Lazy<T> & dagger.Provider<T>: Extensively used in ViewModels to defer UseCase instantiation until the exact moment of execution.
• Compile-Time Graph Validation: Dagger's static analysis ensures that all dependency requirements are satisfied at build time, eliminating runtime DI crashes.
• Leak Detection: Use of LeakCanary during verification to ensure UserComponent and its dependencies are properly reclaimed post-logout.

---

5. Incremental Development Roadmap

To ensure stability and maintain transactional integrity, the implementation will be executed in the following incremental phases:

Phase 1: Environment & Core DI Infrastructure

1. Dependency Injection & Firebase Setup: Update libs.versions.toml with Dagger 2, Firebase BOM, and DataStore dependencies. Apply plugins and dependencies to all module build.gradle.kts files.
2. Annotation Definition: Create @UserScope and @ViewModelKey in :core:domain or :core:ui.
3. Core Data Module: Create CoreModule and CoreComponent in :core:data to provide Json and basic infrastructure.
4. ViewModel Factory: Implement DaggerViewModelFactory in :core:ui.

Phase 2: Data Layer Refactoring (SSOT)

1. Architectural Repository Split: Relocate the SessionRepository interface to :core:domain and keep SessionRepositoryImpl in :core:data.
2. Injectable SessionManager: Refactor SessionManager.kt to remove the singleton pattern and support constructor injection.
3. Secure Persistence: Implement EncryptedDataStore logic in :core:data to replace SharedPreferences.
4. Repository Implementation: Update SessionRepositoryImpl and AuthRepositoryImpl to use constructor injection and the new DataStore.

Phase 3: Feature & App Layer Integration

1. Feature Multibinding: Annotate LoginViewModel and HomeViewModel with @Inject and register them in their respective Dagger modules using @IntoMap.
2. UserComponent Orchestration: Implement the ComponentManager in :app to manage the lifecycle of the @UserScope graph.
3. Application & Activity Wiring: Initialize the Dagger graph in RhoApplication.kt and trigger injection in MainActivity.kt.

Phase 4: Firebase Integration & Final Polish

1. Remote Data Source: Implement FirebaseRemoteDataSource wrapper.
2. Production Repository: Switch AuthRepositoryImpl from mock logic to real Firebase authentication.
3. Final Audit: Execute memory profiling and encryption verification.

---

6. Verification & Audit Plan

6.1 Automated Testing

• DI Graph Audit: Build-time verification of the complete Dagger graph.
• Transactional Logic: Unit tests for SessionManager to verify atomic state transitions during edge cases (e.g., failed logout).
• Domain Logic: 90%+ coverage for UseCases using Dagger-provided mocks.

6.2 Manual Verification & Compliance

• Session Purge Audit: Verify memory reclamation of @UserScope objects using Memory Profiler.
• Encryption Audit: Inspect DataStore files on a rooted device (or via App Inspection) to confirm PII encryption.
• Fintech UX Verification: Verify the "Secure Logout" flow ensures no PII is visible in the UI after a session termination.

---

Rho.Studio® - Engineering Department - Contact alexis.tercero@rho.studio