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/yanzhenjie/SwipeRecyclerView 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

• 6 active contributors
• Apache-2.0 licensed
• ⚠ Stale — last commit 2y ago
• ⚠ Concentrated ownership — top contributor handles 73% of recent commits
• ⚠ No CI workflows detected
• ⚠ No test directory 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 yanzhenjie/SwipeRecyclerView repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/yanzhenjie/SwipeRecyclerView.

What it runs against: a local clone of yanzhenjie/SwipeRecyclerView — 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 yanzhenjie/SwipeRecyclerView | 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 ≤ 677 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "yanzhenjie/SwipeRecyclerView(\\.git)?\\b" \\
  && ok "origin remote is yanzhenjie/SwipeRecyclerView" \\
  || miss "origin remote is not yanzhenjie/SwipeRecyclerView (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 "support/src/main/java/com/yanzhenjie/recyclerview/SwipeRecyclerView.java" \\
  && ok "support/src/main/java/com/yanzhenjie/recyclerview/SwipeRecyclerView.java" \\
  || miss "missing critical file: support/src/main/java/com/yanzhenjie/recyclerview/SwipeRecyclerView.java"
test -f "support/src/main/java/com/yanzhenjie/recyclerview/SwipeMenuLayout.java" \\
  && ok "support/src/main/java/com/yanzhenjie/recyclerview/SwipeMenuLayout.java" \\
  || miss "missing critical file: support/src/main/java/com/yanzhenjie/recyclerview/SwipeMenuLayout.java"
test -f "support/src/main/java/com/yanzhenjie/recyclerview/AdapterWrapper.java" \\
  && ok "support/src/main/java/com/yanzhenjie/recyclerview/AdapterWrapper.java" \\
  || miss "missing critical file: support/src/main/java/com/yanzhenjie/recyclerview/AdapterWrapper.java"
test -f "support/src/main/java/com/yanzhenjie/recyclerview/touch/ItemTouchHelperCallback.java" \\
  && ok "support/src/main/java/com/yanzhenjie/recyclerview/touch/ItemTouchHelperCallback.java" \\
  || miss "missing critical file: support/src/main/java/com/yanzhenjie/recyclerview/touch/ItemTouchHelperCallback.java"
test -f "support/src/main/java/com/yanzhenjie/recyclerview/ExpandableAdapter.java" \\
  && ok "support/src/main/java/com/yanzhenjie/recyclerview/ExpandableAdapter.java" \\
  || miss "missing critical file: support/src/main/java/com/yanzhenjie/recyclerview/ExpandableAdapter.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 677 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~647d)"
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/yanzhenjie/SwipeRecyclerView"
  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).

SwipeRecyclerView is an Android RecyclerView wrapper that adds side-swipe menus, drag-to-reorder items, swipe-to-delete, auto-load-more, sticky headers, and HeaderView/FooterView support. It extends RecyclerView with zero API changes—use it as a drop-in replacement with extra methods for swipe menus, touch dragging, and grouping layouts. Single-module library: support/ contains the core implementation under support/src/main/java/com/yanzhenjie/recyclerview/, with subpackages for touch handling (touch/), widgets (widget/), and core components (SwipeRecyclerView, SwipeMenu, SwipeMenuLayout). No separate x/ module visible; build.gradle suggests dual-output configuration from single source.

Android app developers building list-based UIs who need swipe gestures and interactive item behaviors (side menus, drag-reorder, delete) without building from scratch. Particularly those maintaining apps targeting both AndroidX and legacy Support libraries.

Actively maintained with version 1.3.2 supporting AndroidX (v1.3.0+), 627KB of Java code, and README documentation. Repository shows intentional dual-lib structure (support/ module for both Support and AndroidX variants). No visible CI pipeline or test suite in file list suggests moderate maturity—feature-complete but missing automated testing infrastructure.

Single-maintainer (yanzhenjie) with no visible GitHub Actions or test coverage in the file structure. No open-issue/PR data provided, but the dual-library maintenance burden (support + AndroidX) means a single architectural change requires updates in parallel. Android SDK version constraints not visible in build.gradle snippet. Breaking changes documented at v1.3.0 (package/class name changes).

No commit history visible in provided data. Library appears stable at v1.3.2 with completed features (swipe menus, drag-reorder, sticky headers, load-more). No active development signals detected; focus seems to be on maintenance and compatibility rather than new features.

