-
data - This is the main package that contains:
- Repositories: Classes that serve as single sources of truth, coordinating data from various sources (network, local database, etc.).
- Models: Data models that are often the primary types used across the app, sometimes referred to as "domain models."
- API (Network): Classes for network interactions and managing remote data, often separated
into their own subdirectories within
data. - Service Managers: Managers for third-party services or integrations, such as Firebase or Health Connect.
-
database - A separate package exclusively for local data storage:
- Entities: Database entity classes annotated for Room or other local storage frameworks.
- DAOs: Data Access Objects that define methods for querying and modifying the database.
- Converters: Type converters for Room, if needed.
core/
├── data/ # Core data module for shared data logic
│ ├── src/
│ │ └── main/
│ │ ├── java/com/ylabz/basepro/core/data
│ │ │ ├── api/ # Network-related classes and APIs
│ │ │ │ ├── HealthApi.kt # Example API for Health data
│ │ │ │ ├── MapsApi.kt # Example API for Maps
│ │ │ │ └── YelpApi.kt # Example API for Yelp
│ │ │ ├── model/ # Shared data models across the app
│ │ │ │ ├── BusinessInfo.kt # Example model for Yelp business info
│ │ │ │ └── HealthData.kt # Example model for health-related data
│ │ │ ├── repository/ # Repositories coordinating data sources
│ │ │ │ ├── YelpRepository.kt # Example Yelp repository
│ │ │ │ └── HealthRepository.kt # Example Health repository
│ │ │ └── service/ # Service Managers for third-party integrations
│ │ │ └── HealthConnectManager.kt # Google Health Connect manager
│ │ └── AndroidManifest.xml
│ └── build.gradle.kts # Build configuration for core-data
│
└── database/ # Core module for local database logic
├── src/
│ └── main/
│ ├── java/com/ylabz/basepro/core/database
│ │ ├── entity/ # Entities for RoomDB
│ │ │ └── BikeProEntity.kt # Example entity for Room database
│ │ ├── dao/ # DAOs for database interactions
│ │ │ └── BikeProDao.kt # Example DAO
│ │ ├── converter/ # Converters for Room types
│ │ │ └── DateConverter.kt # Example date converter for Room
│ │ └── BikeProDB.kt # Database setup and configuration
│ └── AndroidManifest.xml
└── build.gradle.kts # Build configuration for core-database
-
core/data:
- api/: Contains classes for network APIs and external data sources.
- model/: Holds data models that are shared across the app, including those returned from APIs or used in repositories.
- repository/: Repositories that orchestrate data flow, such as fetching data from both local and remote sources, handling caching, etc.
- service/: Contains service managers, such as
HealthConnectManager, which manage interactions with external systems (like Google Health).
-
core/database:
- entity/: Holds the entity definitions for the Room database, defining the schema.
- dao/: Contains DAO interfaces with methods to access and modify the database.
- converter/: If needed, this is where you would put converters for custom types that Room
cannot directly store (e.g.,
DateConverter). BikeProDB.kt: Sets up the Room database, connecting entities and DAOs.
- Separation of Concerns: By splitting
dataanddatabase, you’re clearly distinguishing between remote and local data management. - Modularity: Each component has a dedicated place, making it easy to extend functionality. Adding a new API or repository doesn’t clutter the database folder, and vice versa.
- Scalability: This structure supports adding more complex data management without making the project confusing or overly coupled.
- DI modules and repositories often manage dependencies and data that are needed by multiple features.
- By placing these components outside of individual feature modules, they can be reused across the entire app, avoiding code duplication.
- For example, if you have a repository that fetches user data, multiple features (such as Profile, Settings, and Home) might need access to that data. Placing the repository in a shared layer makes it accessible to any feature without duplicating code.
- The data layer (repositories, data sources, and DI) is separate from the UI layer ( features).
- This separation follows the Clean Architecture principle, where the data layer is isolated from the UI layer and can work independently of any specific feature.
- By keeping repositories and DI modules outside the feature modules, the codebase aligns with the Single Responsibility Principle, making each module more maintainable and focused on a single purpose.
- Having a standalone data layer that isn’t tightly coupled to the UI allows easier unit testing and integration testing.
- Tests can focus on the functionality of repositories and data without needing to depend on specific UI components, which leads to better test coverage and more reliable code.
- With DI and repositories located outside the feature modules, it’s easier to scale the app as new features are added.
- The shared data layer allows for modularization of features without needing to reimplement or reconfigure the core dependencies each time.
- This structure aligns with Modern Android Development (MAD) practices, which emphasize modularization, scalability, and separation of concerns.
- The DI module setup is centralized, simplifying the dependency graph. Dependencies don’t need to be redefined in each feature module, and managing dependencies (such as database instances, network clients, or configuration settings) is centralized in the core DI setup.
- This makes it easier to see the dependencies at a high level and manage updates or changes without affecting feature-specific code.
- In a typical layered architecture (as seen in Now in Android):
- Data Layer: Contains repositories, data sources, and DI, handling data management independently of any UI or feature.
- Domain Layer: Contains use cases (if implemented) that handle business logic, and they can use repositories from the data layer.
- UI Layer (Features): Contains feature-specific UI and ViewModels, focusing solely on displaying data and interacting with users, with dependencies injected from the data and domain layers.
- This consistency ensures that each layer only deals with its specific concerns, improving maintainability and readability.
core/
├── data/ # Data layer
│ ├── di/ # Dependency Injection (e.g., Hilt modules)
│ ├── repository/ # Repositories for shared data
│ └── service/ # Services for network, database, etc.
├── domain/ # Optional domain layer for business logic
│ ├── usecase/ # Use cases, if needed
features/
├── profile/ # Feature module
│ ├── ui/ # UI components
│ ├── viewmodel/ # ViewModels for UI
│ └── navigation/ # Feature navigation, if required
├── settings/ # Another feature module
│ ├── ui/
│ ├── viewmodel/
│ └── navigation/