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/janishar/android-mvp-architecture 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.

WAIT — Stale — last commit 2y ago

• 13 active contributors
• Apache-2.0 licensed
• Tests present
• ⚠ Stale — last commit 2y ago
• ⚠ Concentrated ownership — top contributor handles 50% of recent commits
• ⚠ 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 janishar/android-mvp-architecture repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/janishar/android-mvp-architecture.

What it runs against: a local clone of janishar/android-mvp-architecture — 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 janishar/android-mvp-architecture | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 782 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of janishar/android-mvp-architecture. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/janishar/android-mvp-architecture.git
#   cd android-mvp-architecture
#
# 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 janishar/android-mvp-architecture and re-run."
  exit 2
fi

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

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

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 782 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~752d)"
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/janishar/android-mvp-architecture"
  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 deprecated but comprehensive Android sample app demonstrating Model-View-Presenter (MVP) architecture with Dagger2 dependency injection, GreenDao ORM, RxJava2 reactive streams, and FastAndroidNetworking for HTTP calls. It provides a production-like quiz/survey application with user authentication, question feeds, ratings, and local database persistence—serving as a reference implementation for enterprise Android architecture patterns. Standard Android monorepo structure: app/src/main/java contains source split into data/ (AppDataManager, DbHelper, ApiHelper), di/ (Dagger components/modules), ui/ (Activities/Presenters), service/, and utils/. Database models (User, Question, Option) live in data/db/model/; network contracts in data/network/ (ApiEndPoint, ApiHeader, ApiHelper). Assets include seed data JSON files for questions and options.

Android developers learning MVP architecture and dependency injection; architects designing scalable Android apps with clean separation of concerns; teams migrating from older patterns who need concrete examples of Dagger2, GreenDao, and RxJava2 integration in a real Activity/Fragment structure.

Explicitly deprecated as of the README (redirects to newer WIMM project). The codebase is well-structured with test infrastructure (TestComponent.java, LoginActivityTest.java in androidTest/), but active development has ceased in favor of modern Android development practices. Age and commit recency unknown from provided data, but architecture reflects 2017-era best practices.

High architectural obsolescence risk: the project is publicly deprecated and the author directs new users to a different repo (unusualcodeorg/wimm-android-app). Dependencies like GreenDao, RxJava2, and Support Library are no longer current (Android Jetpack/Room/Flow are preferred). Single maintainer (janisharali) with no visible CI/CD pipeline setup in provided file list. No indication of active issue triage or PR reviews.

No active development—project is in archived/deprecated state. README explicitly directs users to the successor project (wimm-android-app). No recent commits, PRs, or issues mentioned in provided data.

Clone the repository: git clone https://github.com/janishar/android-mvp-architecture.git && cd android-mvp-architecture. Open in Android Studio (requires Gradle; build.gradle uses GreenDao plugin). Build with: ./gradlew build. Run on emulator/device with ./gradlew installDebug or via Android Studio's Run button. Mock API at http://www.mocky.io/v2 is pre-configured in BuildConfig.

