yury03/appcocktailbar

Purpose and runtime

Cocktail Bar is a native Android app for creating, viewing, editing, and deleting locally saved cocktail recipes. Recipes include descriptive fields, ingredients, preparation instructions, and apparently an image. It is a single Gradle Android application module: app/build.gradle.kts, launched through app/src/main/AndroidManifest.xml.

Application entry and navigation

MainActivity is the Android UI entry point and hosts the app’s primary screen/navigation container: app/src/main/java/com/example/appcocktailbar/ui/main_activity/MainActivity.kt, app/src/main/res/layout/activity_main.xml. Fragment destinations and transitions are centrally declared in app/src/main/res/navigation/nav_graph.xml, separating the list, add, and detail/edit flows.

UI presentation layer

The UI uses Android Fragments backed by screen-specific ViewModels:

• Cocktail collection: ui/cocktails/CocktailsFragment.kt, ui/cocktails/CocktailsViewModel.kt

• Creation: ui/add_cocktail/AddCocktailFragment.kt, ui/add_cocktail/AddCocktailViewModel.kt

• Details and modification: ui/cocktail_details/CocktailDetailsFragment.kt, ui/cocktail_details/CocktailDetailsViewModel.kt

List-oriented displays are delegated to RecyclerView-style adapters for cocktails and ingredients: ui/cocktails/adapters/CocktailsListAdapter.kt, ui/cocktail_details/adapters/IngredientListAdapter.kt. Fragment layouts define each screen’s Android View-based rendering boundary.

Domain contracts and use cases

The domain layer isolates recipe behavior from Android UI and Room persistence. domain/models/CocktailModel.kt is the application-level cocktail representation, while domain/Repository.kt defines the repository boundary. Explicit use cases express the main commands and query: domain/usecases/GetAllCocktails.kt, domain/usecases/AddCocktail.kt, domain/usecases/EditCocktail.kt, and domain/usecases/DeleteCocktail.kt.

Primary control flow is: user interaction in Fragment → ViewModel → use case → repository contract → data implementation → Room. Results return in reverse to refresh displayed state.

Persistence and data boundary

Cocktails are stored on-device through Room, not a remote backend. data/room/CocktailDatabase.kt owns database construction; data/room/dao/CocktailsDatabaseDao.kt defines database operations; and data/room/entity/CocktailEntity.kt is the storage schema. data/room/mappers/CocktailMapper.kt converts between persistence entities and domain models, preventing Room types from becoming the domain API.

Repository-facing implementations are operation/screen-oriented: data/AddCocktailsContractImpl.kt, data/CocktailsFragmentContractImpl.kt, and data/DetailsFragmentContractImpl.kt. These form the concrete bridge from domain/UI contracts to local storage.

Dependency composition

Dependency injection is organized by architectural layer: di/dataModule.kt supplies persistence/data bindings, di/domainModule.kt supplies use cases, and di/uiModule.kt supplies UI-facing dependencies. The app-level bootstrap is app/App.kt, likely the Application class responsible for initializing this dependency graph.

External boundaries

Material dependencies are Android platform APIs, AndroidX navigation/fragments/view models, Room local database infrastructure, and the Gradle Android build runtime. No source path indicates a network API, cloud service, authentication system, or implemented recipe-sharing integration; README-mentioned sharing is not represented as a visible architectural subsystem. Figma is a design reference, not an application runtime dependency.