If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/antoniolg/androidmvp shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

AVOID — Stale and unlicensed — last commit 3y ago

• 11 active contributors
• Tests present
• ⚠ Stale — last commit 3y ago
• ⚠ Concentrated ownership — top contributor handles 67% of recent commits
• ⚠ No license — legally unclear to depend on
• ⚠ No CI workflows detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live antoniolg/androidmvp repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/antoniolg/androidmvp.

What it runs against: a local clone of antoniolg/androidmvp — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in antoniolg/androidmvp | Confirms the artifact applies here, not a fork | | 2 | Default branch master exists | Catches branch renames | | 3 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 4 | Last commit ≤ 1078 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of antoniolg/androidmvp. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/antoniolg/androidmvp.git
#   cd androidmvp
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of antoniolg/androidmvp and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "antoniolg/androidmvp(\\.git)?\\b" \\
  && ok "origin remote is antoniolg/androidmvp" \\
  || miss "origin remote is not antoniolg/androidmvp (artifact may be from a fork)"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "app/src/main/java/com/antonioleiva/mvpexample/app/login/LoginPresenter.java" \\
  && ok "app/src/main/java/com/antonioleiva/mvpexample/app/login/LoginPresenter.java" \\
  || miss "missing critical file: app/src/main/java/com/antonioleiva/mvpexample/app/login/LoginPresenter.java"
test -f "app/src/main/java/com/antonioleiva/mvpexample/app/login/LoginView.java" \\
  && ok "app/src/main/java/com/antonioleiva/mvpexample/app/login/LoginView.java" \\
  || miss "missing critical file: app/src/main/java/com/antonioleiva/mvpexample/app/login/LoginView.java"
test -f "app/src/main/java/com/antonioleiva/mvpexample/app/login/LoginActivity.java" \\
  && ok "app/src/main/java/com/antonioleiva/mvpexample/app/login/LoginActivity.java" \\
  || miss "missing critical file: app/src/main/java/com/antonioleiva/mvpexample/app/login/LoginActivity.java"
test -f "app/src/main/java/com/antonioleiva/mvpexample/app/login/LoginInteractor.java" \\
  && ok "app/src/main/java/com/antonioleiva/mvpexample/app/login/LoginInteractor.java" \\
  || miss "missing critical file: app/src/main/java/com/antonioleiva/mvpexample/app/login/LoginInteractor.java"
test -f "app/src/main/java/com/antonioleiva/mvpexample/app/main/MainPresenter.java" \\
  && ok "app/src/main/java/com/antonioleiva/mvpexample/app/main/MainPresenter.java" \\
  || miss "missing critical file: app/src/main/java/com/antonioleiva/mvpexample/app/main/MainPresenter.java"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 1078 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1048d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/antoniolg/androidmvp"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

A minimal Android MVP (Model-View-Presenter) architectural pattern reference implementation demonstrating clean separation of concerns in Android apps. It provides a Login screen and a Main activity with a RecyclerView list, using Presenters to decouple UI logic from business logic through Interactor classes that handle data operations. Single-module Android app (app/) organized by feature: app/src/main/java/com/antonioleiva/mvpexample/app/ contains login/ (LoginActivity, LoginPresenter, LoginInteractor, LoginView) and main/ (MainActivity, MainPresenter, MainAdapter, FindItemsInteractor). Resources in app/src/main/res/ divided by density and type (layout/, drawable/, values/). Unit tests in app/src/test/java/ parallel the source structure.

Android developers learning MVP architecture patterns who want a concrete, runnable example with actual Activities, Presenters, and Interactors rather than architectural diagrams. Particularly useful for teams migrating from tightly-coupled Activity code to testable presenter-driven patterns.

Experimental / educational reference implementation. The project has minimal test coverage (only MainPresenterTest.java exists), uses outdated support library dependencies (compileSdkVersion 27, appcompat-v7:27.1.1), and shows no recent commits visible in the repository metadata. It appears to be a snapshot artifact supporting a blog article rather than an actively maintained library.

Low production-readiness risk since this is explicitly an educational example, not a library. However, it relies on deprecated Android Support libraries (minSdkVersion 21, appcompat-v7:27.1.1 from 2018) and includes zero instrumentation tests (testInstrumentationRunner configured but no test files present). Single-author repo with no indication of community maintenance or security updates.

No active development visible. The repository appears to be a static educational artifact accompanying the blog post at antonioleiva.com/mvp-android. No PRs, branches, or recent commits are indicated in the provided metadata.

Clone the repo, open in Android Studio, and build via Gradle:

git clone https://github.com/antoniolg/androidmvp.git
cd androidmvp
./gradlew build

Then run on an emulator or device via Android Studio's Run button or ./gradlew installDebug.