git clone https://github.com/yanzhenjie/SwipeRecyclerView.git
cd SwipeRecyclerView
./gradlew build
# or on Windows: gradlew.bat build

Then add to your app's build.gradle: implementation 'com.yanzhenjie.recyclerview:support:1.3.2' (for AndroidX use x:1.3.2).

Daily commands: This is a library, not an app. To test in IDE: ./gradlew assembleDebug builds the .aar. For a runnable demo, check for a separate demo/ or app/ module (not listed in top 60 files). To include in your project, add to build.gradle and instantiate SwipeRecyclerView in layout XML, then configure via code (see README examples for setSwipeMenuCreator, setOnItemClickListener).

• support/src/main/java/com/yanzhenjie/recyclerview/SwipeRecyclerView.java — Main entry point and public API—extends RecyclerView with swipe menu, drag, and load-more capabilities; all contributors must understand how this class orchestrates the library's features
• support/src/main/java/com/yanzhenjie/recyclerview/SwipeMenuLayout.java — Core layout container for swipe menu rendering and touch gesture handling; critical for understanding how horizontal swiping and menu animation work
• support/src/main/java/com/yanzhenjie/recyclerview/AdapterWrapper.java — Wraps user adapter to inject header/footer/load-more views and manage item decoration; essential for understanding item lifecycle and view management
• support/src/main/java/com/yanzhenjie/recyclerview/touch/ItemTouchHelperCallback.java — Implements drag-and-drop and swipe-delete logic via ItemTouchHelper callback; fundamental to gesture recognition and item movement
• support/src/main/java/com/yanzhenjie/recyclerview/ExpandableAdapter.java — Handles grouped/expandable item lists (sticky headers); required for understanding nested list and grouping behavior
• support/src/main/java/com/yanzhenjie/recyclerview/SwipeMenuCreator.java — Interface for menu creation and item-specific menu customization; defines the contract for building swipe menus per item
• support/build.gradle — Library build configuration with AndroidX support and resource declarations; necessary for building and packaging the library

Add a Swipe Menu to Your RecyclerView

1. In your Activity/Fragment, use SwipeRecyclerView instead of RecyclerView (support/src/main/java/com/yanzhenjie/recyclerview/SwipeRecyclerView.java)
2. Create a SwipeMenuCreator implementation to define menu items per position (support/src/main/java/com/yanzhenjie/recyclerview/SwipeMenuCreator.java)
3. Call swipeRecyclerView.setSwipeMenuCreator(creator) to attach the menu creator (support/src/main/java/com/yanzhenjie/recyclerview/SwipeRecyclerView.java)
4. Implement OnItemMenuClickListener and pass to swipeRecyclerView.setOnItemMenuClickListener() to handle menu clicks (support/src/main/java/com/yanzhenjie/recyclerview/OnItemMenuClickListener.java)
5. Reference sample implementation in ListActivity (supportSample/src/main/java/com/yanzhenjie/recyclerview/sample/activity/menu/ListActivity.java)

Enable Drag-and-Drop and Swipe-to-Delete

1. Create an OnItemMoveListener to track drag movements (support/src/main/java/com/yanzhenjie/recyclerview/touch/OnItemMoveListener.java)
2. Create an OnItemStateChangedListener to detect state changes (selected, idle) (support/src/main/java/com/yanzhenjie/recyclerview/touch/OnItemStateChangedListener.java)
3. Call swipeRecyclerView.setItemViewSwipeEnabled(true) to enable swipe-delete (support/src/main/java/com/yanzhenjie/recyclerview/SwipeRecyclerView.java)
4. Call swipeRecyclerView.setLongPressDragEnabled(true) to enable drag on long-press (support/src/main/java/com/yanzhenjie/recyclerview/SwipeRecyclerView.java)
5. Attach listeners and view reference implementation in sample move activity (supportSample/src/main/java/com/yanzhenjie/recyclerview/sample/activity/move)

Add Header, Footer, and Load-More Views

1. Call swipeRecyclerView.addHeaderView(headerView) to inject a sticky header (support/src/main/java/com/yanzhenjie/recyclerview/SwipeRecyclerView.java)

1. Swipe menus close automatically when items are deleted—ensure your data update triggers a notifyItemRemoved() before the animation completes, or menus won't visually sync. 2. LayoutManager type (Linear vs Grid vs Staggered) is not auto-detected; you must setLayoutManager() before attaching adapter, or drag-reorder may misbehave. 3. HeaderView/FooterView positions shift when data is filtered—no built-in sticky-header logic for filtered lists; use ExpandableAdapter or implement custom decoration. 4. Side-swipe gestures can conflict with DrawerLayout—README notes this but mitigation requires careful gesture handler configuration.

