183 lines
5.2 KiB
Markdown
183 lines
5.2 KiB
Markdown
# Profile Manager Migration Guide
|
|
|
|
## Overview of Changes
|
|
|
|
The Profile Manager has been successfully migrated from a monolithic architecture to a modular screen-based system. This provides better code organization, maintainability, and extensibility.
|
|
|
|
## Key Changes
|
|
|
|
### Architecture
|
|
|
|
**Before (Monolithic)**:
|
|
- Single large `ProfileManager` class handling all screens
|
|
- Mixed UI rendering and business logic
|
|
- Complex navigation and state management
|
|
- Large render method with screen conditionals
|
|
|
|
**After (Modular)**:
|
|
- Separate screen modules for each interface
|
|
- Clean separation between UI and business logic
|
|
- Individual screen classes with focused responsibilities
|
|
- Simplified main ProfileManager class
|
|
|
|
### File Structure Changes
|
|
|
|
```
|
|
profile_manager/
|
|
├── profile_manager.py # Simplified main manager (UPDATED)
|
|
├── profile_data.py # Business logic (unchanged)
|
|
├── ui_components.py # UI components (unchanged)
|
|
├── screens/ # NEW: Modular screen system
|
|
│ ├── __init__.py # Screen exports
|
|
│ ├── base_screen.py # Base screen class
|
|
│ ├── screen_manager.py # Screen management
|
|
│ ├── main_menu_screen.py # Main menu logic
|
|
│ ├── profile_list_screen.py # Profile list logic
|
|
│ ├── create_profile_screen.py # Profile creation logic
|
|
│ ├── edit_profile_screen.py # Settings editing logic
|
|
│ ├── leaderboard_screen.py # Leaderboard display logic
|
|
│ ├── profile_stats_screen.py # Statistics display logic
|
|
│ ├── example_integration.py # Integration example
|
|
│ └── README.md # Screen system documentation
|
|
```
|
|
|
|
### Code Reduction
|
|
|
|
The main `profile_manager.py` has been reduced from:
|
|
- **~750 lines** → **~130 lines** (83% reduction)
|
|
- Complex screen handling → Simple delegation
|
|
- Mixed concerns → Clean separation
|
|
|
|
## Running the Updated Profile Manager
|
|
|
|
### Standard Usage (No Changes)
|
|
```bash
|
|
cd /home/enne2/Sviluppo/mice/profile_manager
|
|
python3 profile_manager.py
|
|
```
|
|
|
|
The user interface and functionality remain exactly the same. All existing features work identically:
|
|
- Create profiles with virtual keyboard
|
|
- Edit profile settings
|
|
- View leaderboards
|
|
- Profile statistics
|
|
- Gamepad and keyboard controls
|
|
|
|
### Verifying the Migration
|
|
|
|
1. **Test Basic Navigation**:
|
|
- Run the profile manager
|
|
- Navigate through all screens
|
|
- Verify all buttons and controls work
|
|
|
|
2. **Test Profile Operations**:
|
|
- Create a new profile
|
|
- Edit profile settings
|
|
- Delete profiles
|
|
- Switch active profiles
|
|
|
|
3. **Test Advanced Features**:
|
|
- View leaderboards (if API enabled)
|
|
- Check profile statistics
|
|
- Test error handling
|
|
|
|
## Benefits of the New Architecture
|
|
|
|
### 1. Maintainability
|
|
- Each screen is independently maintainable
|
|
- Bug fixes isolated to specific screen modules
|
|
- Clear code organization
|
|
|
|
### 2. Extensibility
|
|
- Easy to add new screens
|
|
- Consistent interface pattern
|
|
- Minimal changes to main manager
|
|
|
|
### 3. Testability
|
|
- Individual screen unit tests possible
|
|
- Mock dependencies easily
|
|
- Isolated functionality testing
|
|
|
|
### 4. Code Quality
|
|
- Reduced complexity in main class
|
|
- Single responsibility principle
|
|
- Better error handling
|
|
|
|
## Adding New Screens
|
|
|
|
To add a new screen (e.g., "Settings Screen"):
|
|
|
|
1. **Create screen module**:
|
|
```python
|
|
# screens/settings_screen.py
|
|
from .base_screen import BaseScreen
|
|
|
|
class SettingsScreen(BaseScreen):
|
|
def render(self):
|
|
# Screen rendering logic
|
|
pass
|
|
|
|
def handle_input(self, action: str) -> bool:
|
|
# Input handling logic
|
|
pass
|
|
```
|
|
|
|
2. **Register in screen manager**:
|
|
```python
|
|
# screens/screen_manager.py
|
|
"settings": SettingsScreen(self.data_manager, self.ui_renderer, self)
|
|
```
|
|
|
|
3. **Add navigation**:
|
|
```python
|
|
# From any screen
|
|
self.screen_manager.set_screen("settings")
|
|
```
|
|
|
|
## Backward Compatibility
|
|
|
|
The migration maintains 100% backward compatibility:
|
|
- Same user interface
|
|
- Same keyboard/gamepad controls
|
|
- Same file formats (user_profiles.json)
|
|
- Same external API integration
|
|
- Same SDL2 rendering
|
|
|
|
## Performance Impact
|
|
|
|
The modular system has minimal performance impact:
|
|
- Slightly more memory for screen objects
|
|
- Faster rendering due to delegation
|
|
- Reduced complexity in main loop
|
|
- Better error isolation
|
|
|
|
## Troubleshooting
|
|
|
|
### ImportError: screens module
|
|
If you get import errors, ensure the `screens/` directory exists and has `__init__.py`
|
|
|
|
### Screen not rendering
|
|
Check that the screen is properly registered in `ModularScreenManager._initialize_screens()`
|
|
|
|
### Navigation issues
|
|
Verify screen transitions use `self.screen_manager.set_screen("screen_name")`
|
|
|
|
## Development Workflow
|
|
|
|
### Making Changes to Screens
|
|
1. Edit the specific screen module in `screens/`
|
|
2. No changes needed to main `profile_manager.py`
|
|
3. Test the individual screen
|
|
|
|
### Adding Features
|
|
1. Determine which screen handles the feature
|
|
2. Modify only that screen module
|
|
3. Add any new dependencies to base class if needed
|
|
|
|
### Debugging
|
|
1. Enable debug mode in individual screens
|
|
2. Test screens in isolation
|
|
3. Use screen-specific error handling
|
|
|
|
The modular architecture makes the Profile Manager much more maintainable and extensible while preserving all existing functionality.
|