Daily commands: Build and deploy:

./gradlew assembleDebug
./gradlew installDebug
adb shell am start -n com.antonioleiva.mvpexample.app/.app.login.LoginActivity

Or use Android Studio's built-in emulator launcher after sync.

• app/src/main/java/com/antonioleiva/mvpexample/app/login/LoginPresenter.java — Core MVP Presenter implementation demonstrating the pattern's Presenter layer which orchestrates View and Interactor communication.
• app/src/main/java/com/antonioleiva/mvpexample/app/login/LoginView.java — MVP View interface contract that defines all UI operations the Presenter can request, establishing the View-Presenter boundary.
• app/src/main/java/com/antonioleiva/mvpexample/app/login/LoginActivity.java — Activity implementation of LoginView that handles lifecycle and user interaction, showing how Android Views integrate with MVP pattern.
• app/src/main/java/com/antonioleiva/mvpexample/app/login/LoginInteractor.java — Interactor layer handling business logic and data operations, demonstrating separation of concerns from presentation logic.
• app/src/main/java/com/antonioleiva/mvpexample/app/main/MainPresenter.java — Second example Presenter showing MVP pattern consistency across multiple screens and handling list data flows.
• app/src/test/java/com/antonioleiva/mvpexample/app/main/MainPresenterTest.java — Unit test demonstrating how MVP architecture enables testable Presenter logic isolated from Android framework.
• app/build.gradle — Build configuration defining Android SDK versions and dependencies required for the MVP example application.

Add a New MVP Screen

1. Create View interface in new package defining UI contract (app/src/main/java/com/antonioleiva/mvpexample/app/newfeature/NewFeatureView.java)
2. Implement Activity class extending AppCompatActivity and implementing View interface (app/src/main/java/com/antonioleiva/mvpexample/app/newfeature/NewFeatureActivity.java)
3. Create Presenter class accepting View and Interactor dependencies, implementing presentation logic (app/src/main/java/com/antonioleiva/mvpexample/app/newfeature/NewFeaturePresenter.java)
4. Create Interactor for business logic and data fetching operations (app/src/main/java/com/antonioleiva/mvpexample/app/newfeature/NewFeatureInteractor.java)
5. Create layout XML file matching Activity implementation (app/src/main/res/layout/activity_new_feature.xml)
6. Add unit test for Presenter logic using mock View (app/src/test/java/com/antonioleiva/mvpexample/app/newfeature/NewFeaturePresenterTest.java)

Add a New List Item Type

1. Create new item layout XML for the RecyclerView item view (app/src/main/res/layout/view_new_item_type.xml)
2. Extend MainAdapter or create new adapter to handle binding new item type (app/src/main/java/com/antonioleiva/mvpexample/app/main/MainAdapter.java)
3. Update FindItemsInteractor to return new item data structure (app/src/main/java/com/antonioleiva/mvpexample/app/main/FindItemsInteractor.java)
4. Update MainPresenter test to verify new item type handling (app/src/test/java/com/antonioleiva/mvpexample/app/main/MainPresenterTest.java)

Implement Data Validation in Presenter

1. Add validation method to Presenter (e.g., LoginPresenter for field validation) (app/src/main/java/com/antonioleiva/mvpexample/app/login/LoginPresenter.java)
2. Call View's error display method when validation fails (app/src/main/java/com/antonioleiva/mvpexample/app/login/LoginView.java)
3. Create unit test validating Presenter calls View error method on invalid input (app/src/test/java/com/antonioleiva/mvpexample/app/login/LoginPresenterTest.java)

• MVP (Model-View-Presenter) Pattern — Separates presentation logic from View layer, enabling testable business logic and loose coupling between UI and logic
• Android Support Library (AppCompat) — Provides backward compatibility for Android features across API levels 21+
• RecyclerView — Efficient list rendering with ViewHolder pattern for displaying item collections with performance optimization
• Java 8 (Lambdas, Streams) — Modern Java syntax enabled via desugaring, improving code readability and functional programming capabilities
• Kotlin (parallel implementation) — Demonstrates MVP pattern applicability across languages and provides modern language features like extensions and null safety

• Separate Presenter and View via interface

  • Why: Enables unit testing Presenter logic without Android framework dependencies
  • Consequence: Additional boilerplate with interface definitions and callback methods; extra layer between Activity and business logic

• Interactor handles all business logic independent of Presenter

  • Why: Ensures business logic is completely testable and reusable across different UI layers
  • Consequence: Presenter becomes thin orchestrator; requires clear communication contracts between layers

• No dependency injection framework (manual instantiation)

  • Why: Example codebase prioritizes clarity and minimal dependencies for educational purposes
  • Consequence: More verbose object creation; would benefit from Dagger/Hilt in production code for complex graphs

