Pokedex: the Android MVVM sample, and the Compose twin next door

Google's Hero benchmarks documentation points at this sample

The first fact worth knowing is that this repository is referenced from outside itself. Pokedex, together with a Jetpack Compose version, is featured in the official Android documentation on Hero benchmarks.

That tells you what kind of artifact this is. It is a reference app, and it is expected to be run on a device and measured, not consumed as a library. Nothing here is published to a repository you would add to a build; the value is in reading how the pieces connect.

The stack it demonstrates is described in one line: Hilt, Material Motion, Coroutines, Flow and Jetpack with Room and ViewModel, on MVVM. The floor is a minimum SDK level of 21, and the language is Kotlin with Coroutines and Flow handling asynchronous work.

The Compose version lives somewhere else. Pokedex Compose is a separate repository, and the README points anyone who wants the Compose version at it. That is the first fork in the road for a reader: two maintained samples, one built on the View system with DataBinding, one built on Compose, and no guidance in the repository about which one to read first.

The newest APK is 1.2.0, and the newest commit is months later

There is no install command in this repository, and the distribution route is a binary: go to the Releases page and download the latest APK.

That makes release state worth checking. The releases listed are 1.2.0 from 2025-10-11, 1.1.3 from 2025-03-19 and 1.1.2 from 2023-08-03. The last push to main was on 2026-10-31. So the most recent tagged build is roughly a year older than the tip of the branch, and anyone who downloads that APK is not running the code currently on main.

The repository is not archived, and the gap is not evidence of abandonment. It is evidence of a sample whose releases are occasional while commits are not, which is a normal shape for an app whose purpose is to be read.

For building from source, the tree is a Gradle project with the usual entry points: build.gradle.kts, settings.gradle.kts, gradle.properties, a gradle/ directory, and gradlew with gradlew.bat for Unix and Windows.

The data layer has to stay pure, and that is the rule to copy

The architecture section is the part of the README with real teaching content, and it is short.

There are two layers, a UI layer and a data layer, each with its own responsibilities. Each layer follows unidirectional event and data flow: the UI layer emits user events to the data layer, and the data layer exposes data as a stream to other layers. Then the constraint that shapes everything else: the data layer is designed to work independently and must be pure, meaning it has no dependencies on the other layers.

The stack list explains how each piece serves that. Lifecycle observes Android lifecycles and handles UI state on lifecycle changes. ViewModel holds UI-related data and keeps it alive across configuration changes such as screen rotations. DataBinding binds layout components to data sources declaratively instead of programmatically. Room provides an abstraction over SQLite. Hilt handles dependency injection. The chain is spelled out as View, DataBinding, ViewModel, Model, with the Repository pattern underneath and Bindables there to notify UI layers of data changes.

The sample was written against Google's own Guide to app architecture, which is the reference to follow if you want the reasoning rather than the code. The useful thing to lift from here is the purity rule, because it is the one that decides where your own code is allowed to import from.

Eight of the dependencies are the author's own packages

Read the stack list and count who wrote what. Hilt, Room, Retrofit2, OkHttp3, Moshi, Glide, Timber, Turbine, ksp and Material-Components are the wider ecosystem. Sandwich, WhatIf, Bundler, Bindables, TransformationLayout, Rainbow, AndroidRibbon and ProgressView are all published by the same account that maintains this repository.

Their roles are described in one line each, and some are worth reading for the reason they exist. WhatIf is for checking nullable objects and empty collections more fluently. Bundler is an extension over Intent and Bundle for inserting and retrieving values. Sandwich is described as a lightweight response interface for network payloads. Bindables is a DataBinding kit for notifying data changes to UI layers. TransformationLayout handles transformation motion animations, and the three custom views cover a shimmer ribbon, a tinted gradient view and a configurable ProgressView.

That is a deliberate showcase, and a reader should treat it as one. Adopting the sample's stack means adopting eight packages from a single author, several of which solve problems your app may not have. Nothing in the repository compares any of them with an alternative, and nothing explains what happens if you swap one out, so the cost of that choice is unmeasured rather than zero.

Modules named after their job, not their layer

The source tree gives the architecture a second reading, and the module names are the interesting part.

Alongside app/ there are core-data/, core-database/, core-model/, core-network/ and core-test/, plus buildSrc/ for build logic, benchmark/, previews/ for UI previews, spotless/ for formatting, and a figure/ directory. Gradle multi-module with names split by responsibility is how a sample of this size stays readable, and it also means the layers visible in the README have physical counterparts you can open.

Two details in there show the project is maintained as working software rather than as a code drop. renovate.json sits at the root, so dependency bumps are configured rather than done by hand. .coderabbit.yaml suggests an automated review step is configured for pull requests. build.gradle.kts and .editorconfig alongside spotless mean formatting is enforced by tooling.

The network side is Retrofit2 and OkHttp3 for the REST APIs and paging network data, with Moshi for JSON, and the testing side is a core-test/ module with Turbine for Flow. ksp, the Kotlin Symbol Processing API, is in the list. Nothing here is exotic, and nothing is explained beyond the one-line descriptions, so the sample teaches structure rather than configuration.

Most of the README is about the author's other products

A reader arriving to evaluate this sample has to get past three promotional sections first.

The Manifest Android Interview is described as a guide of 108 interview questions with detailed answers, 162 additional practical questions, and 50 or more Pro Tips for Mastery sections, covering the framework, UI, Jetpack libraries, business logic and Compose. Next comes Practical Kotlin Deep Dive, a book that goes from how to use Kotlin into how it works, including internal implementations, bytecodes and compiler behavior, plus a companion course on Leanpub with 158 interactive assessments. Then Dove Letter, a private subscription repository for learning and discussion, with a Medium article explaining how to get in.

None of that tells you anything about the code. It is separate products with their own scope, and their existence next to the sample is not evidence that the sample is good, only that the author has other things to sell.

The practical effect is navigation. The architecture section is the substance of this repository, and it sits below three sections of links and marketing. If you are here to learn the layering, jump to the Architecture heading and the stack list. If you are here to decide whether the interview guide or the Kotlin book is worth your time, this repository was never the place to answer that.

Room and Retrofit answer questions the sample does not ask

Two absences are worth naming, because a sample app is often mistaken for a template.

There is no authentication, no login, no account state and no error-reporting story anywhere in what the repository describes. The data layer is a cache in front of a REST API, and everything else a production app needs on top of that, sessions, retries, migration paths when the Room schema changes, telemetry, is not part of this demonstration.

Minimum SDK 21, Kotlin, Hilt and Room are specified in the stack list.

Set against those gaps, the parts that are documented are precise: the two-layer split, unidirectional flow, the purity rule for the data layer, and the fact that Room, Retrofit and Hilt each have one job. That is enough to learn from, and not enough to copy wholesale.

Editorial conclusion

Read Pokedex if you want one coherent example of Google's app architecture guidance with a data layer that is kept pure, and read the Pokedex Compose repository instead if your team has moved to Compose, since the two are maintained apart. Do not adopt the dependency list wholesale: eight of the entries are the author's own packages. Before you base anything on the build, check that the APK on the Releases page predates the current main branch, because the newest tag is 1.2.0 from 2025-10-11 while the last push was on 2026-10-31.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. skydoves/Pokedex on GitHub