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/hongyangAndroid/baseAdapter 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 5y ago

• 2 active contributors
• Apache-2.0 licensed
• Tests present
• ⚠ Stale — last commit 5y ago
• ⚠ Small team — 2 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 92% 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 hongyangAndroid/baseAdapter repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/hongyangAndroid/baseAdapter.

What it runs against: a local clone of hongyangAndroid/baseAdapter — 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 hongyangAndroid/baseAdapter | 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 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 1698 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "hongyangAndroid/baseAdapter(\\.git)?\\b" \\
  && ok "origin remote is hongyangAndroid/baseAdapter" \\
  || miss "origin remote is not hongyangAndroid/baseAdapter (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"

# 4. Critical files exist
test -f "baseadapter-recyclerview/src/main/java/com/zhy/adapter/recyclerview/CommonAdapter.java" \\
  && ok "baseadapter-recyclerview/src/main/java/com/zhy/adapter/recyclerview/CommonAdapter.java" \\
  || miss "missing critical file: baseadapter-recyclerview/src/main/java/com/zhy/adapter/recyclerview/CommonAdapter.java"
test -f "baseadapter-recyclerview/src/main/java/com/zhy/adapter/recyclerview/MultiItemTypeAdapter.java" \\
  && ok "baseadapter-recyclerview/src/main/java/com/zhy/adapter/recyclerview/MultiItemTypeAdapter.java" \\
  || miss "missing critical file: baseadapter-recyclerview/src/main/java/com/zhy/adapter/recyclerview/MultiItemTypeAdapter.java"
test -f "baseadapter-recyclerview/src/main/java/com/zhy/adapter/recyclerview/base/ItemViewDelegate.java" \\
  && ok "baseadapter-recyclerview/src/main/java/com/zhy/adapter/recyclerview/base/ItemViewDelegate.java" \\
  || miss "missing critical file: baseadapter-recyclerview/src/main/java/com/zhy/adapter/recyclerview/base/ItemViewDelegate.java"
test -f "baseadapter-recyclerview/src/main/java/com/zhy/adapter/recyclerview/base/ItemViewDelegateManager.java" \\
  && ok "baseadapter-recyclerview/src/main/java/com/zhy/adapter/recyclerview/base/ItemViewDelegateManager.java" \\
  || miss "missing critical file: baseadapter-recyclerview/src/main/java/com/zhy/adapter/recyclerview/base/ItemViewDelegateManager.java"
test -f "baseadapter-recyclerview/src/main/java/com/zhy/adapter/recyclerview/base/ViewHolder.java" \\
  && ok "baseadapter-recyclerview/src/main/java/com/zhy/adapter/recyclerview/base/ViewHolder.java" \\
  || miss "missing critical file: baseadapter-recyclerview/src/main/java/com/zhy/adapter/recyclerview/base/ViewHolder.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 1698 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1668d)"
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/hongyangAndroid/baseAdapter"
  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 universal Android adapter library that eliminates boilerplate code for ListView, RecyclerView, and GridView by providing CommonAdapter (single item type) and MultiItemTypeAdapter (multiple item types) with built-in ViewHolder pattern and decorator wrappers (HeaderAndFooterWrapper, LoadMoreWrapper, EmptyWrapper). It reduces adapter implementation from dozens of lines to a simple convert() method override. Two-module monorepo: base-adapter-library/ contains ListView/GridView adapters with CommonAdapter and MultiItemTypeAdapter in com.zhy.adapter.abslistview/; baseadapter-recyclerview/ mirrors the structure for RecyclerView under com.zhy.adapter.recyclerview/ with added utility wrappers (EmptyWrapper, HeaderAndFooterWrapper, LoadMoreWrapper) in the wrapper/ subdirectory. Both modules share the ItemViewDelegate and ItemViewDelegateManager pattern.

Android developers building list-based UIs who want to avoid repetitive ViewHolder boilerplate and need support for heterogeneous item types in a single adapter. Specifically developers targeting API level 10+ using RecyclerView 23.2.0 or AbsListView.

