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/jfeinstein10/SlidingMenu 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

• 18 active contributors
• Apache-2.0 licensed
• ⚠ Stale — last commit 5y ago
• ⚠ Concentrated ownership — top contributor handles 65% 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 jfeinstein10/SlidingMenu repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/jfeinstein10/SlidingMenu.

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

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "jfeinstein10/SlidingMenu(\\.git)?\\b" \\
  && ok "origin remote is jfeinstein10/SlidingMenu" \\
  || miss "origin remote is not jfeinstein10/SlidingMenu (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 "library/src/com/jeremyfeinstein/slidingmenu/lib/SlidingMenu.java" \\
  && ok "library/src/com/jeremyfeinstein/slidingmenu/lib/SlidingMenu.java" \\
  || miss "missing critical file: library/src/com/jeremyfeinstein/slidingmenu/lib/SlidingMenu.java"
test -f "library/src/com/jeremyfeinstein/slidingmenu/lib/SlidingMenuActivity.java" \\
  && ok "library/src/com/jeremyfeinstein/slidingmenu/lib/SlidingMenuActivity.java" \\
  || miss "missing critical file: library/src/com/jeremyfeinstein/slidingmenu/lib/SlidingMenuActivity.java"
test -f "example/src/com/jeremyfeinstein/slidingmenu/example/SlidingMenuActivity.java" \\
  && ok "example/src/com/jeremyfeinstein/slidingmenu/example/SlidingMenuActivity.java" \\
  || miss "missing critical file: example/src/com/jeremyfeinstein/slidingmenu/example/SlidingMenuActivity.java"
test -f "library/AndroidManifest.xml" \\
  && ok "library/AndroidManifest.xml" \\
  || miss "missing critical file: library/AndroidManifest.xml"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"

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

SlidingMenu is an Android library that implements slide-in navigation panels (behind-content menus) popularized by Google+, YouTube, and Facebook. It provides three integration patterns: programmatic attachment via SlidingMenu.attachToActivity(), Activity inheritance via SlidingActivity, and direct XML/programmatic view embedding. The core capability is smooth off-screen menu sliding with configurable behavior (SLIDING_WINDOW vs SLIDING_CONTENT) for both left and right menus. Single-module library + example structure: SlidingMenu/src/ contains core library code (ViewGroup implementations, attachment logic); example/ is a standalone Eclipse project demonstrating all three integration patterns; art/ holds marketing assets. No multi-module Maven structure visible despite parent POM reference. Build targets Groovy (725 bytes, likely Gradle scripts) alongside Java (141,908 bytes).

Android app developers building applications between 2010-2015 who need slide-out navigation UI without building custom ViewGroup animations. Specifically developers using Eclipse and ActionBarSherlock who want drop-in menu functionality compatible with legacy Android versions (API 4+, based on the project age).

This project is mature but dormant: it's production-ready (deployed in 16+ high-profile apps listed in README including Foursquare, LinkedIn, Evernote Food), but shows signs of age—the last visible activity marker is the example/ directory structure suggesting pre-Android Studio era (Eclipse .classpath, Crittercism 3.0.3 SDK). No visible CI configuration (no .travis.yml, GitHub Actions) and version is 1.3-SNAPSHOT suggest active maintenance ended around 2013-2015.

High technical debt risk: (1) No visible test suite (no test/ or androidTest/ directories), (2) Direct dependency on ActionBarSherlock (deprecated; last release 2013), (3) No CI/CD pipeline visible, (4) Single maintainer (jfeinstein10) with no commit recency data provided, (5) Target API level unknown but example uses Crittercism v3.0.3 (extremely outdated). Not suitable for new greenfield projects; legacy maintenance risk for existing implementations.

No active development visible from provided data. The repository appears frozen post-v1.3-SNAPSHOT. The inclusion of Groovy hints at a migration attempt toward Gradle, but completion status is unknown. No PR, issue, or milestone data provided—assume no ongoing work.

