# 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