kanmanemone/swemo

Purpose and module shape

Swemo is a modular Android memo application. The repository separates app composition, memo feature UI, domain models, repository/data access, local database persistence, shared Compose UI utilities, and design-system assets. Gradle multi-module wiring begins at settings.gradle.kts and root build configuration is in build.gradle.kts.

Application entry and composition

Android launches through app/src/main/AndroidManifest.xml, with app/src/main/java/com/example/swemo/MainActivity.kt as the activity entry point. app/src/main/java/com/example/swemo/SwemoApplication.kt initializes application-level dependencies, while app/src/main/java/com/example/swemo/ui/SwemoApp.kt is the top-level Compose application shell that hosts the memo feature.

Memo feature presentation

The primary user workflow resides in feature/memo/src/main/java/com/example/memo/MemoScreen.kt. feature/memo/src/main/java/com/example/memo/MemoViewModel.kt mediates UI actions and repository operations; feature/memo/src/main/java/com/example/memo/MemoUiState.kt represents observable screen state. The screen composes feed, editor, category selection, and destructive-action dialogs from feature/memo/src/main/java/com/example/memo/components/.

Domain boundary

The platform-independent memo vocabulary is defined in the model module: model/src/main/java/com/example/model/Memo.kt, model/src/main/java/com/example/model/MemoContent.kt, and model/src/main/java/com/example/model/Category.kt. Feature and data layers should exchange these domain objects rather than database entities, preserving persistence independence.

Repository and dependency boundary

data/src/main/java/com/example/data/MemoRepository.kt defines the feature-facing persistence contract. data/src/main/java/com/example/data/MemoRepositoryImpl.kt implements it against the database layer; data/src/main/java/com/example/data/FakeMemoRepositoryImpl.kt provides an alternate in-memory/fake implementation. Dependency injection binding for this boundary is centralized in data/src/main/java/com/example/data/di/DataModule.kt.

Local persistence

The app’s durable store is an Android Room-style database centered on database/src/main/java/com/example/database/SwemoDatabase.kt. DAO interfaces—database/src/main/java/com/example/database/dao/MemoDao.kt and database/src/main/java/com/example/database/dao/CategoryDao.kt—encapsulate database queries and mutations. Persistence schema/entity representations are isolated in database/src/main/java/com/example/database/model/MemoEntity.kt, database/src/main/java/com/example/database/model/MemoContentEntity.kt, and database/src/main/java/com/example/database/model/CategoryEntity.kt; database construction/injection is in database/src/main/java/com/example/database/di/DatabaseModule.kt.

Primary control and data flow

User events flow from Compose components into MemoScreen and MemoViewModel, which updates MemoUiState and invokes MemoRepository. The repository maps between domain models and database entities, delegates reads/writes to DAOs, and returns memo/category data to the ViewModel for rendering. The architectural boundary is therefore: Compose feature → ViewModel/state → repository contract → Room DAOs/database. No remote API or external backend is indicated by the tree.

Shared UI and runtime

The runtime is a Kotlin Android application using Jetpack Compose for UI and a local database for storage. designsystem/src/main/java/com/example/designsystem/theme/Theme.kt and designsystem/src/main/java/com/example/designsystem/icon/SwemoIcons.kt provide shared visual primitives, while ui/src/main/java/com/example/ui/MemoPreviewParameterProvider.kt supports reusable Compose previews. Android resources and launcher configuration remain in app/src/main/res/.