git clone https://github.com/jfeinstein10/SlidingMenu.git
cd SlidingMenu
# Eclipse: Import as Android library project (Project > Clean to generate R.java)
# Or for Maven: mvn clean install
# For example app: Import example/ folder into Eclipse workspace

Note: Requires Eclipse + Android SDK setup or Maven with android-maven-plugin configured.

Daily commands: Eclipse workflow: (1) Right-click project → Android Tools → Fix Project Properties, (2) Project → Clean to generate R.java, (3) Run as → Android Application. Maven: mvn clean install android:deploy android:run. No dev server—this is a UI library; runtime happens within Android emulator or connected device.

• library/src/com/jeremyfeinstein/slidingmenu/lib/SlidingMenu.java — Core SlidingMenu class that manages the slide-in menu behavior, animations, and user interactions—entry point for all menu functionality.
• library/src/com/jeremyfeinstein/slidingmenu/lib/SlidingMenuActivity.java — Base Activity class that developers extend to integrate SlidingMenu—demonstrates the primary integration pattern.
• example/src/com/jeremyfeinstein/slidingmenu/example/SlidingMenuActivity.java — Example Activity showing how to configure and use SlidingMenu with real-world patterns.
• library/AndroidManifest.xml — Library manifest declaring the core SlidingMenu components and required Android permissions.
• README.md — Project overview, setup instructions, and integration guide that all developers must follow before using this library.
• LICENSE.txt — Open-source license terms that must be cited and included in any app using this library.

• SlidingMenu (Android ViewGroup, Scroller, GestureDetector) — Central ViewGroup that manages menu position, animations, touch events, and applies transformations to content; acts as orchestrator for all sliding behavior
  • Failure mode: Menu fails to respond to touch, animations stutter, or content layout not visible—usually due to incorrect setMenu/setContent calls or layout conflicts
• SlidingMenuActivity (Android Activity, SlidingMenu) — Base Activity class that wraps SlidingMenu integration, lifecycle management, and provides convenient API for developers to configure menu behavior
  • Failure mode: Activity crashes on rotation, menu state lost, or menu appears unresponsive if lifecycle methods not properly called
• Scroller (Android Scroller API) — Manages animation curves and timing for menu slide transitions; decouples animation logic from view rendering
  • Failure mode: Animations appear jerky, animation duration ignored, or menu position overshoots—usually animation config errors
• CustomViewAbove (Android ViewGroup) — Custom ViewGroup wrapper for the main content area that supports position transforms and shadow effects when menu slides behind
  • Failure mode: Content layout not properly constrained, shadow not visible, or touch events not passed through correctly

• User input (touch event) → SlidingMenu.onTouchEvent() — Touch events dispatched to menu ViewGroup for gesture recognition
• SlidingMenu.onTouchEvent() → Scroller.startScroll() — Menu detects swipe and initiates smooth animation via Scroller
• Scroller animation loop → SlidingMenu.computeScroll() — Scroller updates position each frame; menu queries current position and invalidates to redraw
• SlidingMenu internal layout → CustomViewAbove + menu layout — Menu positions content and menu child views based on animation progress and configuration
• SlidingMenuActivity.onCreate() → SlidingMenu configuration — Activity initializes menu width, mode, shadow, and callback listeners during setup

Add SlidingMenu to a new Activity

1. Extend SlidingMenuActivity instead of Activity (library/src/com/jeremyfeinstein/slidingmenu/lib/SlidingMenuActivity.java)
2. Call getSlidingMenu() in onCreate() to configure menu behavior (left/right, width, animations) (example/src/com/jeremyfeinstein/slidingmenu/example/SlidingMenuActivity.java)
3. Inflate your menu layout via setMenu() and main content layout via setContentView() (example/res/layout/menu.xml)

Customize menu appearance and animations

