Files
daily-notification-plugin/docs/progress/P2.1-IOS-BATCH-C.md
Matthew Raymer 1dca99ad17 feat(ios): Extract orchestration helpers to ScheduleHelper
Extract iOS orchestration logic from plugin to dedicated helper,
matching Android's ScheduleHelper.kt pattern. This completes the
P2.1 native plugin refactoring for both platforms.

Changes:
- Created DailyNotificationScheduleHelper.swift (192 lines)
  - scheduleDailyNotification(): Full orchestration (cancel, clear, save, schedule, prefetch)
  - scheduleDualNotification(): Dual scheduling coordination
  - clearRolloverState(): Rollover state cleanup helper
  - getHealthStatus(): Status combination from multiple sources
- Refactored DailyNotificationPlugin.swift to delegate to helper
  - Reduced plugin by 236 lines (1854 → 1807 LOC)
  - Total iOS reduction: 11.7% (2047 → 1807 LOC)
- Updated documentation
  - docs/progress/00-STATUS.md: Marked verification complete, added helper extraction
  - docs/progress/01-CHANGELOG-WORK.md: Added iOS helper extraction entry
  - docs/progress/P2.1-REFACTORING-COMPLETE.md: Updated with helper extraction
  - docs/00-INDEX.md: Added reference to refactoring summary

Verification:
- TypeScript typecheck: PASS
- Build: PASS
- Tests: PASS (115 tests, 8 test suites)
- External API behavior unchanged

Files changed:
- ios/Plugin/DailyNotificationScheduleHelper.swift (new, 192 lines)
- ios/Plugin/DailyNotificationPlugin.swift (198 insertions, 434 deletions)
- docs/progress/00-STATUS.md (verification status updated)
- docs/progress/01-CHANGELOG-WORK.md (changelog entry added)
- docs/00-INDEX.md (index reference added)

Related:
- Completes P2.1 iOS refactoring (27 methods across 3 batches)
- Matches Android ScheduleHelper.kt pattern
- Total P2.1: 55 methods refactored (28 Android + 27 iOS)
2025-12-24 06:35:03 +00:00

137 lines
4.8 KiB
Markdown

# P2.1 iOS Batch C - Glue & Orchestration Methods
**Purpose:** Third batch of iOS plugin refactoring - methods that orchestrate multiple services
**Owner:** Development Team
**Created:** 2025-12-23
**Status:** ready
**Baseline:** See `docs/progress/00-STATUS.md` (v1.0.11-p3-complete)
---
## Goal
Refactor iOS plugin methods that **orchestrate multiple services** or combine multiple data sources. These methods:
- Combine results from multiple services
- Handle complex coordination logic
- Manage state across multiple services
- May need helper objects (similar to Android's `ScheduleHelper`)
**Success Criteria:**
- Plugin method becomes thin coordinator
- Complex orchestration logic moved to helper/service
- External API unchanged
- Tests pass
---
## Target Methods (Batch C)
### Status & Health (2 methods)
1. **`getNotificationStatus()`**
- **Current:** Combines scheduler (permission + pending count), stateActor/storage (last notification + settings), calculates next time
- **Target:** Create helper or delegate to `DailyNotificationStateActor.getStatus()` if it exists
- **Type:** glue (combines multiple sources)
- **Lines:** ~60 lines
2. **`getHealthStatus()` (private)**
- **Current:** Private helper that combines scheduler and stateActor/storage
- **Target:** Move to `DailyNotificationStateActor` or create helper
- **Type:** glue (combines multiple sources)
- **Lines:** ~40 lines
### Rollover & Delivery (2 methods)
3. **`handleNotificationDelivery()` (private)**
- **Current:** Notification observer that extracts data and calls `processRollover()`
- **Target:** Delegate to `DailyNotificationReactivationManager.handleDelivery()`
- **Type:** glue (notification observer)
- **Lines:** ~20 lines
4. **`processRollover()` (private)**
- **Current:** Private helper that orchestrates scheduler and storage for rollover
- **Target:** Move to `DailyNotificationReactivationManager.processRollover()`
- **Type:** glue (orchestrates multiple services)
- **Lines:** ~50 lines
### Scheduling Orchestration (2 methods)
5. **`scheduleDailyNotification()`**
- **Current:** Complex orchestration: cancel all, clear storage, clear rollover state, save content, schedule notification, schedule background fetch
- **Target:** Extract to helper (similar to Android's `ScheduleHelper.scheduleDailyNotification()`)
- **Type:** glue (complex orchestration)
- **Lines:** ~120 lines
6. **`scheduleDualNotification()`**
- **Current:** Orchestrates both background fetch and user notification scheduling
- **Target:** Extract to helper or delegate to integration manager
- **Type:** glue (orchestrates multiple schedulers)
- **Lines:** ~15 lines (already simplified, but marked as glue)
---
## Implementation Strategy
1. **Review current implementation** of each method
2. **Identify orchestration logic** that can be extracted
3. **Create helper methods** (similar to Android's `ScheduleHelper`) or enhance existing services
4. **Refactor plugin method** to: validate → delegate to helper → map response
5. **Test** that external API behavior is unchanged
6. **Commit** in small batches (1-2 methods per commit)
---
## Helper Methods Needed
Similar to Android, we may need to create iOS helper objects:
- **`ScheduleHelper` (Swift)** - For scheduling orchestration
- `scheduleDailyNotification()` - Complex orchestration
- `scheduleDualNotification()` - Dual scheduling coordination
- **Or enhance existing services:**
- `DailyNotificationStateActor.getStatus()` - Combine multiple status sources
- `DailyNotificationReactivationManager.processRollover()` - Rollover orchestration
- `DailyNotificationReactivationManager.handleDelivery()` - Delivery handling
---
## Notes
- iOS uses async/await (Swift concurrency) vs Kotlin coroutines
- Services are optional properties (need nil checks)
- State actor pattern for thread-safe access (iOS 13+)
- Background task manager exists but may not be initialized in plugin
- Some methods are private helpers that should be moved to services
---
## Estimated Impact
- **Methods refactored:** 6
- **Lines removed:** ~200-300 lines (orchestration logic moved to helpers/services)
- **Complexity reduction:** High (complex coordination logic moved out of plugin)
- **Risk:** Medium (orchestration logic changes, but external API unchanged)
---
## Next Steps
After Batch C, the iOS plugin should be a thin adapter similar to Android:
- All business logic in services
- Plugin only validates input and delegates
- Complex orchestration in helpers/services
- External API unchanged
---
## Success Criteria
- [ ] All 6 glue methods refactored
- [ ] Orchestration logic moved to helpers/services
- [ ] Plugin class is thin adapter
- [ ] External API behavior unchanged
- [ ] Tests pass
- [ ] Documentation updated