Daily commands: Debug build (emulator): ./gradlew installDebug then launch app from device. Release build: ./gradlew assembleRelease (ProGuard enabled, see proguard-rules.pro). MockServer endpoints configured via BuildConfig.BASE_URL (http://www.mocky.io/v2) with hardcoded API_KEY in build.gradle.

• app/src/main/java/com/mindorks/framework/mvp/MvpApp.java: Application class that initializes Dagger DI component and global app state; entry point for dependency graph setup
• app/src/main/java/com/mindorks/framework/mvp/data/AppDataManager.java: Facade implementing DataManager interface; coordinates all data sources (DB, network, preferences) for presenters
• app/src/main/java/com/mindorks/framework/mvp/data/db/DbOpenHelper.java: GreenDao schema initialization and database setup; manages SQLite database lifecycle
• app/src/main/java/com/mindorks/framework/mvp/data/network/AppApiHelper.java: HTTP client wrapper using FastAndroidNetworking; handles all REST API calls with RxJava2 Observables
• app/build.gradle: Gradle configuration with GreenDao plugin, BuildConfig API endpoints/keys, and all library dependencies
• app/src/androidTest/java/com/mindorks/framework/mvp/di/component/TestComponent.java: Custom Dagger component for instrumentation tests; swaps real modules with test doubles
• app/src/main/assets/seed/questions.json: Seed data for quiz questions; demonstrates how initial DB population works on app first-run

For new MVP screens: create Activity and Presenter in ui/{feature}/ (see ui/login/LoginActivity.java, ui/login/LoginActivityTest.java as template); add DI bindings in di/module/ and component interfaces in di/component/; use AppDataManager for data access. For DB changes: modify data/db/model/ POJOs (User.java, Question.java), increment greendao.schemaVersion in build.gradle, rebuild. For API endpoints: add to data/network/ApiEndPoint.java and data/network/AppApiHelper.java.

GreenDao requires manual schema version bumping in build.gradle and recompilation when entity classes change; no automatic migrations. MockServer endpoints (mocky.io) may become unavailable, breaking API testing. BuildConfig.BASE_URL and API_KEY are hardcoded per build type—environment-specific overrides require build variant management. Support Library is deprecated in favor of AndroidX; direct dependency on appcompat-v7 version. No visible Gradle wrapper (.gradle/wrapper/gradle-wrapper.jar) in file list—native gradle installation required. Database initialization happens in DbOpenHelper.onCreate()—GreenDao tables auto-generated but seed data (options.json, questions.json) must be manually loaded.

• Model-View-Presenter (MVP) — Core architectural pattern in this entire codebase; Presenters decouple UI logic (Views/Activities) from business logic (Models/Interactors), enabling testability and reusability—essential to understand the ui/ and data/ package separation
• Dependency Injection (Dagger2) — The di/ package uses Dagger2 to auto-wire components (Components, Modules, Scopes) at compile-time; enables swapping real vs. test implementations (TestComponent.java) and decouples object creation from usage throughout presenters and data managers
• Reactive Streams (RxJava2) — AppApiHelper and data layer return Observables for async network calls and database queries; presenters subscribe to these streams to handle backpressure, error handling, and lifecycle-aware disposal—core pattern throughout data access layer
• Object-Relational Mapping (GreenDao) — Maps database models (User.java, Question.java, Option.java in data/db/model/) to SQLite tables; AppDbHelper uses DaoSession to persist and query entities; generates table schemas from POJOs at compile-time via greendao gradle plugin
• Facade Pattern — AppDataManager implements the DataManager interface as a single facade; presenters depend on DataManager abstraction rather than separate DbHelper, ApiHelper, and PreferenceHelper—simplifies data layer complexity and enables easier testing via mocks
• Activity/Fragment Lifecycle Integration — Presenters must subscribe/unsubscribe from RxJava2 Observables in sync with Activity onCreate/onDestroy to avoid memory leaks and crashes; TestComponentRule.java in tests manages lifecycle for instrumentation testing
• Build Variants and BuildConfig — build.gradle defines debug/release buildTypes with different BASE_URL and API_KEY values injected into BuildConfig; allows same code to target mock servers (mocky.io) in dev and production servers in release without code changes

• janishar/PlaceHolderView — Official UI library used in this MVP app for rendering placeholder/empty states in feeds and lists
• janishar/android-dagger2-example — Companion learning repo by same author focusing deep-dive on Dagger2 DI patterns used throughout this app
• unusualcodeorg/wimm-android-app — Official successor repo; modern Android development replacement for this deprecated MVP sample with MVVM, Jetpack, and Flow
• googlesamples/android-architecture — Official Google Android architecture samples; includes TODO-MVP reference implementation with similar patterns but using AAC
• ribot/android-boilerplate — Similar-era MVP boilerplate with Dagger2 and RxJava; alternative reference for structuring Android MVP projects

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 comprehensive unit tests for DataManager and AppDataManager

The repo has minimal test coverage. AppDataManager.java and DataManager.java are critical data orchestration classes that coordinate between network, database, and preferences layers. These classes lack unit tests despite being central to the MVP architecture. Adding unit tests here would demonstrate proper testing of data layer dependencies and improve code reliability for contributors.

• [ ] Create app/src/test/java/com/mindorks/framework/mvp/data/AppDataManagerTest.java with mocked ApiHelper, DbHelper, and PreferencesHelper
• [ ] Add tests for each public method in AppDataManager (e.g., login flow, logout, data persistence)
• [ ] Create app/src/test/java/com/mindorks/framework/mvp/data/network/AppApiHelperTest.java to test network request handling
• [ ] Verify RxJava2 Observable chain behavior using TestObserver in test cases
• [ ] Update build.gradle to include junit, mockito, and rxjava2 test dependencies if missing

Add instrumented tests for Dagger2 dependency injection with TestComponent validation

The repo already has TestComponent.java and TestComponentRule.java set up, but only contains one LoginActivityTest.java. The Dagger2 DI setup with multiple scopes (@PerActivity, @PerService) and custom annotations (@ApplicationContext, @ActivityContext) is complex and error-prone. More instrumented tests are needed to validate that components correctly inject dependencies across different scopes, ensuring contributors don't break the DI graph.

• [ ] Expand app/src/androidTest/java/com/mindorks/framework/mvp/ui/login/LoginActivityTest.java with assertions for presenter and manager injection
• [ ] Create app/src/androidTest/java/com/mindorks/framework/mvp/di/component/ActivityComponentTest.java to validate component bindings
• [ ] Add tests in androidTest for ApplicationComponent to verify ApplicationTestModule correctly overrides production dependencies
• [ ] Test that @PerActivity scoped objects are properly created and destroyed across activity lifecycles
• [ ] Verify that PreferencesHelper and DbHelper are correctly injected into activities via ActivityComponent

Add integration tests for GreenDao database operations in AppDbHelper

AppDbHelper.java and DbOpenHelper.java manage all database operations for User, Question, and Option models, but there are no tests verifying that CRUD operations work correctly with the actual GreenDao ORM. Given the schemaVersion 1 configuration in build.gradle, database migrations and model persistence are critical. Integration tests would catch regressions when the schema evolves.

• [ ] Create app/src/androidTest/java/com/mindorks/framework/mvp/data/db/AppDbHelperTest.java with AndroidJUnit4
• [ ] Add test cases for inserting, updating, deleting, and querying User objects using GreenDao DAOs
• [ ] Test transaction handling when saving Question and Option entities together
• [ ] Verify database queries work correctly by checking returned Observable emissions using TestObserver
• [ ] Add a test for DbOpenHelper.onUpgrade() behavior when schemaVersion is incremented in greendao config

• Migrate database layer from GreenDao to AndroidX Room: Replace data/db/AppDbHelper.java and DbOpenHelper.java with Room DAOs, update build.gradle to remove GreenDao plugin, and refactor AppDataManager to use Room repositories instead of DaoSession objects.
• Add AndroidX and Jetpack migration: Update app/build.gradle to replace android.support:appcompat-v7 with androidx.appcompat:appcompat, replace RxJava2 with LiveData/Flow in data presenters, and update all import statements in ui/ and di/ packages.
• Expand unit test coverage for AppDataManager: Create tests/com/mindorks/framework/mvp/data/AppDataManagerTest.java with mocked DbHelper and ApiHelper dependencies (using Mockito); cover all CRUD operations for User, Question, Option models and API error handling.

• High · Hardcoded API Credentials in Build Configuration — app/build.gradle (buildTypes: debug and release). The build.gradle file contains hardcoded API_KEY and BASE_URL values directly in buildConfigField declarations. These credentials are embedded in the compiled APK and can be easily extracted through reverse engineering. The API_KEY 'ABCXYZ123TEST' appears to be a test key, but the practice of hardcoding secrets in build files is a critical security risk. Fix: Use a secure secrets management approach such as: 1) Store API keys in local.properties (excluded from VCS), 2) Use Android Keystore for sensitive credentials, 3) Implement server-side authentication instead of embedding keys in the client, 4) Use BuildConfig with environment variables during CI/CD pipelines, 5) Consider using a secrets management tool like Google Cloud Secret Manager or AWS Secrets Manager.
• High · Deprecated Project with Outdated Dependencies — README.md and app/build.gradle. The project is explicitly marked as deprecated in the README. This indicates the codebase is no longer actively maintained. The dependencies (particularly Dagger2, GreenDao, RxJava, and support libraries) are from 2017-era Android development. Deprecated and outdated libraries contain known security vulnerabilities and lack security patches. Fix: Migrate to the maintained fork (Modern Android Development - WhereIsMyMotivation) or perform a comprehensive dependency upgrade. Update to latest stable versions of: androidx libraries (replace support-v7), Dagger 2.x latest, RxJava 3.x, and ensure all transitive dependencies are audited for known CVEs.
• High · Insecure Network Configuration - Cleartext HTTP — app/build.gradle (buildConfigField BASE_URL in both debug and release). The build.gradle shows BASE_URL configured as 'http://www.mocky.io/v2' (cleartext HTTP) instead of HTTPS. This allows man-in-the-middle (MITM) attacks where network traffic can be intercepted, credentials can be stolen, and responses can be modified. Fix: 1) Use HTTPS exclusively for all API endpoints, 2) Implement certificate pinning to prevent MITM attacks, 3) Add a network security configuration file (network_security_config.xml) to enforce HTTPS, 4) Configure Android to disallow cleartext traffic for the domain.
• Medium · Potential SQL Injection via GreenDao ORM — app/src/main/java/com/mindorks/framework/mvp/data/db/ (AppDbHelper.java, DbOpenHelper.java). The project uses GreenDao for database operations. While ORM frameworks like GreenDao provide some protection against SQL injection, the presence of raw database helper classes (AppDbHelper, DbOpenHelper) suggests potential for raw SQL queries without parameterization. The file structure shows db/model classes but actual query implementations are not visible. Fix: 1) Audit all database query implementations for raw SQL, 2) Always use parameterized queries or ORM query methods, 3) Never concatenate user input into SQL strings, 4) Validate and sanitize all inputs before database operations, 5) Use GreenDao's generated query APIs instead of raw SQL when possible.
• Medium · Insufficient Input Validation on Network Models — app/src/main/java/com/mindorks/framework/mvp/data/network/model/. The project defines network model classes (LoginRequest, LoginResponse, ApiError, etc.) but there is no evidence of input validation on data received from API responses. Malicious or malformed API responses could lead to crashes, data corruption, or injection attacks. Fix: 1) Implement strict input validation for all API responses, 2) Use JSON schema validation, 3) Validate data types, ranges, and formats before using them, 4) Implement defensive parsing with proper error handling, 5) Consider using type-safe deserialization libraries with validation capabilities.
• Medium · ProGuard Configuration May Not Adequately Protect Sensitive Code — app/proguard-rules.pro. The project includes proguard-rules.pro for release builds, but the actual rules are not visible in the provided content. ProGuard obfuscation can be bypassed, and improper configuration may leave sensitive code unprotected or cause functionality issues. Fix: 1) Review and strengthen ProGuard rules to obfuscate sensitive classes and methods, 2) Ensure API endpoint classes and

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.