1. Configure menu width, shadow, mode (left/right/both), and offsets in getSlidingMenu() (example/src/com/jeremyfeinstein/slidingmenu/example/SlidingMenuActivity.java)
2. Pass custom Scroller or animation settings to control sliding speed and easing (library/src/com/jeremyfeinstein/slidingmenu/lib/Scroller.java)
3. Define menu shadows and visual effects in drawable resources (example/res/drawable/shadow.xml)

Handle menu open/close events and navigation

1. Register SlidingMenu.OnOpenedListener or OnClosedListener callbacks (library/src/com/jeremyfeinstein/slidingmenu/lib/SlidingMenu.java)
2. Listen for menu item clicks in your menu layout fragment or view (example/res/layout/menu.xml)
3. Call getSlidingMenu().toggle() or showMenu()/hideMenu() to control menu visibility (example/src/com/jeremyfeinstein/slidingmenu/example/SlidingMenuActivity.java)

• Android ViewGroup/Custom View hierarchy — Provides low-level control over layout, touch events, and animations needed for smooth sliding menu transitions without heavyweight frameworks
• Scroller (android.widget.Scroller) — Enables smooth, physics-based animation curves for slide-in/out transitions with configurable duration and easing
• Activity/Fragment lifecycle integration — Ensures menu state and animations survive configuration changes and integrate seamlessly with Android's lifecycle model

• Custom ViewGroup instead of FragmentTransaction animations

  • Why: Provides finer control over touch handling, shadow effects, and per-frame customization
  • Consequence: More low-level code to maintain; developers must carefully integrate lifecycle to avoid memory leaks

• Single SlidingMenu instance per Activity

  • Why: Simplifies state management and ensures consistent animations across the activity
  • Consequence: Cannot have multiple independent sliding menus in a single Activity without custom modifications

• No built-in dependency injection or module system

  • Why: Keeps the library lightweight and easy to integrate without external frameworks
  • Consequence: Developers must manually manage menu/content fragment references and communicate via interfaces

• Does not provide real-time menu content updates or data binding—menu is static once set
• Does not include navigation drawer or Material Design components—pre-dates modern Android UI frameworks
• Does not support nested or multi-level sliding menus
• Does not handle authorization or permission integration beyond standard Android permissions

• Direct ViewGroup manipulation without lifecycle awareness (High) — SlidingMenu.java (touch event handling and animation loop): Menu state updates and animations may continue after Activity destroyed if callbacks not properly unregistered; no automatic cleanup on configuration change
• Hardcoded animation durations and distances — SlidingMenu.java (setMenu, computeScroll): Animation timing and menu width are configurable but rely on developer correctly calling setter

(1) ActionBarSherlock coupling: If you extend SlidingSherlockActivity, you must add ActionBarSherlock as a library dependency AND import it into Eclipse workspace—Maven alone is insufficient. (2) View lifecycle timing: attachToActivity() must be called in onCreate() before any view inflation; calling it post-inflation causes layout corruption. (3) Eclipse-only: All build scripts assume Eclipse ADT; Gradle migration is incomplete (Groovy files present but unclear status). (4) No resource conflicts: SlidingMenu uses its own R.* references; embedding in projects with conflicting menu resources requires manual layout XML editing. (5) Fragment support: If using Fragments with behind-content views, you must manually manage their lifecycle—the library does not auto-destroy fragments when menu is attached.

