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/pedant/sweet-alert-dialog 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.

AVOID — Stale and unlicensed — last commit 5y ago

• 4 active contributors
• ⚠ Stale — last commit 5y ago
• ⚠ Small team — 4 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 95% of recent commits
• ⚠ No license — legally unclear to depend on
• ⚠ 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 pedant/sweet-alert-dialog repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/pedant/sweet-alert-dialog.

What it runs against: a local clone of pedant/sweet-alert-dialog — 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 pedant/sweet-alert-dialog | Confirms the artifact applies here, not a fork | | 2 | Default branch master exists | Catches branch renames | | 3 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 4 | Last commit ≤ 1741 days ago | Catches sudden abandonment since generation |

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

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

# 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/cn/pedant/SweetAlert/SweetAlertDialog.java" \\
  && ok "library/src/main/java/cn/pedant/SweetAlert/SweetAlertDialog.java" \\
  || miss "missing critical file: library/src/main/java/cn/pedant/SweetAlert/SweetAlertDialog.java"
test -f "library/src/main/res/layout/alert_dialog.xml" \\
  && ok "library/src/main/res/layout/alert_dialog.xml" \\
  || miss "missing critical file: library/src/main/res/layout/alert_dialog.xml"
test -f "library/src/main/java/cn/pedant/SweetAlert/SuccessTickView.java" \\
  && ok "library/src/main/java/cn/pedant/SweetAlert/SuccessTickView.java" \\
  || miss "missing critical file: library/src/main/java/cn/pedant/SweetAlert/SuccessTickView.java"
test -f "library/src/main/res/anim" \\
  && ok "library/src/main/res/anim" \\
  || miss "missing critical file: library/src/main/res/anim"
test -f "library/src/main/java/cn/pedant/SweetAlert/ProgressHelper.java" \\
  && ok "library/src/main/java/cn/pedant/SweetAlert/ProgressHelper.java" \\
  || miss "missing critical file: library/src/main/java/cn/pedant/SweetAlert/ProgressHelper.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 1741 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1711d)"
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/pedant/sweet-alert-dialog"
  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).

SweetAlertDialog is an Android library that ports the JavaScript SweetAlert UI pattern to Android, providing beautiful, customizable alert dialogs with animations and multiple display types (success, error, warning, progress). It replaces Android's default AlertDialog with a Material Design-inspired alternative featuring smooth transitions, drawable icons (success tick, error X, warning sign), and interactive progress indicators via ProgressHelper. Simple two-module structure: library/ contains the core SweetAlertDialog.java plus supporting classes (ProgressHelper, Rotate3dAnimation, SuccessTickView, OptAnimationLoader) in cn/pedant/SweetAlert/, with corresponding res/ drawables (error_center_x.xml, success_bow.xml, warning_sigh.xml) and animations (error_frame_in.xml, modal_in.xml). The sample/ module demonstrates usage patterns.

Android developers building consumer-facing apps who want polished, animated alert dialogs without building custom Views from scratch. Particularly useful for apps requiring user confirmations, progress feedback, or error/success messaging with a modern UI.

This is a stable, production-ready library at v1.3. Last activity appears to be from 2015–2016 era (buildToolsVersion 19.1.0, compileSdkVersion 21 suggest pre-Android 5.0 origin). No active CI/CD visible in file list, and the codebase is small (~40KB Java). It's mature but no longer actively maintained; safe to use in production but won't receive new features.

Single-maintainer (pedant org), minimal dependencies (no external deps listed in gradle.properties), and no test infrastructure visible. The library targets old SDK versions (compileSdkVersion 21 = Android 5.0), which may cause compatibility issues on modern Android 12+. No CI pipeline and no recent commits suggests low maintenance risk but also no rapid security fixes.

Based on file metadata, this project is not actively developed. No visible PRs, issues, or recent commits in the provided data. The codebase is in maintenance mode.

git clone https://github.com/pedant/sweet-alert-dialog.git && cd sweet-alert-dialog && ./gradlew build

Daily commands: ./gradlew assembleDebug (builds library AAR and sample APK). Run sample on emulator: ./gradlew sample:installDebug && adb shell am start -n com.example.sac/.MainActivity

