31214c816d
Created docs/P2.1-NATIVE-REFACTORING-ANALYSIS.md with: - Current state analysis (Android: 2,782 lines, iOS: 2,047 lines) - Inventory of existing services (many already extracted!) - Refactoring strategy: Focus on making plugin a thin adapter - Next steps: Analyze remaining methods, create extraction plan Key Finding: Many services already exist on both platforms. Refactoring should focus on delegation to existing services rather than creating new ones. Verification: - Analysis document created ✅ - Existing services inventoried ✅ - Strategy defined ✅
111 lines
4.1 KiB
Markdown
111 lines
4.1 KiB
Markdown
# Priority 2.1: Native Plugin Refactoring - Analysis
|
|
|
|
**Purpose:** Analyze current native plugin structure and create refactoring plan to extract services from god classes.
|
|
**Owner:** Development Team
|
|
**Last Updated:** 2025-12-23
|
|
**Status:** analysis
|
|
|
|
---
|
|
|
|
## Current State
|
|
|
|
### Android: `DailyNotificationPlugin.kt`
|
|
- **Location:** `android/src/main/java/com/timesafari/dailynotification/DailyNotificationPlugin.kt`
|
|
- **Size:** ~2,782 lines (per ChatGPT feedback)
|
|
- **Type:** Capacitor Plugin class (extends `Plugin`)
|
|
|
|
### iOS: `DailyNotificationPlugin.swift`
|
|
- **Location:** `ios/Plugin/DailyNotificationPlugin.swift`
|
|
- **Size:** ~2,047 lines (per ChatGPT feedback)
|
|
- **Type:** Capacitor Plugin class (extends `CAPPlugin`)
|
|
|
|
---
|
|
|
|
## Refactoring Goals
|
|
|
|
### Target Services (from ChatGPT feedback)
|
|
|
|
1. **SchedulerService** - Schedule management logic
|
|
2. **PermissionService** - Permission handling
|
|
3. **Power/ExactAlarmService** - Power management and exact alarm handling
|
|
4. **ReactivationService** - Cold start recovery and reactivation
|
|
5. **RollingWindowService** - Rolling window and rate limiting
|
|
6. **Storage/StateRepository** - Database and state management
|
|
7. **FetcherBridge** - Native fetcher registration and calling
|
|
|
|
### Principles
|
|
|
|
- **Thin Plugin Adapter**: Plugin class should only:
|
|
- Parse/validate input
|
|
- Call platform service
|
|
- Map exceptions to plugin errors
|
|
- **Service-Oriented**: Real logic lives in services
|
|
- **Testability**: Services should be independently testable
|
|
- **No Breaking Changes**: Maintain existing API surface
|
|
|
|
---
|
|
|
|
## Analysis Steps
|
|
|
|
1. **Inventory Current Methods** - List all methods in both plugin classes
|
|
2. **Identify Service Boundaries** - Group methods by logical service
|
|
3. **Check Existing Services** - See what's already extracted
|
|
4. **Create Extraction Plan** - Define safe, incremental extraction order
|
|
5. **Define Service Interfaces** - Establish contracts for each service
|
|
|
|
---
|
|
|
|
## Analysis Results
|
|
|
|
### Good News: Many Services Already Extracted!
|
|
|
|
Both platforms have already extracted significant functionality into services:
|
|
|
|
#### Android Services Already Exist:
|
|
- ✅ `PermissionManager.java` - Permission handling
|
|
- ✅ `DailyNotificationScheduler.java` - Scheduling logic
|
|
- ✅ `ReactivationManager.kt` - Cold start recovery
|
|
- ✅ `DailyNotificationRollingWindow.java` - Rolling window logic
|
|
- ✅ `DailyNotificationStorage.java` - Storage abstraction
|
|
- ✅ `DailyNotificationExactAlarmManager.java` - Exact alarm handling
|
|
- ✅ `NativeNotificationContentFetcher.java` - Fetcher interface
|
|
- ✅ `DailyNotificationPerformanceOptimizer.java` - Performance optimization
|
|
- ✅ `TimeSafariIntegrationManager.java` - Integration orchestration
|
|
|
|
#### iOS Services Already Exist:
|
|
- ✅ `DailyNotificationScheduler.swift` - Scheduling logic
|
|
- ✅ `DailyNotificationReactivationManager.swift` - Recovery
|
|
- ✅ `DailyNotificationRollingWindow.swift` - Rolling window
|
|
- ✅ `DailyNotificationStorage.swift` - Storage abstraction
|
|
- ✅ `DailyNotificationPowerManager.swift` - Power management
|
|
- ✅ `DailyNotificationStateActor.swift` - Thread-safe state
|
|
- ✅ `DailyNotificationBackgroundTaskManager.swift` - Background tasks
|
|
|
|
### Remaining Work
|
|
|
|
The plugin classes still contain:
|
|
1. **Direct database access** - Should use Storage service
|
|
2. **Business logic** - Should delegate to services
|
|
3. **Error handling** - Should use ErrorHandler service
|
|
4. **Validation logic** - Should be in service layer
|
|
5. **Orchestration** - Should use IntegrationManager (Android) or similar (iOS)
|
|
|
|
### Refactoring Strategy
|
|
|
|
Since many services already exist, the refactoring should focus on:
|
|
1. **Removing direct service instantiation** from plugin methods
|
|
2. **Delegating all business logic** to existing services
|
|
3. **Making plugin class a thin adapter** that only:
|
|
- Parses/validates input
|
|
- Calls service methods
|
|
- Maps exceptions to plugin errors
|
|
4. **Consolidating duplicate logic** into services
|
|
|
|
## Next Steps
|
|
|
|
1. ✅ Inventory existing services (DONE)
|
|
2. ⏭️ Analyze plugin methods to identify what still needs extraction
|
|
3. ⏭️ Create extraction plan focusing on delegation, not new services
|
|
4. ⏭️ Implement refactoring in small batches
|
|
|