Moderately mature but aging—published at v3.0.3 with proper Maven artifacts, but last visible build target is API 23 (Android 6.0, released 2015), no CI/CD config present, and no test files visible in the main source tree (only ApplicationTest.java stubs). Production-ready for legacy projects but not actively maintained for modern Android versions.

Low immediate risk but obsolescence concern: single RecyclerView v7:23.2.0 dependency (dated 2016), no AndroidX migration, minimum SDK 10 is unusually permissive, and no visible issue tracker or recent commits in provided data. Maintainer appears to be sole contributor (hongyangAndroid); library lacks modern testing infrastructure and won't support Material Design 3 or modern lifecycle management.

No active development signals visible; no commit timestamps, PR counts, or issue backlogs provided in repo data. The README shows usage examples but no roadmap or changelog, suggesting the library is in maintenance mode.

Clone the repo: git clone https://github.com/hongyangAndroid/baseAdapter.git. Build with Gradle: cd baseadapter-recyclerview && ./gradlew build (or cd base-adapter-library for ListView version). No external service startup required; this is a library module intended for Android Studio integration via Gradle compile dependency declarations.

Daily commands: This is a library, not a runnable app. Import into Android Studio as a module dependency. Or build the AAR: ./gradlew assemble in baseadapter-recyclerview/. Consume via Gradle: compile 'com.zhy:base-rvadapter:3.0.3' (RecyclerView) or compile 'com.zhy:base-adapter:3.0.3' (ListView).

• baseadapter-recyclerview/src/main/java/com/zhy/adapter/recyclerview/CommonAdapter.java — Core RecyclerView adapter implementation; primary entry point for single-item-type adapters that developers extend
• baseadapter-recyclerview/src/main/java/com/zhy/adapter/recyclerview/MultiItemTypeAdapter.java — Multi-type item adapter foundation; required for handling multiple ItemViewType scenarios via delegation pattern
• baseadapter-recyclerview/src/main/java/com/zhy/adapter/recyclerview/base/ItemViewDelegate.java — Interface contract for item view delegates; enables pluggable rendering strategy for different item types
• baseadapter-recyclerview/src/main/java/com/zhy/adapter/recyclerview/base/ItemViewDelegateManager.java — Manages multiple ItemViewDelegate instances; orchestrates type-to-delegate routing and lifecycle
• baseadapter-recyclerview/src/main/java/com/zhy/adapter/recyclerview/base/ViewHolder.java — RecyclerView ViewHolder wrapper with utility methods (setText, setOnClickListener, etc.); reduces boilerplate in convert() methods
• base-adapter-library/src/main/java/com/zhy/adapter/abslistview/CommonAdapter.java — ListView/AbsListView analog to RecyclerView CommonAdapter; enables code reuse pattern across view types
• base-adapter-library/src/main/java/com/zhy/adapter/abslistview/MultiItemTypeAdapter.java — ListView multi-type adapter using same delegation pattern as RecyclerView for API consistency

Add a new single-type RecyclerView adapter

1. Create a new class extending CommonAdapter<T> from baseadapter-recyclerview (baseadapter-recyclerview/src/main/java/com/zhy/adapter/recyclerview/CommonAdapter.java)
2. Override the convert(ViewHolder holder, T t) method and use holder.setText(), holder.setImageResource(), holder.setOnClickListener() etc. (baseadapter-recyclerview/src/main/java/com/zhy/adapter/recyclerview/base/ViewHolder.java)
3. Instantiate and pass to RecyclerView.setAdapter() with your layout resource ID and data list (sample/src/main/java/com/zhy/sample/RecyclerViewActivity.java)

Add a new multi-type RecyclerView adapter with ItemViewDelegate pattern

