Skeleton widget update

[dewabisma]

Summary

Moved skeleton update in miner reward branch to this branch.

• updated skeleton styling
• updated tx item skeleton

---

Note

Low Risk
Low risk UI-only changes that adjust theme color fields and loading placeholders; main risk is minor visual regressions in skeleton rendering.

Overview
Updates the loading Skeleton to use the V2 theme (context.colors) with a new base + two-tone highlight shimmer, and standardizes the animation duration.

Replaces the old Skeleton.txItem constructor with a dedicated TxItemSkeleton widget and switches activity loading states to render it.

Removes legacy skeleton colors from AppColorsTheme and updates AppColorsV2 to replace skeletonHighlight with skeletonHighlightA/skeletonHighlightB (including new default values).

^{Reviewed by Cursor Bugbot for commit 005bcff. Bugbot is set up for automated code reviews on this repo. Configure here.}

[n13]

I've reviewed PR #480 thoroughly. Here's my review.

Overall

This is a well-scoped, low-risk UI cleanup. CI is green (Analyze, Bugbot, Security Reviewer all passing). The widget becomes simpler, more theme-driven, and removes a pre-existing footgun in Skeleton.circular/Skeleton's border-radius logic. Approving in spirit, with a few small suggestions below.

What's good

• Drops the hardcoded _defaultSkeletonBaseColor / _defaultSkeletonHighlightColor fallbacks → fully theme-driven via context.colors (also matches the "fail early, no silent fallback" rule).
• Splitting Skeleton.txItem into a dedicated TxItemSkeleton widget is cleaner — each shimmering rectangle gets its own animation and proper layout, instead of one fixed 40px-tall bar pretending to be a row.
• All Skeleton.txItem callers (activity_screen.dart, activity_section.dart) are updated; no orphans left in the tree.
• Skeleton.circular now actually applies BorderRadius.circular(size). Previously it set borderRadius = null and relied on the build-time heuristic width == height ? circular(width) : circular(4), which silently turned every square Skeleton into a circle. The new constructor makes the intent explicit.
• Import switched to the canonical package:resonance_network_wallet/... path, consistent with the rest of v2.
• The single MaterialApp in mobile-app/lib/app.dart uses v2/theme/app_theme.dart which registers both V1 and V2 extensions, so context.colors is always available — no risk of null! crash from this widget.

Concerns / suggestions

1. Dead V1 fields left behind. After this PR, AppColorsTheme.skeletonBase and AppColorsTheme.skeletonHighlight in mobile-app/lib/features/styles/app_colors_theme.dart (lines 41–42, 81–82, 123–124, 165–166, 207–208, 246–247, 290–291) have no remaining consumers. Worth deleting them in this PR — DRY-wise we now have two parallel skeleton color definitions (V1+V2), only one of which is used.

2. Subtle visual regression for square Skeletons. Previously Skeleton(width: 32, height: 32) rendered as a 16px-radius circle (because of the width == height shortcut). Now it renders as a 4px-radius rounded square. I checked all callers and none rely on this — the only square use was the old Skeleton.txItem icon block, which is rewritten. Still worth calling out in the PR description so reviewers know the icon block intentionally went from circular to rounded-square.

3. Opacity widget triggers a saveLayer() for every skeleton on screen (3 in activity preview × multiple Skeletons inside TxItemSkeleton = ~15 save layers per loading state). Visually equivalent and cheaper:

decoration: BoxDecoration(
  borderRadius: borderRadius,
  color: context.colors.skeletonBase,
  gradient: LinearGradient(
    begin: Alignment.centerLeft,
    end: Alignment.centerRight,
    colors: [
      context.colors.skeletonHighlightA.withValues(alpha: 0.2),
      context.colors.skeletonHighlightB.withValues(alpha: 0.2),
      context.colors.skeletonHighlightA.withValues(alpha: 0.2),
    ],
    stops: const [0.0, 0.5, 1.0],
    transform: _SlideGradientTransform(_animation.value),
  ),
),

Single Container, no inner widget, no Opacity, no save layer. (You could also bake the 0.2 alpha directly into the V2 palette so this stays a one-line gradient.)

4. Skeleton.circular lost its const-ness. Because BorderRadius.circular(size) isn't const-evaluable for a runtime size. No current callers, so no compile errors, but it does mean any future const Skeleton.circular(size: 16) won't compile. If you want to keep it const-friendly, leave borderRadius = null and resolve in build() like:

final br = widget.borderRadius ??
    (widget.width != null && widget.width == widget.height
        ? BorderRadius.circular(widget.width!)
        : BorderRadius.circular(4));

— but that re-introduces the heuristic from #2, so the simpler thing is to keep the current non-const constructor and accept it.

5. Tiny nit in TxItemSkeleton:

  Widget build(BuildContext context) {
    final double txItemHeight = 32.0;
    final double txItemDetailHeight = 12.0;

    return Row(

Make these const double (or hoist to file-level constants) — then the Skeleton(...) calls below can also become const Skeleton(...), which lets Flutter elide rebuilds.

6. AppColorsV2 has no .light() constructor (pre-existing, not introduced here), but adding two new required fields makes a future light theme slightly more painful. Worth noting.

7. No tests / goldens for the visual change. Not blocking — the codebase doesn't have skeleton tests today — but the new look (solid base + 20% gradient overlay) is materially different from the old (full-strength 3-stop shimmer). A screenshot in the PR description would help the visual reviewer (@n13).

Verdict

LGTM with the dead V1 skeletonBase/skeletonHighlight cleanup as the only thing I'd ask for in this PR. The other items are nice-to-haves and fine as follow-ups.

Want me to push the V1 dead-field cleanup and/or the Opacity-removal optimization to the branch?