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/daimajia/AndroidSwipeLayout 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

• 17 active contributors
• Distributed ownership (top contributor 42% of recent commits)
• MIT licensed
• CI configured
• ⚠ Stale — last commit 2y ago
• ⚠ 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 daimajia/AndroidSwipeLayout repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/daimajia/AndroidSwipeLayout.

What it runs against: a local clone of daimajia/AndroidSwipeLayout — 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 daimajia/AndroidSwipeLayout | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | 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 ≤ 940 days ago | Catches sudden abandonment since generation |

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

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT 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 "library/src/main/java/com/daimajia/swipe/SwipeLayout.java" \\
  && ok "library/src/main/java/com/daimajia/swipe/SwipeLayout.java" \\
  || miss "missing critical file: library/src/main/java/com/daimajia/swipe/SwipeLayout.java"
test -f "library/src/main/java/com/daimajia/swipe/adapters/BaseSwipeAdapter.java" \\
  && ok "library/src/main/java/com/daimajia/swipe/adapters/BaseSwipeAdapter.java" \\
  || miss "missing critical file: library/src/main/java/com/daimajia/swipe/adapters/BaseSwipeAdapter.java"
test -f "library/src/main/java/com/daimajia/swipe/implments/SwipeItemMangerImpl.java" \\
  && ok "library/src/main/java/com/daimajia/swipe/implments/SwipeItemMangerImpl.java" \\
  || miss "missing critical file: library/src/main/java/com/daimajia/swipe/implments/SwipeItemMangerImpl.java"
test -f "library/src/main/java/com/daimajia/swipe/interfaces/SwipeAdapterInterface.java" \\
  && ok "library/src/main/java/com/daimajia/swipe/interfaces/SwipeAdapterInterface.java" \\
  || miss "missing critical file: library/src/main/java/com/daimajia/swipe/interfaces/SwipeAdapterInterface.java"
test -f "library/src/main/res/values/attrs.xml" \\
  && ok "library/src/main/res/values/attrs.xml" \\
  || miss "missing critical file: library/src/main/res/values/attrs.xml"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 940 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~910d)"
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/daimajia/AndroidSwipeLayout"
  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).

AndroidSwipeLayout is a reusable Android ViewGroup component that enables swipe-to-reveal gestures (like swiping left to delete) on any container—ListView, GridView, RecyclerView, or plain ViewGroup. It handles complex touch mechanics automatically, fires lifecycle callbacks (onOpen, onClose, onUpdate), notifies hidden children of visibility progress, and supports nested swipe layers. Standard Android library module: the core SwipeLayout ViewGroup logic lives in library/src/main/java; demo/ provides executable examples (ListViewExample.java, GridViewExample.java, RecyclerViewExample.java, NestedExample.java) showing integration patterns; demo/src/main/res/layout contains XML templates for swipeable item layouts (listview_item.xml, recyclerview_item.xml, complicate_layout.xml for nested cases).

Android app developers building list-based UIs who need swipe-to-action patterns (delete, archive, flag items) without managing touch event routing and state manually. Particularly useful for teams integrating SwipeLayout into existing ListViewAdapter or RecyclerViewAdapter implementations.

Mature but inactive: the library reached v1.2.0 and was production-ready circa 2014–2016, with Travis CI integration. However, there are no recent commits visible in the provided data, no active issue/PR tracking documented, and no evidence of updates for modern Android (AndroidX, Jetpack). The codebase is stable but should be considered legacy-maintained.

Single-maintainer risk (daimajia) with no recent activity; no test suite evident in file list. Relies on support-v4 and recyclerview-v7 libraries pinned to 2014–2015 era versions (support-v4:20.+, recyclerview-v7:21.0.0), which may conflict with modern Android projects expecting AndroidX. Breaking changes to Android touch APIs post-API 21 are unlikely to be addressed.

No active development visible from provided metadata. The repository appears to be in maintenance mode or archived; no CI job results, recent commits, or open PRs are documented.

git clone https://github.com/daimajia/AndroidSwipeLayout.git && cd AndroidSwipeLayout && ./gradlew build. Then open demo/build.gradle in Android Studio or run ./gradlew :demo:installDebug to deploy the demo APK to an emulator/device.

Daily commands: ./gradlew :demo:assembleDebug to build APK; ./gradlew :demo:installDebug to deploy to connected device/emulator. Alternatively, import into Android Studio (File > Open) and click Run.

