14893e62a5
This MVP release provides a complete full-stack solution for managing action mappings in Geutebruck's GeViScope and GeViSoft video surveillance systems. ## Features ### Flutter Web Application (Port 8081) - Modern, responsive UI for managing action mappings - Action picker dialog with full parameter configuration - Support for both GSC (GeViScope) and G-Core server actions - Consistent UI for input and output actions with edit/delete capabilities - Real-time action mapping creation, editing, and deletion - Server categorization (GSC: prefix for GeViScope, G-Core: prefix for G-Core servers) ### FastAPI REST Backend (Port 8000) - RESTful API for action mapping CRUD operations - Action template service with comprehensive action catalog (247 actions) - Server management (G-Core and GeViScope servers) - Configuration tree reading and writing - JWT authentication with role-based access control - PostgreSQL database integration ### C# SDK Bridge (gRPC, Port 50051) - Native integration with GeViSoft SDK (GeViProcAPINET_4_0.dll) - Action mapping creation with correct binary format - Support for GSC and G-Core action types - Proper Camera parameter inclusion in action strings (fixes CrossSwitch bug) - Action ID lookup table with server-specific action IDs - Configuration reading/writing via SetupClient ## Bug Fixes - **CrossSwitch Bug**: GSC and G-Core actions now correctly display camera/PTZ head parameters in GeViSet - Action strings now include Camera parameter: `@ PanLeft (Comment: "", Camera: 101028)` - Proper filter flags and VideoInput=0 for action mappings - Correct action ID assignment (4198 for GSC, 9294 for G-Core PanLeft) ## Technical Stack - **Frontend**: Flutter Web, Dart, Dio HTTP client - **Backend**: Python FastAPI, PostgreSQL, Redis - **SDK Bridge**: C# .NET 8.0, gRPC, GeViSoft SDK - **Authentication**: JWT tokens - **Configuration**: GeViSoft .set files (binary format) ## Credentials - GeViSoft/GeViScope: username=sysadmin, password=masterkey - Default admin: username=admin, password=admin123 ## Deployment All services run on localhost: - Flutter Web: http://localhost:8081 - FastAPI: http://localhost:8000 - SDK Bridge gRPC: localhost:50051 - GeViServer: localhost (default port) Generated with Claude Code (https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
143 lines
4.7 KiB
Markdown
143 lines
4.7 KiB
Markdown
# Flutter App Constitution
|
|
|
|
## Purpose
|
|
|
|
This document establishes the foundational principles and standards for developing the Geutebruck API Flutter mobile application. These guidelines ensure code quality, maintainability, and exceptional user experience.
|
|
|
|
## Core Principles
|
|
|
|
### 1. Code Quality
|
|
|
|
- **Clean Code**: Follow Flutter and Dart style guides (effective_dart)
|
|
- **Modularity**: Organize code into reusable widgets and services
|
|
- **Separation of Concerns**: Implement clear boundaries between UI, business logic, and data layers
|
|
- **DRY Principle**: Avoid code duplication through proper abstraction
|
|
- **SOLID Principles**: Apply object-oriented design principles where appropriate
|
|
|
|
### 2. Architecture
|
|
|
|
- **Pattern**: Use **BLoC (Business Logic Component)** pattern for state management
|
|
- Separates presentation from business logic
|
|
- Testable and predictable state management
|
|
- Reactive programming with streams
|
|
- **Layered Architecture**:
|
|
- **Presentation Layer**: Widgets and UI components
|
|
- **Business Logic Layer**: BLoCs and Cubits
|
|
- **Data Layer**: Repositories and data sources
|
|
- **Domain Layer**: Models and business entities
|
|
|
|
### 3. Testing Standards
|
|
|
|
- **Test Coverage**: Minimum 80% code coverage
|
|
- **Test Types**:
|
|
- **Unit Tests**: All business logic, repositories, and utilities
|
|
- **Widget Tests**: All custom widgets and screens
|
|
- **Integration Tests**: Critical user flows
|
|
- **Test-Driven Development (TDD)**: Write tests before implementation where feasible
|
|
- **Mocking**: Use mockito for dependency injection in tests
|
|
|
|
### 4. User Experience
|
|
|
|
- **Material Design 3**: Follow Material Design guidelines for consistency
|
|
- **Responsive Design**: Support multiple screen sizes (phones, tablets)
|
|
- **Accessibility**: Support screen readers, proper contrast ratios, semantic labels
|
|
- **Performance**:
|
|
- App startup time < 3 seconds
|
|
- List scrolling at 60 FPS
|
|
- Image loading with progressive rendering
|
|
- Efficient API calls with caching
|
|
- **Offline-First**: Cache data locally, sync when online
|
|
- **Error Handling**: Graceful error messages with retry options
|
|
|
|
### 5. Security
|
|
|
|
- **Secure Storage**: Use flutter_secure_storage for sensitive data (JWT tokens, passwords)
|
|
- **HTTPS Only**: All API communication over TLS
|
|
- **Token Management**: Automatic token refresh before expiration
|
|
- **Input Validation**: Sanitize all user inputs
|
|
- **No Hardcoded Secrets**: Use environment variables and configuration files
|
|
|
|
### 6. API Integration
|
|
|
|
- **REST Client**: Use dio package for HTTP requests
|
|
- **Error Handling**: Standardized error parsing and user-friendly messages
|
|
- **Retry Logic**: Automatic retry with exponential backoff for failed requests
|
|
- **Request Cancellation**: Cancel pending requests on screen navigation
|
|
- **Response Caching**: Implement caching strategy for frequently accessed data
|
|
|
|
### 7. Code Organization
|
|
|
|
```
|
|
lib/
|
|
├── core/
|
|
│ ├── constants/
|
|
│ ├── errors/
|
|
│ ├── network/
|
|
│ └── utils/
|
|
├── data/
|
|
│ ├── models/
|
|
│ ├── repositories/
|
|
│ └── data_sources/
|
|
├── domain/
|
|
│ ├── entities/
|
|
│ └── repositories/
|
|
├── presentation/
|
|
│ ├── blocs/
|
|
│ ├── screens/
|
|
│ └── widgets/
|
|
└── main.dart
|
|
```
|
|
|
|
### 8. Dependency Management
|
|
|
|
- **Minimal Dependencies**: Only add well-maintained, popular packages
|
|
- **Version Locking**: Use exact versions in pubspec.yaml
|
|
- **Regular Updates**: Review and update dependencies monthly
|
|
- **Null Safety**: Enforce sound null safety
|
|
|
|
### 9. Documentation
|
|
|
|
- **Code Comments**: Document complex logic and non-obvious decisions
|
|
- **API Documentation**: Generate documentation using dartdoc
|
|
- **README**: Comprehensive setup and running instructions
|
|
- **Change Log**: Document all changes in CHANGELOG.md
|
|
|
|
### 10. Version Control
|
|
|
|
- **Git Flow**: Use feature branches with descriptive names
|
|
- **Commit Messages**: Follow conventional commits format
|
|
- **Pull Requests**: Require code review before merging
|
|
- **CI/CD**: Automated testing and deployment pipelines
|
|
|
|
## Governance
|
|
|
|
### Technical Decisions
|
|
|
|
- Architecture changes require team consensus
|
|
- New dependencies require justification and approval
|
|
- Breaking changes require migration plan
|
|
|
|
### Code Review Standards
|
|
|
|
- All code must be reviewed before merging
|
|
- Reviewers check for:
|
|
- Adherence to principles
|
|
- Test coverage
|
|
- Code clarity and documentation
|
|
- Performance implications
|
|
|
|
### Performance Budgets
|
|
|
|
- App size: < 50MB
|
|
- Memory usage: < 200MB during normal operation
|
|
- Network requests: Batched and optimized
|
|
- Battery consumption: Minimal background activity
|
|
|
|
## Exceptions
|
|
|
|
Exceptions to these principles require:
|
|
1. Clear justification
|
|
2. Documentation of trade-offs
|
|
3. Approval from technical lead
|
|
4. Technical debt tracking
|