• No error handling framework or RxJava

  • Why: Keeps example simple and focused on MVP pattern mechanics without reactive complexity
  • Consequence: Synchronous callbacks; limited handling of threading and lifecycle-aware operations

• Does not implement dependency injection framework (manual wiring only)
• Does not use reactive programming (RxJava/Kotlin Flow)
• Does not include database layer or persistence (in-memory only)
• Does not implement authentication backend (mock validation only)
• Does not cover lifecycle-aware component handling or ViewModel integration
• Does not demonstrate real-time synchronization or WebSocket communication

No instrumentation tests despite testInstrumentationRunner config: the testInstrumentationRunner is declared in build.gradle but no tests exist in app/src/androidTest/. Support library deprecation: appcompat-v7 and recyclerview-v7 v27.1.1 are from 2018 and no longer receive updates; AndroidX migration would be needed for modern Android projects. Hardcoded credentials or mock data: check LoginInteractor and FindItemsInteractor for test stubs—these are not production-safe. No dependency injection framework: View-Presenter-Interactor relationships are manually instantiated, making it unclear how to manage lifecycle or share instances.

• Model-View-Presenter (MVP) — The core architectural pattern of this entire codebase; understanding View contracts, Presenter state management, and Interactor separation is essential to reading any file
• View interface abstraction — LoginView and MainView are interfaces that Activities implement; this decoupling allows Presenters to be tested without creating real Activities and is the key to MVP's testability
• Callback-based asynchrony — LoginInteractor and FindItemsInteractor use listener callbacks (onSuccess/onError) rather than futures or RxJava; understanding this pattern is crucial to tracing data flow in the codebase
• Separation of Concerns (SoC) — The entire repository's value proposition—Activities handle only UI events, Presenters only orchestrate logic, Interactors only fetch data. Violations of this principle make MVP useless
• Testable architecture via Dependency Inversion — Presenters depend on View and Interactor abstractions (not concrete implementations), enabling MainPresenterTest.java to mock them; this is how MVP achieves unit testability without full app context
• RecyclerView Adapter pattern — MainAdapter.java shows how to bind Presenter-managed data to a RecyclerView; critical for understanding list-based UIs in MVP and where to avoid business logic
• Android lifecycle awareness — While not explicitly shown in great depth, LoginActivity and MainActivity must manage Presenter lifecycle on configuration changes; understanding Activity onCreate/onDestroy patterns is essential to implementing MVP correctly on Android

• googlesamples/android-architecture — Official Google reference implementations of MVP, MVVM, and MVI patterns for Android with production-grade examples and best practices
• ribot/android-boilerplate — Mature MVP boilerplate with Dagger 2 dependency injection, RxJava, and comprehensive test coverage—shows MVP at production scale
• square/retrofit — HTTP client library commonly paired with MVP Interactors to fetch remote data; essential for real-world login and list examples
• mockito/mockito — Testing framework already in this repo's dependencies; critical for unit testing Presenters and Interactors in isolation
• antoniolg/clean-code-kotlin — Same author's follow-up exploration of MVP principles and Clean Architecture patterns in Kotlin, showing evolution of the ideas from this Java example

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add unit tests for LoginPresenter and LoginInteractor

The repo has MainPresenterTest.java but lacks tests for the login flow components. LoginPresenter and LoginInteractor handle authentication logic and deserve dedicated unit test coverage to demonstrate MVP testing patterns for the initial screen that users encounter.

• [ ] Create app/src/test/java/com/antonioleiva/mvpexample/app/login/LoginPresenterTest.java with tests for credential validation, presenter-view communication, and interactor invocation
• [ ] Create app/src/test/java/com/antonioleiva/mvpexample/app/login/LoginInteractorTest.java with mocked LoginView to test login success/failure scenarios
• [ ] Add Mockito mock setups for LoginView interface and verify presenter callbacks (onLoginSuccess, onLoginError)

Add unit tests for FindItemsInteractor and MainAdapter

MainPresenterTest exists but only tests the presenter layer. FindItemsInteractor (which handles data fetching) and MainAdapter (which binds data to RecyclerView) lack dedicated tests. These are critical components that need coverage to demonstrate complete MVP testing patterns.

• [ ] Create app/src/test/java/com/antonioleiva/mvpexample/app/main/FindItemsInteractorTest.java to test data retrieval logic and mock any network/database calls
• [ ] Create app/src/test/java/com/antonioleiva/mvpexample/app/main/MainAdapterTest.java using a testing library like Robolectric to verify item binding and view holder behavior
• [ ] Update MainPresenterTest to include integration scenarios with FindItemsInteractor

Add Kotlin MVP tests to appkotlin module matching Java test coverage