• library/src/main/java/com/daimajia/swipe/SwipeLayout.java — Core swipe gesture detection and animation logic; every contributor must understand the touch event handling and layout measurement system that powers the library
• library/src/main/java/com/daimajia/swipe/adapters/BaseSwipeAdapter.java — Abstract base for all swipe-enabled adapters (ListView, GridView, RecyclerView); required foundation for understanding how swipe state is managed across different list implementations
• library/src/main/java/com/daimajia/swipe/implments/SwipeItemMangerImpl.java — Central state manager for tracking open/closed swipe items across list views; critical for preventing multiple items open simultaneously and coordinating swipe behavior
• library/src/main/java/com/daimajia/swipe/interfaces/SwipeAdapterInterface.java — Contract that all swipe adapters must implement; defines the public API and expected behavior for item opening, closing, and state queries
• library/src/main/res/values/attrs.xml — XML attribute definitions for SwipeLayout customization (direction, edge, mode); required for understanding user-facing configuration options
• library/build.gradle — Library-specific build configuration, dependencies, and artifact publishing setup; needed for build modifications and release process

Add a new swipe-enabled list view

1. Create a new Activity extending from demo activities (e.g., ListViewExample.java) (demo/src/main/java/com/daimajia/swipedemo/MyActivity.java)
2. Create a layout XML with SwipeLayout wrapping your item content (demo/src/main/res/layout/sample1.xml)
3. Extend ArraySwipeAdapter or BaseSwipeAdapter and override getView/onBindViewHolder (demo/src/main/java/com/daimajia/swipedemo/adapter/ListViewAdapter.java)
4. Initialize SwipeLayout attributes (direction, edge) in adapter item creation (library/src/main/java/com/daimajia/swipe/util/Attributes.java)

Customize swipe behavior per item

1. In your adapter's getView/onBindViewHolder, get the SwipeLayout instance from the item view (demo/src/main/java/com/daimajia/swipedemo/adapter/ListViewAdapter.java)
2. Call SwipeLayout.setSwipeDirection(), setDragEdge(), or setClickToClose() to override defaults (library/src/main/java/com/daimajia/swipe/SwipeLayout.java)
3. Attach a SimpleSwipeListener or custom SwipeListener to handle open/close events (library/src/main/java/com/daimajia/swipe/SimpleSwipeListener.java)

Implement custom swipe adapter for new list type

1. Extend BaseSwipeAdapter and implement required abstract methods (getCount, getItem, getView/onBindViewHolder) (library/src/main/java/com/daimajia/swipe/adapters/BaseSwipeAdapter.java)
2. The adapter automatically inherits SwipeItemMangerInterface via BaseSwipeAdapter (library/src/main/java/com/daimajia/swipe/implments/SwipeItemMangerImpl.java)
3. Call mItemManger.openItem(position) or closeItem(position) in response to user actions (library/src/main/java/com/daimajia/swipe/adapters/BaseSwipeAdapter.java)

Configure swipe layout XML attributes

1. Add SwipeLayout to your item layout XML with desired attributes (demo/src/main/res/layout/listview_item.xml)
2. Reference attrs.xml to set swipeDirection (left/right/up/down), dragEdge, clickToClose (library/src/main/res/values/attrs.xml)
3. Position your action buttons/views as child views within SwipeLayout for reveal on swipe (demo/src/main/res/layout/sample1.xml)

• Custom ViewGroup (SwipeLayout) — Needed for fine-grained control over touch events, layout measurement, and child view positioning during drag; standard Views lack this flexibility
• Scroller/ValueAnimator — Provides smooth acceleration-based scrolling and spring-back animations for natural swipe feel
• Adapter pattern with interface segmentation — Abstracts swipe state management (SwipeItemMangerInterface) from list display (BaseSwipeAdapter) to support ListView, GridView, and RecyclerView
• XML attributes (attrs.xml) — Allows declarative configuration of swipe behavior (direction, edge, mode) in layouts without code changes

• Single open item per list (enforced by SwipeItemMangerImpl)

  • Why: Simpler UX and state management; prevents visual confusion with multiple open items
  • Consequence: Cannot show multiple swipeable items simultaneously; must close previous item to open new one

• Touch event handling at SwipeLayout level rather than adapter level

  • Why: Keeps gesture logic centralized and reusable across all list types
  • Consequence: Adapter must wrap items in SwipeLayout; adds one view layer to hierarchy

• Manual state management in BaseSwipeAdapter (no automatic RecyclerView diffing)

  • Why: Preserves open/closed state during list updates without losing user context
  • Consequence: Developers must call notifyItemChanged() carefully to avoid state conflicts during scrolling/recycling

• Multi-directional swipe (up/down/left/right simultaneously)
• Swipe animations with physics-based particle effects
• Real-time collaborative swipe state across devices
• Accessibility features (VoiceOver, TalkBack optimizations not documented)