• ViewGroup composition and nested layout hierarchy — SlidingMenu's core is a custom ViewGroup that manages multiple child views (behind, content, menu) and routes touch/draw calls between them; understanding ViewGroup.onMeasure() and onLayout() is essential to modifying animation or size behavior.
• Scroller and VelocityTracker (Android animation primitives) — SlidingMenu uses Scroller to animate menu reveal/hide and VelocityTracker to detect fling gestures; reading the source reveals how frame-by-frame View.computeScroll() produces smooth 60fps animations on pre-honeycomb Android.
• GestureDetector and OnTouchListener event routing — The library intercepts and consumes touch events to detect swipes/drags that trigger menu sliding; understanding event.getAction() and requestDisallowInterceptTouchEvent() is critical to debugging input conflicts.
• Activity window attachment and DecorView replacement — The attachToActivity() pattern works by replacing the Activity's root DecorView with SlidingMenu itself, then re-parenting the original content; this is an advanced pattern that breaks if not timed correctly in onCreate().
• ActionBar integration and compatibility libraries (pre-AndroidX) — SlidingMenu's Sherlock variants depend on ActionBarSherlock's backport of ActionBar to Android 2.1+; understanding the difference between SLIDING_WINDOW (includes ActionBar) and SLIDING_CONTENT (excludes it) requires knowing ActionBar lifecycle.
• Eclipse ADT build system and manifest merge (pre-Gradle) — The project uses Eclipse's legacy build system with manual R.java generation; modern developers unfamiliar with pre-Gradle Android should understand why .classpath files exist and why Project > Clean is necessary.
• Fragment back-stack management and Activity result callbacks — SlidingMenu can contain Fragments, but the library does not manage their lifecycle automatically; developers must manually handle Fragment transactions and Activity.onActivityResult() when using menu-driven navigation.

• mikepenz/MaterialDrawer — Modern (2020s) successor for Android slide-out navigation using Material Design; drop-in replacement for SlidingMenu with Kotlin support and AndroidX compatibility
• chrisbanes/ActionBarSherlock — Direct dependency of SlidingMenu's Sherlock variants; required for backward-compatible ActionBar integration on Android 2.x-3.x devices
• google/material-components-android — Modern Material Design navigation patterns (NavigationView, BottomNavigationView) that replace SlidingMenu's slide-out UX in current Android ecosystem
• JakeWharton/ActionBarSherlock — Alternative ActionBarSherlock fork with community maintenance after original was deprecated
• roboguice/roboguice — Dependency injection library frequently paired with SlidingMenu in legacy Android apps (ca. 2012-2013) for Activity/Fragment management

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.

Remove Windows-specific Thumbs.db files and add to .gitignore

The repository currently contains multiple Thumbs.db files across art/Blue, art/Green, art/Orange, art/Red, and art/White directories. These are Windows thumbnail cache files that should never be version controlled. This cleanup will reduce repo size and prevent accidental commits of system files by future contributors.