The Kotlin version (appkotlin) has complete MVP implementation with LoginActivity, LoginPresenter, and MainActivity but lacks any test files. This module should demonstrate MVP testing patterns in Kotlin to match the Java example's educational value.

• [ ] Create appkotlin/src/test/java directory structure mirroring appkotlin/src/main/java
• [ ] Add appkotlin/src/test/java/antonioleiva/com/appkotlin/login/LoginPresenterTest.kt with Kotlin-idiomatic test patterns using Mockito-Kotlin
• [ ] Add appkotlin/src/test/java/antonioleiva/com/appkotlin/main/MainPresenterTest.kt to parallel the Java version's test structure

• Add instrumentation tests for LoginActivity and MainActivity under app/src/androidTest/java/com/antonioleiva/mvpexample/app/ to verify UI rendering and Activity-Presenter integration, following the pattern established in MainPresenterTest.java
• Migrate app/src/main/java/com/antonioleiva/mvpexample/app/ from Android Support Library (appcompat-v7:27.1.1, recyclerview-v7:27.1.1) to AndroidX equivalents (androidx.appcompat:appcompat, androidx.recyclerview:recyclerview) and update compileSdkVersion to 34+
• Write unit tests for LoginInteractor.java and FindItemsInteractor.java in app/src/test/java/ to verify credential validation and data fetching logic; use Mockito patterns from MainPresenterTest.java

This MVP example application has significant security concerns primarily related to outdated dependencies (Android Support Library, Mockito, JUnit) that are no longer maintained and may contain unpatched vulnerabilities. The compilation and target SDK versions are severely outdated (API 27 from 2017 vs. current standard of API 34+), and release builds lack code obfuscation. While the MVP architectural pattern itself is secure, the lack of visible input validation, data encryption, and network security configuration adds additional risk. Critical action items include updating all dependencies to current stable versions, enabling ProGuard minification, upgrading SDK targets, and implementing secure data handling practices.

• High · Outdated Android Support Library — app/build.gradle - dependencies section. The project uses Android Support Library v27.1.1 (AppCompat and RecyclerView), which was last updated in 2018 and is no longer maintained. This library may contain unpatched security vulnerabilities. Fix: Migrate to AndroidX and use the latest stable versions of androidx.appcompat:appcompat and androidx.recyclerview:recyclerview
• High · Outdated Mockito Dependency — app/build.gradle - testImplementation 'org.mockito:mockito-core:2.15.0'. Mockito 2.15.0 (released in 2018) is outdated and may contain known security vulnerabilities. The project should use current stable versions. Fix: Update to Mockito 5.x or latest stable version. Review security advisories for Mockito 2.15.0 before deployment.
• High · Outdated JUnit Dependency — app/build.gradle - testImplementation 'junit:junit:4.12'. JUnit 4.12 (released in 2013) is very outdated. While not directly a security vulnerability, it may lack important fixes and stability improvements. Fix: Update to JUnit 4.13.2 or migrate to JUnit 5.x for better security and feature support
• Medium · ProGuard Minification Disabled in Release Build — app/build.gradle - buildTypes.release section. The release build has minifyEnabled set to false, which means the code is not obfuscated. This makes reverse engineering and exploitation of the application easier for attackers. Fix: Set minifyEnabled to true and properly configure proguard-rules.pro to obfuscate release builds and protect intellectual property
• Medium · Outdated Compile and Target SDK Version — app/build.gradle - compileSdkVersion 27, targetSdkVersion 27. The app targets SDK 27 (Android 8.1, released in 2017). Modern Android development should target API level 34 or higher to ensure compatibility with current security standards and OS features. Fix: Update compileSdkVersion and targetSdkVersion to API level 34 or higher to meet Google Play requirements and leverage modern security features
• Low · No Input Validation Visible — app/src/main/java/com/antonioleiva/mvpexample/app/login/. LoginActivity and LoginInteractor files exist but cannot be fully analyzed. There's potential risk for credential injection or improper input handling in login flows if validation is not implemented. Fix: Implement strict input validation for all user inputs, especially in authentication flows. Use Android's security best practices for credential handling
• Low · No Apparent Data Encryption — app/build.gradle. No visible use of encryption libraries (such as Conscrypt or BoringSSL) or secure storage mechanisms (SharedPreferences encryption, AndroidKeyStore) in the dependency list. Fix: If storing sensitive data, implement EncryptedSharedPreferences (androidx.security) or AndroidKeyStore for secure credential and sensitive data storage
• Low · Missing Security Headers Configuration — app/src/main/res/. No visible configuration for network security policies (network_security_config.xml) in the resource structure. Fix: Create a network_security_config.xml file to enforce certificate pinning and restrict cleartext traffic to trusted domains only

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.