• library/src/main/java/cn/pedant/SweetAlert/SweetAlertDialog.java — Core dialog class implementing all alert types, animations, and user interactions; entry point for the entire library
• library/src/main/res/layout/alert_dialog.xml — Main layout definition for the alert dialog UI; defines all views and their hierarchy
• library/src/main/java/cn/pedant/SweetAlert/SuccessTickView.java — Custom drawable for success checkmark animation; demonstrates custom animation pattern used throughout
• library/src/main/res/anim — Animation resource directory containing all entrance/exit animations that define the visual identity
• library/src/main/java/cn/pedant/SweetAlert/ProgressHelper.java — Manages progress animation rendering; critical for PROGRESS_TYPE dialogs
• sample/src/main/java/cn/pedant/SweetAlert/sample/SampleActivity.java — Demonstrates all dialog types and configurations; reference for implementing dialogs in applications

• SweetAlertDialog (Android Dialog, ObjectAnimator,) — Main orchestrator; manages dialog state, type switching, animation sequencing, button callbacks, and lifecycle

Add a new alert type/icon style

1. Add new type constant to SweetAlertDialog class (e.g., CUSTOM_TYPE = 5) (library/src/main/java/cn/pedant/SweetAlert/SweetAlertDialog.java)
2. Create custom drawable for the icon in drawable directory (library/src/main/res/drawable/custom_icon.xml)
3. Add color values for the new type (library/src/main/res/values/colors.xml)
4. Add type-specific animation sequence (library/src/main/res/anim/custom_animation.xml)
5. Implement setType() switch case and animation logic in SweetAlertDialog (library/src/main/java/cn/pedant/SweetAlert/SweetAlertDialog.java)
6. Add demo example in SampleActivity (sample/src/main/java/cn/pedant/SweetAlert/sample/SampleActivity.java)

Customize dialog appearance and theme

1. Modify color scheme in colors.xml for buttons and backgrounds (library/src/main/res/values/colors.xml)
2. Adjust dimensions (padding, margins, text sizes) in dimen.xml (library/src/main/res/values/dimen.xml)
3. Update button drawable shapes and gradients (library/src/main/res/drawable/blue_button_background.xml)
4. Modify dialog layout structure if needed (library/src/main/res/layout/alert_dialog.xml)
5. Update styles.xml theme attributes (library/src/main/res/values/styles.xml)

Add custom animation for dialog state transitions

1. Create new animation XML in anim directory (library/src/main/res/anim/custom_transition.xml)
2. Load animation in OptAnimationLoader or SweetAlertDialog (library/src/main/java/cn/pedant/SweetAlert/OptAnimationLoader.java)
3. Apply animation to specific view or type in setType() method (library/src/main/java/cn/pedant/SweetAlert/SweetAlertDialog.java)
4. Test animation in sample activity (sample/src/main/java/cn/pedant/SweetAlert/sample/SampleActivity.java)

• Android AnimationSet + ObjectAnimator — Enables smooth, composable animations for icon transformations and dialog entrance/exit without external dependencies
• Custom Drawable subclasses (SuccessTickView) — Provides lightweight, scalable vector animations without using WebView or heavy animation libraries
• XML resource-based animations — Decouples animation logic from Java code; allows designers to tweak timing/values without recompilation
• Android Dialog/DialogFragment base — Leverages native Android window management, lifecycle, and back-stack behavior without reimplementing

• Extends Dialog instead of DialogFragment

  • Why: Simpler API surface and easier to integrate with legacy Activities; less memory overhead
  • Consequence: Less lifecycle-aware than DialogFragment; potential memory leaks if not dismissed properly in activity lifecycle

• Hardcoded type constants (NORMAL, SUCCESS, ERROR, WARNING, PROGRESS) instead of fully extensible system

  • Why: Reduces complexity and ensures consistent UX across all dialog states; easier to maintain animations/colors
  • Consequence: Adding new types requires modifying core class; less suitable for highly customized use cases

• Single layout file (alert_dialog.xml) with visibility toggling for different types

  • Why: Minimizes layout inflation overhead; all views pre-created
  • Consequence: Memory footprint includes unused views for each dialog instance; harder to conditionally add views