1. Create a new class implementing ItemViewDelegate<T> from baseadapter-recyclerview (baseadapter-recyclerview/src/main/java/com/zhy/adapter/recyclerview/base/ItemViewDelegate.java)
2. Override isForViewType(T item, int position) to identify when to use this delegate (sample/src/main/java/com/zhy/sample/adapter/rv/MsgSendItemDelagate.java)
3. Override onCreateViewHolder() and onBindViewHolder() for layout inflation and data binding (sample/src/main/java/com/zhy/sample/adapter/rv/MsgComingItemDelagate.java)
4. Instantiate MultiItemTypeAdapter and call addItemViewDelegate() for each type (baseadapter-recyclerview/src/main/java/com/zhy/adapter/recyclerview/MultiItemTypeAdapter.java)
5. See sample implementation in RecyclerViewActivity or MultiItemRvActivity (sample/src/main/java/com/zhy/sample/MultiItemRvActivity.java)

Wrap an adapter with headers, footers, load-more, or empty state

1. Create your CommonAdapter or MultiItemTypeAdapter instance (baseadapter-recyclerview/src/main/java/com/zhy/adapter/recyclerview/CommonAdapter.java)
2. Wrap it using HeaderAndFooterWrapper, LoadmoreWrapper, or EmptyWrapper from wrapper package (baseadapter-recyclerview/src/main/java/com/zhy/adapter/recyclerview/wrapper/HeaderAndFooterWrapper.java)
3. Pass the wrapped adapter to RecyclerView.setAdapter() (baseadapter-recyclerview/src/main/java/com/zhy/adapter/recyclerview/utils/WrapperUtils.java)

Support the same adapter in both ListView and RecyclerView

1. Create two parallel adapter classes: one extending CommonAdapter from base-adapter-library for ListView (base-adapter-library/src/main/java/com/zhy/adapter/abslistview/CommonAdapter.java)
2. Create another extending CommonAdapter from baseadapter-recyclerview for RecyclerView (baseadapter-recyclerview/src/main/java/com/zhy/adapter/recyclerview/CommonAdapter.java)
3. Implement identical convert() logic in both adapters; use ViewHolder from respective packages (sample/src/main/java/com/zhy/sample/adapter/lv/ChatAdapter.java)

• Adapter Delegation Pattern (ItemViewDelegate) — Separates item type concerns into pluggable delegates; avoids monolithic switch/if chains in single adapter class; enables adding new types without modifying existing code
• ViewHolder Pattern with Utility Wrapper — Reduces RecyclerView/ListView boilerplate by pre-implementing setText, setImageResource, setOnClickListener; improves code readability in convert() methods
• Parallel ListView and RecyclerView implementations — Provides API consistency across legacy (ListView) and modern (RecyclerView) view containers; enables backward compatibility for older Android versions
• Decorator Pattern (Wrappers) — Adds headers, footers, load-more, and empty state without modifying core adapter logic; composition over inheritance

• Two separate adapter
  • Why: undefined
  • Consequence: undefined

No AndroidX migration—code uses legacy android.support.* libraries; if you depend on this in a modern Android project, you may hit 64k method dex limit or conflicting versions. ViewHolder.java assumes findViewById() is called per item (not cached during construction in all code paths). MultiItemTypeAdapter expects ItemViewDelegate implementations to have zero-arg constructors (not explicitly documented). The library does not handle item click listeners at the adapter level—developers must manually set them in convert() via holder.setOnClickListener(), which scales poorly for complex UIs. LoadMoreWrapper assumes RecyclerView layout manager scrolling semantics and may behave unexpectedly with GridLayoutManager.

