daily-notification-plugin/docs/progress/P2.1-IOS-BATCH-C.md

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