• ItemTouchHelper callback pattern — SwipeRecyclerView's drag-reorder and swipe-delete rely on ItemTouchHelper.Callback; understanding onMove(), onSwiped(), and isLongPressDragEnabled() is essential to extending gesture behavior
• LayoutManager abstraction — SwipeRecyclerView supports Linear, Grid, and Staggered layouts; LayoutManager choice affects drag-reorder animation and swipe menu reveal calculations
• GestureDetector and touch event interception — Side-swipe menus detect horizontal motion via touch events; understanding MotionEvent routing and VelocityTracker is critical to avoiding gesture conflicts with DrawerLayout or nested scrollers
• Adapter decoration via wrapping — AdapterWrapper transparently injects header/footer rows and menu logic without requiring users to extend their adapter; this is a composition-over-inheritance pattern unique to this library's design
• RecyclerView ViewType filtering — BorderItemDecoration and menu logic exclude certain ViewTypes (headers, footers) from dividers and gestures; getItemViewType() must be consistent with decoration exclusions
• Sticky header via ItemDecoration — SwipeRecyclerView supports sticky group headers without LayoutManager modifications; ItemDecoration onDraw() is used to overlay sticky headers, not direct layout changes
• Android Support vs AndroidX migration — This library maintains dual artifacts (support:1.3.2 and x:1.3.2) with identical source; understanding build-time artifact selection is critical to avoiding dependency conflicts

• jdamcd/android-swipeayout — Older Android swipe menu library; predates SwipeRecyclerView, less polished but similar core gesture handling
• BaseAdapter/BRVAH — Popular RecyclerView adapter wrapper for Android; shares the adapter-decoration pattern but focuses on list binding rather than gestures
• androidkotlin/loadmore — Specialized auto-load-more library; SwipeRecyclerView includes this feature but load-more is more modular in this repo
• CymChad/BaseRecyclerViewAdapterHelper — Another RecyclerView adapter helper with drag, swipe, and header support; direct competitor with richer animation options
• androidx/androidx — Official AndroidX library; SwipeRecyclerView targets androidx.recyclerview:recyclerview as base and must track API changes

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 SwipeMenuLayout and SwipeMenuView touch interaction

The core swipe menu functionality in support/src/main/java/com/yanzhenjie/recyclerview/SwipeMenuLayout.java and SwipeMenuView.java lacks unit tests. These are critical components that handle touch events and menu animations. Adding tests would ensure reliability across Android versions and prevent regressions when refactoring touch handling logic.

• [ ] Create support/src/test/java/com/yanzhenjie/recyclerview/ directory structure
• [ ] Add SwipeMenuLayoutTest.java to test menu open/close animations and boundary conditions
• [ ] Add SwipeMenuViewTest.java to test touch event handling and menu item clicks
• [ ] Test edge cases: rapid swipes, swipes while menu is open, menu item click interception
• [ ] Verify tests run with ./gradlew test

Add GitHub Actions CI workflow for automated testing and APK builds

The repo has no CI/CD configuration. Given the complexity of touch interactions, swipe gestures, and multi-version Android support, automated testing on each push would catch breaking changes early. This is especially important for a library that other developers depend on.

• [ ] Create .github/workflows/android-ci.yml
• [ ] Configure workflow to run: ./gradlew build on every push to main/develop branches
• [ ] Add instrumented tests step: ./gradlew connectedAndroidTest for the support module
• [ ] Add lint checks: ./gradlew lint to catch code quality issues
• [ ] Configure workflow to build both support library and supportSample demo app
• [ ] Add badge to README.md showing CI status

Add comprehensive Javadoc and code comments for public API in core swipe classes

Critical public classes like SwipeRecyclerView.java, SwipeMenuCreator.java, OnItemMenuClickListener.java, and Controller.java lack Javadoc documentation. New contributors cannot understand method purposes, parameters, or callback contracts. This is essential for a library meant to be reused by other developers.