No AndroidX migration; uses legacy support-v4 and recyclerview-v7 libraries. Gradle classpath uses android-maven-plugin v1.2 (outdated, consider migrating to maven-publish plugin). Touch event handling is tightly coupled to pre-API 21 Android behavior; projects targeting API 28+ may encounter unexpected behavior or conflicts with system gesture navigation. No proguard configuration for the library itself (only demo/proguard-rules.pro exists), requiring manual consumer configuration.

• Android Touch Event Dispatch (MotionEvent routing) — SwipeLayout must intercept and consume MotionEvent.ACTION_MOVE, ACTION_DOWN, ACTION_UP; mishandling event dispatch breaks scrolling and nested interactions—core to understanding why SwipeLayout exists.
• ViewGroup.onTouchEvent() and onInterceptTouchEvent() — SwipeLayout likely overrides both methods to detect horizontal swipe velocity and decide whether to consume events or pass to children; critical for nested behavior.
• Scroller / ValueAnimator for smooth reveal animations — Hidden action Views slide in smoothly via timed animation callbacks; SwipeLayout likely uses ValueAnimator.setDuration() and View.offsetLeftAndRight() or TranslationX property.
• Adapter pattern with ViewHolder recycling — SwipeLayout must coexist with ListView/RecyclerView's ViewHolder caching; swiped state must not leak across recycled Views. See RecyclerViewExample.java for proper binding.
• Gesture velocity detection and fling handling — Swiping should feel responsive; SwipeLayout likely uses VelocityTracker to detect fast swipes and auto-open/close drawers. Slow drags require manual threshold logic.
• Child View visibility propagation and Z-ordering — SwipeLayout must manage depth: foreground content View appears above hidden action View when closed, then slides away to reveal actions. Requires careful layout inflation order and elevation.
• Attribute inflation and XML layout parsing — SwipeLayout reads custom XML attributes (swipe direction, edge, duration) via AttributeSet; see demo/src/main/res/layout/listview_item.xml for correct attribute declarations and namespace.

• 47deg/android-swipelistview — Direct predecessor mentioned in README; ListView-only swipe library that AndroidSwipeLayout was designed to improve upon with broader container support and callback architecture.
• daimajia/AndroidViewHover — Sister library by same author; provides hover/popup effects on Views—complementary gesture-based interaction pattern often paired with SwipeLayout in production apps.
• YoKeyword/Fragmentation — Contemporary Android architecture library for Fragment/Activity management; often used alongside SwipeLayout in list-driven navigation patterns.
• square/seismic — Lightweight Android event bus for View lifecycle and gesture events; useful for decoupling SwipeLayout callback handlers from Adapters.
• JakeWharton/butterknife — View binding library that pairs well with SwipeLayout for reducing boilerplate in Adapter onBindViewHolder() and setting up swipe listeners on list items.

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 instrumented tests for SwipeLayout touch event handling

The repo lacks test coverage for core swipe detection and gesture handling logic. Looking at the demo activities (ListViewExample, GridViewExample, RecyclerViewExample, NestedExample), there are multiple complex swipe scenarios being demonstrated but no corresponding androidTest suite. Adding instrumented tests would validate touch event propagation, swipe direction detection, and nested view interaction - critical for a gesture library.

• [ ] Create demo/src/androidTest/java/com/daimajia/swipedemo/SwipeLayoutTouchTest.java for basic swipe gesture validation
• [ ] Add tests for nested swipe scenarios matching sample_nested_parent.xml layout
• [ ] Test ListView adapter swipe behavior matching ListViewAdapter.java implementation
• [ ] Verify RecyclerView swipe integration as shown in RecyclerViewExample.java

Migrate from Travis CI to GitHub Actions with Android-specific workflow

The repo uses .travis.yml (dated config with Gradle 2.3.0) but lacks a modern GitHub Actions workflow. The current setup doesn't leverage GitHub's native CI and likely has slow build times. A GitHub Actions workflow would provide faster feedback, better integration with the repo, and automatic caching of Gradle dependencies - especially important for Android projects.

