skydoves/Pokedex: An Android MVVM Reference App Built on Hilt, Room and Flow

What skydoves/Pokedex actually is, and who it is for

This is a sample application, not a library. The README describes it as a demonstration of modern Android development, and the repository layout confirms that framing: app/, core-data/, core-database/, core-model/, core-network/, core-test/, buildSrc/, benchmark/ and spotless/ sit at the top level. There is no published artifact to depend on, so the value is in reading and running the code.

The audience is narrow and specific. Android developers who already know Kotlin and want to see how Hilt dependency injection, Coroutines and Flow, Room, ViewModel and DataBinding are assembled in a single MVVM codebase will get the most from it. People looking for a Pokedex app to install on a phone are a secondary audience: the README points to the Releases page for the latest APK, so the app can be installed, but that is a side effect of the sample rather than the point of it.

The README also notes the project is featured in the official Android documentation on Hero benchmarks, alongside its Compose counterpart, Pokedex Compose. That context matters when you decide how much weight to give the code: it is a teaching artifact that Google's own documentation points at, which is a stronger signal than a random sample repository.

The module split and the data flow through core-network, core-database and core-data

The top-level entries tell most of the architecture story. core-model/ holds the data types. core-network/ wraps Retrofit2 and OkHttp3 for REST calls, with Moshi for JSON parsing and Sandwich for turning network payloads into a response interface the UI layer can consume. core-database/ wraps Room, which the README describes as an abstraction layer over SQLite. core-data/ sits between them and exposes repositories. app/ holds the ViewModels and the DataBinding layouts.

That is the classic repository pattern the README names. A ViewModel observes a Flow from a repository in core-data; the repository decides whether to read from Room or from the network layer; the result flows back to the view through DataBinding. The README lists Bindables as the DataBinding kit for notifying data changes to the UI layer, which is how the observable properties reach the layouts.

Two details are worth noticing because they are easy to miss. First, the README lists ksp, the Kotlin Symbol Processing API, in the tech stack. That means annotation processing for Hilt and Room runs through KSP rather than KAPT, which affects build times and is a deliberate modern choice. Second, core-test/ is a separate module, and Turbine is listed for testing kotlinx.coroutines Flow. The project treats testing infrastructure as a first-class module rather than scattering test helpers across the app.

The README does not document the retry policy, cache eviction rules or error mapping in detail. Those live in the source, and anyone evaluating the architecture should read core-data/ and core-network/ directly rather than trusting the tech stack list to describe behaviour.

Getting the app: the Releases APK and the Gradle wrapper

The README's only documented distribution path is the Releases page, where it says to go to download the latest APK. The most recent release listed is 1.2.0, published on 2025-10-11. That is the shortest route to seeing the app run, and it requires no local Android toolchain beyond an installer.

For a local build, the repository ships the Gradle wrapper at the top level, alongside gradlew.bat for Windows. The README itself does not spell out a build command, so the wrapper is the mechanism rather than a documented instruction. The wrapper resolves the Gradle version pinned under gradle/, which means no system Gradle install is needed.

./gradlew build

That is the standard wrapper invocation the repository's layout supports. The first run downloads dependencies and runs KSP for Hilt and Room, so it takes noticeably longer than later builds.

Minimum SDK is 21 according to the README badge and the tech stack section, which is worth checking against your emulator image before blaming the build for a runtime failure. The README does not document a signing configuration for release builds, so the release APK from Releases is the practical path for a device install.

Where skydoves/Pokedex stops being the right tool

The clearest limitation is that this is not consumable as a dependency. Nothing in the README describes publishing to Maven Central or any other repository, and the module names (app, core-data, core-database) are application modules, not library artifacts. If you want the pieces, you copy them, and copying means inheriting the project's choices about Gradle configuration, KSP setup and dependency versions.

The second limitation is version coupling. The README lists a long stack: Hilt, Room, Retrofit2, OkHttp3, Moshi, Glide, Material Components, Timber, and several skydoves-authored libraries including Sandwich, Bindables, WhatIf, Bundler, TransformationLayout, Rainbow, AndroidRibbon and ProgressView. Those are not incidental. A meaningful share of the UI and networking glue comes from the same author's ecosystem, so adopting the pattern means adopting that set of dependencies or rewriting the parts that use them.

Third, the README describes the app as based on MVVM with DataBinding, and DataBinding is a legacy-leaning choice compared with Compose or ViewBinding. The README itself points readers to Pokedex Compose for the Jetpack Compose version. If your target is a new Compose codebase, this repository teaches you a stack you may not be shipping.

Finally, the README does not document rollback, migration strategy or how the Room schema evolves across releases. If you are looking for guidance on database migrations in production, this is not the source.

Pokedex Compose and the difference in approach

The README explicitly names Pokedex Compose as the Jetpack Compose version of the same sample, and the note at the top of the README says both projects are featured in the official Android documentation on Hero benchmarks. That is the real alternative, and the difference is not cosmetic.

In skydoves/Pokedex the UI layer is XML layouts bound to observable data through DataBinding, with Bindables providing the notification mechanism. In Pokedex Compose the UI is declarative Compose, which removes the layout-binding layer entirely and changes how state flows to the screen. The ViewModel and repository layers may look similar, but everything above them is a different programming model.

The practical consequence: if you are deciding between the two, pick based on the UI stack you actually ship. Reading this repository to learn Compose will not work, because the DataBinding layer is where much of the sample's structure lives. Reading it to understand Hilt module organisation or the repository pattern still transfers, since those layers are not UI-framework specific.

Maintenance, releases and the Apache-2.0 licence

The repository is not archived, and the last push was on 2026-09-19, so the project is being touched. Releases are less regular: 1.2.0 on 2025-10-11, 1.1.3 on 2025-03-19, and 1.1.2 back on 2023-08-03. The gap between 1.1.2 and 1.1.3 is roughly nineteen months, which suggests releases track meaningful changes rather than a fixed cadence.

For upgrade cost, the honest answer is that the repository is a fork-and-read artifact. There is no upgrade path to maintain because you do not depend on it; you either track the upstream repository or you copy code and own it from that point. The presence of renovate.json at the top level indicates dependency updates are automated upstream, but that says nothing about whether the code you copied will still compile against your own Gradle and Kotlin versions.

The licence is Apache-2.0, stated in the README badge and present as LICENSE at the repository root. Apache-2.0 permits commercial use and modification and includes a patent grant, but it also carries attribution and notice requirements, and the file-level details matter. This is not legal advice; read the LICENSE file and your organisation's policy before shipping derived code.

Editorial conclusion

Adopt skydoves/Pokedex as a reading reference if you are learning how Hilt, Room, Flow and DataBinding are wired together in a modular Android project, or if you want a working APK to inspect. Do not treat it as a dependency: there is no published artifact, and the modules are app code, not a library. Before copying anything, check the README's tech stack list against your own minSdk, since the project targets API 21+, and confirm the Gradle and Kotlin versions in the build files match your toolchain.

Frequently asked questions

Official sources

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