awanish-yadav-iph/movielist

Purpose and entry point

This is a native Android movie-list application written in Kotlin. It presents movie data in a Compose UI, obtains it from a remote movie API, and includes local database persistence. Android launches app/src/main/java/com/example/movielist/MainActivity.kt, with app registration and platform settings in app/src/main/AndroidManifest.xml.

Application composition

MainActivity is the top-level Android/Compose host and connects the screen layer to application state. The UI is organized as composable screens and reusable movie cards:

• app/src/main/java/com/example/movielist/MainActivity.kt

• app/src/main/java/com/example/movielist/ui/MovieScreen.kt

• app/src/main/java/com/example/movielist/ui/MovieCard.kt

The theme package provides the Compose visual system but is not part of core data flow.

Presentation state and control flow

MovieViewModel is the presentation boundary between Compose and data sources. It should own screen-facing movie/loading/error state and initiate fetching or persistence operations rather than allowing UI composables to call network/database layers directly:

• app/src/main/java/com/example/movielist/viewmodel/MovieViewModel.kt

• app/src/main/java/com/example/movielist/ui/MovieScreen.kt

Primary control flow is: Android activity → Compose screen → view model → network and/or local persistence → view-model state → Compose recomposition.

Remote movie integration

The networking layer encapsulates the external movie service. MovieApi defines endpoint contracts, while RetrofitClient constructs/configures the Retrofit client used to execute them:

• app/src/main/java/com/example/movielist/network/MovieApi.kt

• app/src/main/java/com/example/movielist/network/RetrofitClient.kt

• app/src/main/java/com/example/movielist/model/MovieResponse.kt

The network boundary returns response-shaped models, insulating UI code from HTTP and serialization concerns.

Domain and transformation boundary

Movie data has distinct representations for API/domain/local-storage needs. Movie is the app-facing model, MovieResponse represents API payload structure, and MovieMapper converts between representations:

• app/src/main/java/com/example/movielist/model/Movie.kt

• app/src/main/java/com/example/movielist/model/MovieResponse.kt

• app/src/main/java/com/example/movielist/mapper/MovieMapper.kt

This mapping boundary is the appropriate place to handle field normalization and prevent database or wire formats from leaking into UI state.

Local persistence

Room-style persistence is isolated in a database package. MovieEntity defines the stored schema, MovieDao provides query/write access, and MovieDatabase owns database construction:

• app/src/main/java/com/example/movielist/database/MovieEntity.kt

• app/src/main/java/com/example/movielist/database/MovieDao.kt

• app/src/main/java/com/example/movielist/database/MovieDatabase.kt

A likely data lifecycle is remote response → mapper → entity/DAO cache, with persisted entities mapped back to domain movies for display.

Runtime and build infrastructure

The repository is a single Gradle Android application module (app). Runtime dependencies and Android build configuration are centered in:

• app/build.gradle.kts

• build.gradle.kts

• gradle/libs.versions.toml

Material technologies implied by structure are Kotlin, Android, Jetpack Compose, Retrofit for the external movie API, and Room for on-device storage.