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)
3.8 KiB
3.8 KiB
P2.1 iOS Batch A - Pure Delegation Methods
Purpose: First batch of iOS plugin refactoring - pure delegation methods (no validation, no orchestration)
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 are pure delegation - methods that can directly call service methods without input validation or result transformation.
Success Criteria:
- Plugin method becomes thin wrapper around service call
- No business logic remains in plugin
- External API unchanged
- Tests pass
Target Methods (Batch A)
1. cancelAllNotifications()
- Current: Direct call to
UNUserNotificationCenter.current().removeAllPendingNotificationRequests() - Target Service:
UNUserNotificationCenter(already direct) - Change: Keep as-is (already thin) OR wrap in service if we create a notification manager
- Type: pure
- Lines: ~10 lines
2. getLastNotification()
- Current: Delegates to
storage?.getLastNotification() - Target Service:
DailyNotificationStorage - Change: Ensure proper error handling, delegate directly
- Type: pure
- Lines: ~15 lines
3. getScheduledReminders()
- Current: Delegates to
storage?.getReminders() - Target Service:
DailyNotificationStorage - Change: Ensure proper error handling, delegate directly
- Type: pure
- Lines: ~15 lines
4. getBackgroundTaskStatus()
- Current: May have logic in plugin
- Target Service:
DailyNotificationBackgroundTaskManager - Change: Delegate to
backgroundTaskManager.getStatus() - Type: pure
- Lines: ~20 lines
5. checkForMissedBGTask()
- Current: May have logic in plugin
- Target Service:
DailyNotificationBackgroundTaskManager - Change: Delegate to
backgroundTaskManager.checkMissed() - Type: pure
- Lines: ~20 lines
6. getNextScheduledNotificationTime()
- Current: May delegate to scheduler
- Target Service:
DailyNotificationScheduler - Change: Delegate to
scheduler?.getNextTime() - Type: pure
- Lines: ~20 lines
7. getDualScheduleStatus()
- Current: May combine multiple sources
- Target Service:
DailyNotificationScheduler - Change: Delegate to
scheduler?.getDualStatus() - Type: pure (if service method exists) or glue (if needs combination)
- Lines: ~30 lines
Implementation Strategy
- Read current implementation of each method
- Identify service method to delegate to (or create if needed)
- Refactor plugin method to thin wrapper
- Test that external API behavior is unchanged
- Commit in small batches (1-2 methods per commit)
Service Initialization
Ensure services are initialized in load():
storage: DailyNotificationStorage?✅ (already exists)scheduler: DailyNotificationScheduler?✅ (already exists)backgroundTaskManager: DailyNotificationBackgroundTaskManager?(may need to add)reactivationManager: DailyNotificationReactivationManager?✅ (already exists)stateActor: DailyNotificationStateActor?✅ (already exists)
Notes
- iOS uses
@objc funcfor plugin methods (not@PluginMethodlike Android) - Methods are registered in
pluginMethodsarray - Error handling uses
call.reject()andcall.resolve() - Services are optional (
var storage: DailyNotificationStorage?), so need nil checks
Estimated Impact
- Methods refactored: 7
- Lines removed: ~130-150 lines
- Complexity reduction: Low (pure delegation)
- Risk: Low (no business logic changes)
Next Batch
After Batch A, proceed to Batch B (validation + delegation methods) and Batch C (glue/orchestration methods).