Archi: Three Android architectures for the same GitHub app, side by side

A sample app that exists to be compared, not shipped

ivacf/archi solves a specific teaching problem: how do different Android architecture patterns change the same feature set? The repository contains three separate Android projects, each implementing an identical app that shows a list of GitHub public repositories for a given username and a details screen for a selected repository, including owner information. The target audience is Android developers who have outgrown single-Activity tutorials and want to see how responsibilities shift when you move from the platform default to MVP and then to MVVM. The author states plainly that the standard Android approach has a problem: Activities and Fragments become large and hard to test, which is why that variant has no unit tests. That admission is the core of the repository's value. It is a deliberate comparison, not a production codebase.

The shared model and the three implementations

All three projects share the same model layer. The README lists three classes: Repository, User, and a Retrofit service called GithubService. That service is the single point of network access. The standard Android implementation, in the /app directory, puts the logic inside Activities: they call the service, process the response, and update the views. The README describes this as Activities acting like a controller in MVC, but with extra view responsibilities. The MVP version, in /app-mvp, moves that work into presenters. Each Activity has a matching presenter that talks to GithubService and notifies the Activity when data is ready. The MVVM version, in /app-mvvm, uses ViewModels that retrieve data when the view requests it through data binding. This is a classic separation: the standard version mixes concerns, MVP separates presentation logic from the Android framework, and MVVM separates it further by removing the need for explicit view callbacks.

How the patterns change the testing story

The most concrete difference between the three variants is testability. The standard Android implementation has no unit tests, and the author says why: Activities and Fragments are difficult to test in isolation. The MVP implementation is designed for testing by mocking the view layer, which means the presenter can be tested without an emulator or device. The MVVM implementation claims even easier unit testing because ViewModels are decoupled from the view. The repository includes Mockito and Robolectric in the library list, which are the tools you would use for that kind of testing. This is not a benchmark or a measured claim; it is the author's stated rationale. But the structure supports it: presenters and ViewModels are plain Java classes that depend on an interface or an observable data source, not on Activity lifecycle methods. If you are evaluating which pattern to use in a real project, this repository gives you a direct look at how much testable code each approach yields.

Getting it running: build commands and dependencies

The README does not include explicit build instructions, but the repository structure implies standard Gradle usage. Each variant lives in its own directory: /app, /app-mvp, and /app-mvvm. You would open one of those directories as a project in Android Studio and run a Gradle build, typically with ./gradlew assembleDebug from the command line. The dependencies are listed: AppCompat, CardView, RecyclerView, Data Binding (only in the MVVM variant), RxJava and RxAndroid, Retrofit 2, Picasso, Mockito, and Robolectric. The MVVM variant requires enabling data binding in its build.gradle file, which is a known configuration step. Because the project uses RxJava and Retrofit 2, you need a network connection to GitHub's API when the app runs. The model class GithubService is the key file to inspect if you want to understand the API contract.

Where this repository is the wrong tool

This is a sample from an older Android development era. The README mentions the data binding library as recently gaining popularity, which dates the project. It uses RxJava and RxAndroid, which many modern Android projects have replaced with coroutines and Flow. Retrofit 2 is still common, but the code style and dependency versions may not match current best practices. The standard Android variant is explicitly untested, so if you are looking for a fully tested reference implementation, this repository is not it. The app depends on the live GitHub API, which means it can break if the API changes or if a repository is renamed. As a learning tool, the repository is useful; as a production template, it would require significant updates. The lack of recent release information and the unknown last push date add uncertainty about whether the Gradle configuration still builds with current Android SDK versions.

A real alternative: Google's Android Architecture Blueprints

The most direct alternative to ivacf/archi is Google's Android Architecture Blueprints (now known as Android Architecture Samples) on GitHub. That project also implements the same app in multiple architectures, including MVP, MVVM, and MVI, but it is maintained by Google and kept current with modern Android tooling. The key difference in approach is that the Blueprints project uses a todo app as the sample domain and includes a test suite for every variation, whereas archi uses a GitHub repository browser and skips tests for the standard Android variant. The Blueprints project also demonstrates dependency injection with Dagger, which archi does not mention. If you want a comparison that includes current best practices like ViewModel, LiveData, and coroutines, the Blueprints project is a better starting point. Archi remains useful for its simplicity and its explicit focus on the untestability of the standard approach.

Maintenance and license considerations

The repository is licensed under Apache-2.0, which permits commercial use, modification, and distribution with attribution and without warranty. That is a permissive license, so you can copy code from it into your own projects, provided you keep the license notice. However, the maintenance cost is a concern. The repository has no recent releases listed and no information about the last push date. The README references the data binding library as new, which suggests the code may predate significant Android changes. You should expect to update the Gradle files, dependency versions, and possibly the Retrofit service to match your current toolchain. The model classes are simple, so porting them to a modern setup is not difficult, but the RxJava usage would need to be rewritten if you prefer coroutines. The lack of an active maintenance history means you should treat this as a static reference, not a living project.

Editorial conclusion

Adopt this repository if you are learning Android architecture patterns or teaching them: it gives you three concrete, compilable implementations of the same feature set, with the model and libraries held constant. Do not adopt it as a template for a production app: it is a sample from an older Android era, uses RxJava and Retrofit 2 without modern alternatives, and the standard variant is deliberately untested. Before relying on it, verify that the Gradle setup still builds with your current Android SDK and that the GitHub API endpoints used in the model still respond as expected, since the app depends on a live network call. The key judgement: this is a comparison artifact, not a foundation.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. README
4. Releases