daily-notification-plugin/docs/P2.1-NATIVE-REFACTORING-ANALYSIS.md

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