• [ ] Add class-level Javadoc to SwipeRecyclerView.java explaining it's a RecyclerView wrapper with swipe capabilities
• [ ] Document all public methods in SwipeMenuCreator.java with @param and @return tags
• [ ] Add Javadoc to listener interfaces: OnItemMenuClickListener.java, OnItemClickListener.java, OnItemLongClickListener.java
• [ ] Document Controller.java methods: openMenu(), closeMenu(), closeAllMenu()
• [ ] Add inline comments explaining the touch event flow in Horizontal.java, LeftHorizontal.java, RightHorizontal.java
• [ ] Verify Javadoc generates cleanly with ./gradlew javadoc

• Add unit tests for ItemTouchHelperCallback: the touch/ package lacks test coverage. Create support/src/test/java/com/yanzhenjie/recyclerview/touch/ tests for drag, swipe-delete, and edge cases (empty list, single item, rapid gestures).
• Document SwipeMenuCreator callback parameters in code comments and add Javadoc to SwipeMenuCreator.onCreateMenu()—currently only shown in README examples, not in source comments. Add parameter descriptions for leftMenu, rightMenu, and position.
• Create a working demo Activity showing nested RecyclerViews (e.g., parent with swipe menus, child with drag-reorder) since README mentions 'second-level lists' but no example is visible in the file structure.

This Android RecyclerView library project has significant security concerns primarily related to outdated build tools and dependencies. The use of Android Gradle Plugin 3.3.2 (from 2019), deprecated Bintray publishing, and aging plugin versions creates exposure to known vulnerabilities. No immediate code-level injection risks are evident from the file structure, but the outdated toolchain poses build-time and supply-chain risks. The project requires urgent updates to build infrastructure. Missing visibility into config.gradle and manifest files prevents a complete assessment. Recommend: (1) Update all build tools and plugins to current versions, (2) Migrate from Bintray to Maven Central, (3) Implement dependency scanning in CI/CD, (4) Add security policy for dependency updates.

• High · Outdated Gradle Build Tools — build.gradle - classpath 'com.android.tools.build:gradle:3.3.2'. The project uses Android Gradle Plugin version 3.3.2, which was released in February 2019 and is significantly outdated. This version contains multiple known security vulnerabilities and lacks security patches. Current versions (7.x+) include critical security fixes for build-time attacks and dependency resolution. Fix: Update to the latest stable Android Gradle Plugin version (currently 8.1+). Review and update all Gradle wrapper files to match.
• High · Outdated Gradle Maven Plugin — build.gradle - classpath 'com.github.dcendents:android-maven-gradle-plugin:2.1'. The android-maven-gradle-plugin version 2.1 is outdated (released 2017). This plugin is used for publishing artifacts and may have unpatched security vulnerabilities in dependency handling. Fix: Upgrade to the latest version or consider using Maven Central publishing plugin. Verify the plugin's security advisory status before upgrading.
• Medium · Outdated Bintray Gradle Plugin — build.gradle - classpath 'com.jfrog.bintray.gradle:gradle-bintray-plugin:1.8.4'. The gradle-bintray-plugin version 1.8.4 (released 2019) is outdated. Bintray itself was sunset by JFrog in May 2021, and this plugin is no longer maintained. Using deprecated publishing infrastructure increases risk. Fix: Migrate to Maven Central Repository or alternative publishing solutions like GitHub Packages. Remove Bintray plugin if not actively used for publishing.
• Medium · Missing Dependency Version Pinning — build.gradle - 'apply from: "config.gradle"'. The build.gradle file references dependencies without explicit version constraints in config.gradle (which is applied but not shown). Dynamic or unspecified versions can lead to unexpected updates with potential vulnerabilities. Fix: Ensure all dependencies in config.gradle have explicit version pins. Implement dependency scanning tools (e.g., OWASP Dependency-Check) in CI/CD pipeline.
• Low · No ProGuard/R8 Rules for Library — support/proguard-rules.txt. While proguard-rules.txt exists, there's no evidence of obfuscation or shrinking rules being enforced for the library module. This could expose implementation details in the compiled artifact. Fix: Review and strengthen ProGuard/R8 configuration rules to ensure sensitive code paths are properly obfuscated in release builds.
• Low · Missing Security Manifest Permissions Review — support/src/main/AndroidManifest.xml, supportSample/src/main/AndroidManifest.xml. The AndroidManifest.xml files are present but their contents are not visible in this analysis. Android manifest should be reviewed to ensure only necessary permissions are declared. Fix: Review manifest files to ensure: minimal permission declarations, no debuggable flags in release builds, proper intent filter restrictions, and appropriate exported component declarations.

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.