• No dependencies on external animation/UI libraries

  • Why: Minimal APK size impact (~50KB); no transitive dependency conflicts
  • Consequence: Manual animation orchestration; cannot leverage mature animation frameworks like Lottie

• Does not provide real-time progress tracking (static progress drawable only)
• Does not support dialog nesting or multi-window scenarios
• Does not include accessibility features (no TalkBack support documented)
• Does not handle keyboard events or IME integration
• Not designed for non-blocking toast-like notifications
• Does not support dynamic theming at runtime (theme set at creation)

SweetAlertDialog extends Dialog directly (not DialogFragment), so lifecycle management in Fragments requires manual handling of show()/dismiss(). The progress spinner is a custom drawable animation layer (success_mask_layout.xml), not a standard ProgressBar—customization requires understanding Drawable animation XML. View IDs in alert_dialog.xml are hardcoded; renaming them breaks findViewById() calls in SweetAlertDialog.java. No nullability checks on context or callback listeners; passing null activity or unchecked OnSweetClickListener can crash.

• Property Animation (3D Rotation) — SweetAlertDialog uses Rotate3dAnimation and AnimationSet (error_frame_in.xml, success_bow_roate.xml) to animate dialog icons—understanding View animation timing and 3D transforms is core to maintaining/extending animations
• Drawable Animation Layer — The progress spinner and success bow are implemented as drawable resources (success_mask_layout.xml, success_bow.xml), not code—modifying animations requires editing AnimationDrawable XML
• Dialog Lifecycle & Window Tokens — SweetAlertDialog extends Dialog directly and manages show()/dismiss() without Fragment lifecycle—this can cause memory leaks if not properly managed in Activities/Fragments
• Custom View Canvas Drawing — SuccessTickView extends View and overrides onDraw(Canvas) to render animated checkmark paths—understanding Canvas operations and Path drawing is needed to modify the success animation
• Builder Pattern (Fluent API) — SweetAlertDialog uses method chaining (setTitleText().setContentText().show())—maintaining backward compatibility while adding new features requires careful builder design
• Layout Inflation & findViewById() — alert_dialog.xml is inflated and views are retrieved by ID—refactoring the layout risks breaking findViewById() calls scattered through SweetAlertDialog.java

• afollestad/material-dialogs — Drop-in replacement offering Material Design dialogs with more features, active maintenance, and Android 12+ support
• JakeWharton/DialogFragment — Best practices for dialog lifecycle management using DialogFragment pattern (SweetAlertDialog uses Dialog directly)
• pnikosis/materialish-progress — Source library for the progress spinner implementation used in PROGRESS_TYPE dialogs (credited in README)
• t32k/sweet-alert — Original JavaScript SweetAlert library that inspired this Android port

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.

Migrate Gradle build configuration to modern Android Gradle Plugin and dependency management

The repo uses outdated Gradle plugin (0.14.1 from 2014) and compileSdkVersion 21 (from 2015). This causes compatibility issues with modern Android tooling, prevents publishing to Maven Central with current standards, and blocks security updates. Modernizing to Android Gradle Plugin 7.x+, compileSdkVersion 34+, and using dependency BOMs would improve maintainability and security.

• [ ] Update build.gradle classpath to 'com.android.tools.build:gradle:7.4.2' (or latest stable)
• [ ] Update compileSdkVersion to 34 in gradle.properties across root, library/, and sample/
• [ ] Update buildToolsVersion to '34.0.0' in gradle.properties
• [ ] Update minSdkVersion to 21+ in library/build.gradle and verify sample app
• [ ] Test build and APK generation with updated configuration
• [ ] Update README.md with minimum SDK requirements section

Add unit and instrumentation tests for SweetAlertDialog core functionality

The repo has zero test coverage. Core components like SweetAlertDialog.java, ProgressHelper.java, and SuccessTickView.java lack any tests. Adding tests would catch regressions, improve code confidence, and enable future refactoring. This is critical for a UI library used in production apps.