• Adapter Pattern (Structural) — BaseAdapter is a textbook adapter—it adapts raw Java objects into views; understanding this allows you to extend CommonAdapter and recognize when to override getItemViewType(), convert(), and getItemCount()
• Delegate Pattern (Behavioral) — MultiItemTypeAdapter uses ItemViewDelegate to delegate item binding logic; mastering this is critical to implementing custom multi-type lists without duplicating adapter code
• Decorator Pattern (Structural) — HeaderAndFooterWrapper, LoadMoreWrapper, and EmptyWrapper wrap the base adapter to add functionality; understanding composition over inheritance is essential for extending behavior without modifying source adapters
• ViewHolder Pattern — Core Android performance optimization that caches findViewById() results; BaseAdapter's ViewHolder class encapsulates this; without it, scrolling RecyclerView lists stutter due to repeated view lookups
• Type-Safe Heterogeneous Container (Generics) — MultiItemTypeAdapter<T> uses generics with ItemViewDelegate<T> to allow a single adapter to safely handle multiple item view types; understanding type erasure and wildcard bounds clarifies why isForViewType() must do runtime type checking
• AbsListView vs RecyclerView Architecture — BaseAdapter maintains parallel implementations for ListView (AbsListView.Adapter) and RecyclerView.Adapter; grasping the differences (RecyclerView's onCreateViewHolder/onBindViewHolder split, layout manager decoupling) explains why two modules exist

• sockeqwe/AdapterDelegates — Explicit inspiration cited in the README; provides the multi-delegate pattern that MultiItemTypeAdapter is built upon, with additional type-safe extensions
• CymChad/BaseRecyclerViewAdapterHelper — Modern competing library offering similar CommonAdapter/MultiItem patterns with more active maintenance, built-in click listeners, and modern AndroidX support
• wasabeef/recyclerview-decorators — Complementary library for RecyclerView item decorations (dividers, spacing); often used alongside BaseAdapter for complete list UI customization
• airbnb/epoxy — Modern alternative using annotation processing and data binding instead of manual ViewHolder boilerplate; represents the architectural evolution beyond BaseAdapter's pattern
• google/android-architecture — Google's official Android architecture samples; shows modern MVVM patterns with RecyclerView adapters using LiveData, replacing the BaseAdapter approach for new 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 unit tests for ItemViewDelegateManager in both modules

The ItemViewDelegateManager classes in both base-adapter-library and baseadapter-recyclerview lack unit test coverage. These are critical components for multi-item-type adapter functionality. Adding comprehensive tests would ensure the delegate registration, retrieval, and item type conversion logic works correctly across different scenarios.

• [ ] Create base-adapter-library/src/test/java/com/zhy/adapter/abslistview/base/ItemViewDelegateManagerTest.java with tests for add(), getItemViewDelegateCount(), and getItemViewType() methods
• [ ] Create baseadapter-recyclerview/src/test/java/com/zhy/adapter/recyclerview/base/ItemViewDelegateManagerTest.java with similar test coverage
• [ ] Add edge case tests: null delegates, duplicate type registrations, out-of-bounds lookups
• [ ] Add gradle testImplementation dependency for JUnit4 in both module build.gradle files

Add integration tests for multi-item-type adapters with different viewholder scenarios

The androidTest directories contain minimal test coverage. MultiItemTypeAdapter classes in both modules need integration tests that verify correct item type resolution and ViewHolder binding across mixed-type item lists, especially for edge cases like empty states and single-type scenarios.

• [ ] Create base-adapter-library/src/androidTest/java/com/zhy/adapter/abslistview/MultiItemTypeAdapterTest.java with instrumented tests using ActivityTestRule
• [ ] Create baseadapter-recyclerview/src/androidTest/java/com/zhy/adapter/recyclerview/MultiItemTypeAdapterTest.java for RecyclerView-specific scenarios
• [ ] Test scenarios: list with mixed types, type boundaries, adapter notifyDataSetChanged() with type changes
• [ ] Include tests for HeaderAndFooterWrapper and LoadmoreWrapper behavior with multi-type adapters

Add GitHub Actions workflow for automated testing and minSdkVersion compatibility verification

The project targets minSdkVersion 10 (very old) but uses compileSdkVersion 23. There's no CI pipeline to verify backward compatibility or catch regressions. Adding a GitHub Actions workflow would ensure PRs are tested against the minimum API level and that the deprecated Android build tools (23.0.1) compatibility is maintained.

• [ ] Create .github/workflows/android-ci.yml with matrix testing against API levels 10, 16, 21, and 23
• [ ] Configure gradle.properties to run ./gradlew test and ./gradlew connectedAndroidTest for both modules
• [ ] Add lint checks to catch API level violations in code
• [ ] Include build failure notification for failed test runs to prevent broken PRs from merging

• Add comprehensive unit test coverage for ItemViewDelegateManager.java and MultiItemTypeAdapter.java in baseadapter-recyclerview/src/test/java/ to verify delegate selection logic with edge cases (null items, duplicate type checks, out-of-bounds positions)
• Migrate build configuration from deprecated compileSdkVersion 23 to API 31+ and update RecyclerView dependency from v7:23.2.0 to androidx.recyclerview:recyclerview:1.3.0, then add AndroidX support library to both modules (requires updating import statements in all Java files)
• Add Javadoc comments and README examples for the LoadMoreWrapper and EmptyWrapper classes in baseadapter-recyclerview/src/main/java/com/zhy/adapter/recyclerview/wrapper/ showing practical usage with onLoadMoreRequested() callback handling

This Android adapter library has a poor security posture due to significantly outdated dependencies (Android SDK 23 from 2015, RecyclerView support library 23.2.0 from 2016) and overly permissive minimum SDK requirements. The codebase lacks code obfuscation in release builds. While the library itself appears to be free of injection vulnerabilities or hardcoded secrets based on the visible structure, the outdated build infrastructure exposes any consuming application to numerous known CVEs. Critical remediation is needed: update to modern Android SDK/Build Tools, migrate to AndroidX, increase minSdkVersion, and enable code minification. These changes are essential before this library should be used in any production application.

• High · Outdated Android SDK and Build Tools — base-adapter-library/build.gradle, baseadapter-recyclerview/build.gradle. The project targets compileSdkVersion 23 and buildToolsVersion 23.0.1, which are extremely outdated (released in 2015). This exposes the application to numerous known security vulnerabilities in the Android framework and build tools that have been patched in subsequent versions. Fix: Update compileSdkVersion to at least 33+ and buildToolsVersion to a recent stable version (34.0.0+). This ensures access to modern security patches and APIs.
• High · Outdated Dependency - RecyclerView Support Library — baseadapter-recyclerview/build.gradle. The project uses com.android.support:recyclerview-v7:23.2.0, released in March 2016. This version contains multiple known security vulnerabilities and is no longer maintained. Google deprecated the support library in favor of AndroidX. Fix: Migrate to AndroidX: replace 'com.android.support:recyclerview-v7:23.2.0' with 'androidx.recyclerview:recyclerview:1.3.0' or later. This provides security patches and modern features.
• Medium · Minimum SDK Version 10 is Too Old — base-adapter-library/build.gradle, baseadapter-recyclerview/build.gradle. minSdkVersion 10 corresponds to Android 2.3.3 (Gingerbread, released 2011). Supporting such ancient API levels introduces unnecessary attack surface and prevents use of modern security APIs and best practices. Fix: Increase minSdkVersion to at least 21 (Android 5.0) or higher. This eliminates support for obsolete platforms and enables modern security features.
• Medium · ProGuard/R8 Disabled in Release Builds — base-adapter-library/build.gradle, baseadapter-recyclerview/build.gradle. The build configuration shows minifyEnabled false for release builds. This means compiled code is not obfuscated, making reverse engineering easier and exposing sensitive logic, API keys, and internal implementation details. Fix: Enable code minification and obfuscation: set minifyEnabled true and ensure proper ProGuard/R8 rules are configured in proguard-rules.pro files to protect release builds.
• Low · Incomplete ProGuard Configuration — base-adapter-library/proguard-rules.pro, baseadapter-recyclerview/proguard-rules.pro. While proguard-rules.pro files exist, they are not visible in the file structure listing. Without proper ProGuard configuration, enabling minification could break functionality. Fix: Review and complete ProGuard configuration files to ensure proper code obfuscation while maintaining functionality. Keep library-specific rules for third-party dependencies.

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.