• [ ] Create .github/workflows/android-build.yml with Android SDK setup, Gradle caching, and build verification steps
• [ ] Configure workflow to run on demo/src/main/* and library source changes
• [ ] Add APK build artifact generation and test reporting
• [ ] Remove or deprecate .travis.yml with migration notice in README

Add comprehensive Javadoc and usage documentation for SwipeLayout public API

The README shows a gif and high-level description but lacks API documentation. Developers using the library need to understand the public methods, listeners, and configuration options. The demo code hints at features (shown in sample1.xml, sample2.xml, sample3.xml layouts and corresponding adapters) but there's no centralized API reference. Adding structured Javadoc to the library source and an API.md guide would significantly improve usability.

• [ ] Add comprehensive Javadoc comments to core SwipeLayout class (referenced by all examples)
• [ ] Document SwipeListener interface and its callback methods used across demo adapters
• [ ] Create API.md documenting configuration options, common patterns (ListView, GridView, RecyclerView integration from demo examples)
• [ ] Add code examples linking to specific demo files (ListViewAdapter.java, RecyclerViewAdapter.java) showing proper listener setup

• Add unit/instrumentation tests: the repo has no test/ directory visible. Start by writing AndroidTest cases for SwipeLayout's onOpen/onClose callbacks in demo/src/androidTest, using ActivityTestRule to inflate demo layouts and simulate MotionEvent swipe sequences.
• Migrate demo dependencies to AndroidX: update demo/build.gradle to replace com.android.support:recyclerview-v7 with androidx.recyclerview:recyclerview and support-v4 with androidx.legacy:legacy-support-v4. Update imports in demo activities and adapters.
• Document the XML attributes and callback API: the README lacks formal attribute documentation (e.g., swipe direction, drag edge, animation duration). Add a USAGE.md or update README with a table of SwipeLayout XML attributes and Java listener methods, cross-referenced to complicate_layout.xml and NestedExample.java.

The AndroidSwipeLayout codebase has several significant security concerns, primarily related to outdated build infrastructure and deprecated repositories. The project uses a Gradle build tool from 2017 that no longer receives security updates, and relies on JCenter (which has been sunset) and JitPack for dependency resolution without integrity verification. There is no evidence of automated security scanning in the CI/CD pipeline. While the library itself appears to be focused on UI/layout functionality and doesn't expose obvious injection vectors or hardcoded credentials in the visible files, the dependency management and build infrastructure pose supply chain risks. Immediate action is needed to modernize the build system, migrate to maintained repositories, and implement security scanning practices.

• High · Outdated Gradle Build Tools — build.gradle - classpath 'com.android.tools.build:gradle:2.3.0'. The project uses gradle:2.3.0 (released March 2017), which is significantly outdated and no longer receives security updates. This version lacks critical security patches for build-time vulnerabilities and may have unpatched issues in dependency resolution. Fix: Update to the latest stable version of Android Gradle Plugin (currently 8.x). Ensure all build tools are kept current with security patches.
• High · Insecure Maven Repository Configuration — build.gradle - repositories configuration (jcenter() and jitpack.io). The project uses JCenter repository which was sunset by JFrog in 2021. JCenter no longer receives updates and may serve outdated or potentially compromised artifacts. Additionally, the JitPack repository lacks integrity verification mechanisms and could be a vector for supply chain attacks. Fix: Migrate to Maven Central (mavenCentral()) or Google's Maven Repository (google()). Remove JCenter and evaluate JitPack usage; if needed, pin specific versions and verify artifact checksums.
• Medium · Missing Dependency Version Pinning — build.gradle - dependencies section. The build.gradle files do not explicitly pin versions for transitive dependencies. This could lead to unexpected updates with breaking changes or security vulnerabilities being introduced silently. The android-maven-plugin:1.2 is also very old (2014). Fix: Use explicit version numbers (avoid '+' or latest) for all dependencies. Implement dependency locking with 'dependencyLocking' to ensure reproducible builds. Update android-maven-plugin to a maintained alternative.
• Medium · No Security Scanning in CI/CD Pipeline — .travis.yml and build process. The .travis.yml configuration is present but the README indicates it's used. There is no evidence of SAST (Static Application Security Testing), dependency scanning, or vulnerability detection in the CI/CD pipeline. Fix: Integrate security scanning tools such as Dependabot, Snyk, or OWASP Dependency-Check into the CI/CD pipeline. Enable automated scanning on each build.
• Medium · ProGuard Configuration May Be Incomplete — demo/proguard-rules.pro and library/proguard-rules.pro. The project includes proguard-rules.pro files but without visibility into their content, it's unclear if proper obfuscation and security rules are configured. Incomplete ProGuard rules can expose sensitive code and method signatures. Fix: Review ProGuard configurations to ensure sensitive classes are properly obfuscated. Include rules to prevent reverse engineering of critical components. Consider using R8 for modern builds.
• Low · No Explicit Security Policy — Repository root. There is no evidence of a SECURITY.md file or security policy documenting how security issues should be reported. This makes it difficult for security researchers to responsibly disclose vulnerabilities. Fix: Create a SECURITY.md file following GitHub's recommended format that outlines vulnerability reporting procedures and contact information.

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.