• [ ] Create library/src/test/java/cn/pedant/SweetAlert/ directory with JUnit 4 tests
• [ ] Create library/src/androidTest/java/cn/pedant/SweetAlert/ directory with instrumentation tests
• [ ] Add test for SweetAlertDialog initialization with different alert types (NORMAL, WARNING, ERROR, SUCCESS)
• [ ] Add tests for button callbacks (positive, negative, neutral button listeners)
• [ ] Add instrumentation test for SuccessTickView animation rendering
• [ ] Add test configuration to library/build.gradle with testInstrumentationRunner
• [ ] Document testing approach in README.md

Add GitHub Actions CI workflow for automated testing and release validation

The repo has no CI/CD pipeline to validate PRs or ensure builds don't break. A GitHub Actions workflow would automatically test against multiple Android API levels, validate Gradle builds, and prevent publishing broken releases to Maven Central.

• [ ] Create .github/workflows/android-ci.yml with jobs for building library and sample app
• [ ] Configure matrix testing for minSdkVersion 21+ and compileSdkVersion 34
• [ ] Add lint checks step using Android Lint tool in the workflow
• [ ] Add test execution step (once tests from previous PR are added)
• [ ] Configure workflow to trigger on push to main and all PRs
• [ ] Add workflow status badge to README.md
• [ ] Document CI requirements and local testing setup in CONTRIBUTING.md

• Add unit tests for ProgressHelper methods (setProgress, setBarColor, setSpinSpeed)—currently no test/ directory exists, and these core methods lack regression coverage
• Add support for custom icon drawables via setIconDrawable(Drawable) method—currently only hardcoded drawable resources (error_center_x.xml, success_bow.xml) are supported, limiting reusability
• Create Kotlin extension helpers for builder pattern (e.g., sweetAlert { titleText = "..."; contentText = "..."; show() })—the current Java builder is verbose for modern Android development

This Android library project has significant security concerns primarily related to severely outdated development tools and SDK versions. The use of Gradle plugin 0.14.1, Build Tools 19.1.0, and target SDK 21 (all from 2014) means the project lacks over a decade of security patches and modern security features. The codebase itself appears to be a UI library without obvious injection vulnerabilities, but the outdated toolchain severely compromises the overall security posture. Immediate action is required to modernize the build configuration to meet current Android security standards and Google Play Store requirements.

• High · Outdated Gradle Plugin Version — build.gradle (classpath 'com.android.tools.build:gradle:0.14.1'). The project uses Gradle plugin version 0.14.1, which was released in 2014 and contains numerous security vulnerabilities. This outdated version lacks security patches for known vulnerabilities in the Android build system. Fix: Update to the latest stable version of the Android Gradle Plugin (currently 7.x or 8.x). Ensure compatibility with target SDK version.
• High · Outdated Build Tools Version — build.gradle (buildToolsVersion = '19.1.0'). Build Tools version 19.1.0 is extremely outdated (from 2014) and lacks critical security updates. This version does not support modern security features and vulnerability fixes. Fix: Update buildToolsVersion to at least 33.0.0 or higher to receive security patches and modern compilation standards.
• High · Outdated Target SDK Version — build.gradle (compileSdkVersion = 21). The project targets SDK version 21 (Android 5.0, released 2014), which is extremely outdated. Modern Google Play policies require targeting recent API levels, and this version misses critical security features and patches. Fix: Update compileSdkVersion to API level 33 or higher (target level 34+). This is now required by Google Play Store policies.
• Medium · No Dependency Version Pinning in Gradle — build.gradle (mavenCentral repository configuration). Dependencies in the build configuration do not use version constraints or pinning. While the specific dependencies are limited, the absence of precise version specifications could lead to unexpected behavior from transitive dependencies. Fix: Implement strict version pinning for all dependencies. Use dependency locks or explicit version constraints to ensure reproducible builds.
• Medium · Missing ProGuard/R8 Configuration in Library — library/build.gradle (missing proguard rules). The library module does not appear to have ProGuard or R8 obfuscation rules defined, which could expose code logic and potentially sensitive patterns to reverse engineering. Fix: Add proguard-rules.pro with appropriate keep rules for the library's public API to prevent reverse engineering.
• Low · No Security Policy Defined — Repository root. The repository does not contain a SECURITY.md or security policy file, making it unclear how security vulnerabilities should be reported. Fix: Add a SECURITY.md file with instructions for responsible vulnerability disclosure.

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.