137 lines
4.8 KiB
Markdown
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
|
|
|