126 lines
4.2 KiB
Markdown
126 lines
4.2 KiB
Markdown
# Priority 2.1: Batch C - Glue & Orchestration Methods
|
|
|
|
**Purpose:** Third refactoring batch focusing on glue methods and complex orchestration.
|
|
**Owner:** Development Team
|
|
**Created:** 2025-12-23
|
|
**Status:** in_progress
|
|
**Baseline:** See `docs/progress/00-STATUS.md` (v1.0.11-p3-complete)
|
|
|
|
---
|
|
|
|
## Batch C Scope
|
|
|
|
**Goal:** Refactor methods that coordinate multiple services or perform complex orchestration.
|
|
|
|
**Risk Level:** ⭐⭐⭐ Medium-High (complex orchestration, multiple service coordination)
|
|
|
|
**Estimated Impact:** ~6-8 methods across both platforms
|
|
|
|
**Prerequisites:**
|
|
- Batch A complete (7 methods)
|
|
- Batch B complete (15 methods)
|
|
|
|
---
|
|
|
|
## Android Methods
|
|
|
|
### Integration & Configuration
|
|
|
|
1. **`configure()`**
|
|
- **Current:** Simple database storage placeholder
|
|
- **Target:** `TimeSafariIntegrationManager.configure(...)`
|
|
- **Change:** Delegate configuration to integration manager
|
|
- **Files:** `DailyNotificationPlugin.kt` (~20 lines → ~5 lines)
|
|
- **Type:** glue
|
|
|
|
2. **`updateStarredPlans()`**
|
|
- **Current:** Validation + SharedPreferences logic in plugin
|
|
- **Target:** `TimeSafariIntegrationManager.updateStarredPlans(...)`
|
|
- **Change:** Extract validation, delegate to manager
|
|
- **Files:** `DailyNotificationPlugin.kt` (~85 lines → ~10 lines)
|
|
- **Type:** validation + glue
|
|
|
|
### Schedule Status (Multi-Service)
|
|
|
|
3. **`getSchedulesWithStatus()`**
|
|
- **Current:** Combines storage queries + scheduler status checks
|
|
- **Target:** `ScheduleHelper.getSchedulesWithStatus()` or new service method
|
|
- **Change:** Extract combination logic to helper/service
|
|
- **Files:** `DailyNotificationPlugin.kt` (~50 lines → ~10 lines)
|
|
- **Type:** glue
|
|
|
|
### Complex Scheduling
|
|
|
|
4. **`scheduleDailyNotification()`**
|
|
- **Current:** Complex validation + cleanup + scheduling orchestration
|
|
- **Target:** `DailyNotificationScheduler.scheduleDaily(...)` (may need enhancement)
|
|
- **Change:** Extract validation, delegate orchestration
|
|
- **Files:** `DailyNotificationPlugin.kt` (~350 lines → ~30 lines)
|
|
- **Type:** validation + glue
|
|
- **Note:** Large method, may need to be broken into smaller pieces
|
|
|
|
5. **`scheduleUserNotification()`**
|
|
- **Current:** Validation + scheduling orchestration
|
|
- **Target:** `DailyNotificationScheduler.scheduleUserNotification(...)`
|
|
- **Change:** Extract validation, delegate to scheduler
|
|
- **Files:** `DailyNotificationPlugin.kt` (~100 lines → ~15 lines)
|
|
- **Type:** validation + glue
|
|
|
|
6. **`scheduleDualNotification()`**
|
|
- **Current:** Complex dual-schedule orchestration (fetch + notify)
|
|
- **Target:** `TimeSafariIntegrationManager.scheduleDual(...)`
|
|
- **Change:** Extract entire orchestration to integration manager
|
|
- **Files:** `DailyNotificationPlugin.kt` (~200 lines → ~15 lines)
|
|
- **Type:** glue
|
|
|
|
---
|
|
|
|
## Implementation Strategy
|
|
|
|
### Phase 1: Simple Delegations (Low Risk)
|
|
- `configure()` → `TimeSafariIntegrationManager`
|
|
- `updateStarredPlans()` → `TimeSafariIntegrationManager`
|
|
|
|
### Phase 2: Status Combination (Medium Risk)
|
|
- `getSchedulesWithStatus()` → Extract to helper/service
|
|
|
|
### Phase 3: Complex Scheduling (Higher Risk)
|
|
- `scheduleUserNotification()` → `DailyNotificationScheduler`
|
|
- `scheduleDailyNotification()` → `DailyNotificationScheduler` (may need service enhancement)
|
|
- `scheduleDualNotification()` → `TimeSafariIntegrationManager`
|
|
|
|
---
|
|
|
|
## Expected Outcomes
|
|
|
|
### Metrics
|
|
- **Android plugin:** ~800-900 lines removed
|
|
- **Total reduction (A+B+C):** ~1200-1300 lines across all batches
|
|
- **Test coverage:** Maintained (no behavior changes)
|
|
|
|
### Benefits
|
|
- ✅ Plugin becomes true thin adapter
|
|
- ✅ Complex orchestration moves to appropriate services
|
|
- ✅ Integration logic centralized in `TimeSafariIntegrationManager`
|
|
- ✅ Easier to test and maintain
|
|
|
|
---
|
|
|
|
## Rollback Plan
|
|
|
|
If issues arise:
|
|
1. Revert commits for this batch
|
|
2. Service methods remain unchanged (no risk)
|
|
3. Plugin methods can be restored from git history
|
|
|
|
---
|
|
|
|
## Next Steps
|
|
|
|
After Batch C completes:
|
|
- **Review:** Assess plugin class size and complexity
|
|
- **iOS:** Consider starting iOS Batch A/B/C if Android is complete
|
|
- **Testing:** Comprehensive testing of all refactored methods
|
|
- **Documentation:** Update final status and metrics
|
|
|