Build activity type breakdown widget base layout
epic-annual-impact-summary-ui-components-task-010 — Implement the ActivityTypeBreakdownWidget scaffold with support for rendering multiple activity type segments as a bar or pie chart layout. Each segment must display an organisation-specific activity type label (sourced from the OrgLabelsProvider), a percentage value, and a colour derived from design tokens.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 1 - 540 tasks
Can start after Tier 0 completes
Implementation Notes
Implement the chart using Flutter's CustomPainter for maximum control over rendering without introducing a chart dependency. Define an ActivityTypeSegment model with fields: activityTypeId (String), percentage (double), absoluteCount (int), colorToken (String — design token key, resolved to Color at render time). Source segment colours from a design token map (e.g. chartSegmentColors[index % palette.length]) rather than assigning per-activity-type to avoid coupling.
For bar layout, render segments as proportionally sized horizontal bars in a Column; for pie/donut, use CustomPaint with arc drawing. Wrap label text in a Flexible/Expanded to prevent overflow. Consume OrgLabelsProvider via Riverpod ref.watch — pass the resolved label strings into the widget as a parameter rather than reading the provider deep in the paint call, to keep CustomPainter pure. Keep the widget stateless at this stage; tap handling and animations are explicitly out of scope for this task.
Testing Requirements
Widget tests using flutter_test: (1) render with 1, 5, and 10 segments and assert no RenderFlex overflow errors; (2) assert each segment text matches the label returned by a mock OrgLabelsProvider; (3) assert percentage text renders as '[N]%' format; (4) assert segment colours match design token values (not raw hex); (5) test both bar and pie layout modes render without exception. Golden tests for both layout modes with 5 segments. Unit tests for percentage rounding logic if extracted to a utility function.
Simultaneous count-up animations across multiple stat cards and chart draw-in animations on lower-end Android devices may cause frame drops below 60fps, degrading the premium Wrapped experience and making the feature feel unpolished.
Mitigation & Contingency
Mitigation: Stagger animation starts using AnimationController with staggered intervals rather than starting all animations simultaneously. Use RepaintBoundary around each animated widget to isolate rasterisation. Profile on a mid-range Android device (e.g., equivalent to Pixel 4a) during development, not just at QA.
Contingency: If frame rate targets cannot be met on low-end devices, implement a device-capability check at startup and substitute simpler fade-in animations for the count-up and chart draw-in on devices below a CPU performance threshold.
The activity-type-breakdown-widget must render organisation-specific activity type labels sourced from the terminology system. If the terminology provider is not yet integrated at the time this widget is built, the widget will display hardcoded system labels, which is a regression risk for multi-org support.
Mitigation & Contingency
Mitigation: Accept activity type labels as a typed parameter in the widget constructor rather than reading from the terminology provider directly inside the widget. The BLoC or repository layer resolves labels before passing them to the widget, maintaining clean separation and testability.
Contingency: If terminology resolution is unavailable at widget integration time, display internal activity type keys as a temporary fallback with a localised suffix '(label pending)' visible only in non-production builds so QA can identify unresolved labels.