• [ ] Add 'Thumbs.db' entry to .gitignore
• [ ] Remove all Thumbs.db files from art/*/Thumbs.db using 'git rm --cached'
• [ ] Verify .gitignore now prevents future Thumbs.db commits
• [ ] Add similar OS-specific entries (.DS_Store for macOS, .directory for Linux)

Complete and fix the truncated README.md and add CONTRIBUTING.md

The README.md snippet shows the text abruptly cuts off mid-sentence ('Also, you can follow th'). Additionally, there is no CONTRIBUTING.md file, which is critical for an open source library used by major apps (Foursquare, LinkedIn, Evernote, etc.). This would guide new contributors on the PR process, code style, and testing requirements.

• [ ] Complete the README.md by restoring the full text and fixing the truncation after 'Also, you can follow th'
• [ ] Create CONTRIBUTING.md with sections for: Setup Instructions, Code Style Guidelines, Testing Requirements, and PR Submission Process
• [ ] Reference the SlidingMenu library structure and example app in setup instructions
• [ ] Document how to test changes against the example application in example/

Add ProGuard configuration rules to library and document obfuscation in README

The example app contains ProGuard output files (dump.txt, mapping.txt, seeds.txt, usage.txt) in example/proguard/, indicating ProGuard/R8 is being used, but there's no explicit ProGuard rules file (proguard-rules.pro) committed to the library core. This is essential for library users to properly obfuscate their apps without breaking SlidingMenu functionality. The maps-support module is particularly at risk.

• [ ] Create SlidingMenu/proguard-rules.pro with rules to keep public SlidingMenu classes and view constructors (required for inflation)
• [ ] Create SlidingMenu-maps-support/proguard-rules.pro with rules for Google Maps integration
• [ ] Document in README.md the ProGuard configuration and how to include these rules in consumer apps
• [ ] Add -keep rules for reflection-based method calls and SlidingMenu callbacks

• Add JUnit test suite: No test/ directory exists. Create unit tests for SlidingMenu touch event handling, animation frame calculations, and view lifecycle in test/com/jeremyfeinstein/slidingmenu/lib/SlidingMenuTest.java. Start with testing the setOffsetBehind(int) and setScrollScale(float) setter methods.
• Document API compatibility table: Create a CSV/table in README.md listing which integration pattern (Attach/Inherit/Embed) works with ActionBar vs ActionBarSherlock vs AppCompat, and minimum API level for each. Currently users must infer this from example code.
• Update deprecated Crittercism SDK: Replace example/libs/crittercism_v3_0_3_sdkonly.jar (2010s-era crash reporting) with modern Firebase Crashlytics or document removal. Provides good practice for dependency auditing without breaking the library itself.

The SlidingMenu library has moderate security concerns primarily related to outdated and unmaintained dependencies. The most critical issue is the use of the deprecated Google Android Maps API v1 instead of the modern Google Play Services Maps v2. The project also lacks explicit version pinning for dependencies and uses SNAPSHOT versions for what appears to be a production library. The core library code structure appears clean with no obvious injection vulnerabilities or hardcoded credentials visible. Recommendations focus on dependency updates, version management, and housekeeping of example application artifacts.

• High · Outdated Maven Dependency - Google Android Maps — pom.xml - dependency: com.google.android.maps:maps. The pom.xml references 'com.google.android.maps:maps' without specifying a version. This dependency is deprecated and no longer maintained by Google. The Google Maps Android API v2 should be used instead. Using outdated maps library may expose the application to known security vulnerabilities and compatibility issues. Fix: Migrate to Google Play Services Maps (com.google.android.gms:play-services-maps) which receives regular security updates. Remove the deprecated Google Maps v1 dependency.
• Medium · SNAPSHOT Version in Production Build — pom.xml - version: 1.3-SNAPSHOT. The project uses version '1.3-SNAPSHOT' which indicates development/unstable code. SNAPSHOT versions can change without notice and may contain untested or experimental features. This is inappropriate for production releases. Fix: Use stable release versions (e.g., 1.3) for production builds. Reserve SNAPSHOT versions for development branches only.
• Medium · Missing Dependency Version Management — pom.xml - dependencies without explicit versions. The pom.xml does not specify explicit versions for several dependencies (slidingmenu, maps). This relies on parent POM version management which may not be transparent and could lead to unexpected version conflicts or security patches being missed. Fix: Define explicit versions for all dependencies or use a centralized dependencyManagement section. Regularly audit and update dependencies to patch security vulnerabilities.
• Low · Third-party Crash Reporting Library in Example — example/libs/crittercism_v3_0_3_sdkonly.jar. The example application includes 'crittercism_v3_0_3_sdkonly.jar' - an outdated version of a crash reporting service (v3.0.3 is very old). While this is only in the example and not the core library, it demonstrates outdated dependency practices. Fix: Update to the latest version of the crash reporting library or remove if no longer needed. Keep example applications updated to demonstrate security best practices.
• Low · ProGuard Artifacts Committed to Repository — example/proguard/ directory files. ProGuard configuration artifacts (dump.txt, mapping.txt, seeds.txt, usage.txt) are committed to version control. While not sensitive data, these provide information about the application's structure that could aid reverse engineering. Fix: Add ProGuard output files to .gitignore. Commit only proguard.cfg configuration file, not the generated output artifacts.

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.