feat: Geutebruck GeViScope/GeViSoft Action Mapping System - MVP

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>
This commit is contained in:
Administrator
2025-12-31 18:10:54 +01:00
commit 14893e62a5
4189 changed files with 1395076 additions and 0 deletions

View File

@@ -0,0 +1,264 @@
# Flutter App Specification - 001-flutter-app
## Overview
This specification defines a mobile application for managing Geutebruck video surveillance systems through the REST API. The app provides administrators and operators with full control over server configurations, action mappings, cameras, monitors, and cross-switching operations.
## Specification Documents
### 📜 [constitution.md](./constitution.md)
**Foundational principles and standards**
Defines the core principles, architecture patterns, testing standards, and code quality requirements for the Flutter app development. This document must be reviewed and understood by all team members before beginning implementation.
**Key Topics:**
- Clean Architecture + BLoC pattern
- Testing requirements (80% coverage minimum)
- Security standards (secure storage, HTTPS, token management)
- Performance budgets
- Code organization and style guidelines
---
### 📋 [spec.md](./spec.md)
**Functional requirements and user stories**
Contains all user stories organized by epic, with detailed acceptance criteria for each feature. This is the primary reference for understanding WHAT needs to be built and HOW it should behave from a user perspective.
**Epics Covered:**
1. Authentication & Authorization (3 user stories)
2. Server Management (8 user stories)
3. Action Mapping Management (5 user stories)
4. Camera Management (3 user stories)
5. Monitor Management (2 user stories)
6. Cross-Switching (2 user stories)
7. Configuration Management (2 user stories)
8. User Interface & Navigation (4 user stories)
**Total:** 29 user stories with complete acceptance criteria
---
### 🏗️ [plan.md](./plan.md)
**Technical implementation strategy**
Describes the technical architecture, technology stack, design patterns, and implementation approach. This document explains HOW the system will be built from a technical perspective.
**Key Sections:**
- Technology stack with justifications
- Clean Architecture layered approach
- BLoC state management pattern
- Folder structure and organization
- API integration strategy
- Caching and offline support
- Error handling patterns
- Testing strategy
- Performance optimization techniques
---
### ✅ [tasks.md](./tasks.md)
**Detailed implementation task breakdown**
Provides a comprehensive, ordered list of implementation tasks organized by user story and phase. Each task includes file paths, dependencies, and test requirements.
**Phases:**
1. Foundation & Setup
2. Server Management
3. Action Mapping Management
4. Camera Management
5. Monitor & Cross-Switching
6. Configuration Management
7. UI & Navigation
8. Testing & Polish
9. Deployment Preparation
**Total:** 186+ tasks with dependencies mapped
---
### 🚀 [quickstart.md](./quickstart.md)
**Setup and running instructions**
Step-by-step guide for setting up the development environment, installing dependencies, running the app, and common development workflows.
**Covers:**
- Prerequisites and installation
- Running the app on different platforms
- Development workflow
- Testing commands
- Troubleshooting
- IDE setup
- CI/CD configuration
---
## Getting Started
### For Product Owners / Stakeholders
1. Start with **spec.md** to review user stories and acceptance criteria
2. Use **constitution.md** to understand quality standards
3. Review **plan.md** for technical approach and timeline estimates
### For Developers
1. Read **constitution.md** to understand coding standards
2. Study **plan.md** for architecture and patterns
3. Follow **quickstart.md** to set up your environment
4. Use **tasks.md** to pick up tasks based on current phase
5. Reference **spec.md** for acceptance criteria while implementing
### For Project Managers
1. Use **tasks.md** for sprint planning and task assignment
2. Track progress against user stories in **spec.md**
3. Monitor adherence to **constitution.md** standards during code review
4. Reference **plan.md** for understanding technical dependencies
## Document Relationships
```
┌─────────────────┐
│ constitution.md │ ◄─── Defines standards for all documents
└─────────────────┘
┌─────────────────┐
│ spec.md │ ◄─── What needs to be built (User Stories)
└─────────────────┘
┌─────────────────┐
│ plan.md │ ◄─── How it will be built (Architecture)
└─────────────────┘
┌─────────────────┐
│ tasks.md │ ◄─── Detailed task breakdown
└─────────────────┘
┌─────────────────┐
│ quickstart.md │ ◄─── How to get started
└─────────────────┘
```
## Current Status
**Specification Status:** ✅ Complete
All specification documents have been created and reviewed. Ready for implementation.
**Implementation Status:** 🚧 Not Started
Awaiting Flutter SDK installation completion and development environment setup.
## Implementation Workflow
Following the spec-kit methodology:
```
1. Constitution (Standards) ✅ Complete
2. Specification (Requirements) ✅ Complete
3. Clarification (Q&A) ⏳ Ongoing
4. Plan (Architecture) ✅ Complete
5. Tasks (Breakdown) ✅ Complete
6. Implementation 🚧 Ready to start
```
## API Reference
The Flutter app integrates with the Geutebruck REST API:
**Base URL:** `http://localhost:8000/api/v1`
**Key Endpoints:**
- Authentication: `/auth/login`, `/auth/refresh`
- Servers: `/configuration/servers/gcore`, `/configuration/servers/geviscope`
- Action Mappings: `/configuration/action-mappings`
- Cameras: `/cameras`
- Monitors: `/monitors`
- Cross-Switching: `/crossswitch`
See the API documentation at `http://localhost:8000/docs` for complete endpoint details.
## Technology Stack Summary
- **Framework:** Flutter 3.24+
- **Language:** Dart 3.0+
- **State Management:** BLoC (flutter_bloc)
- **HTTP Client:** Dio + Retrofit
- **Local Storage:** Hive + flutter_secure_storage
- **Dependency Injection:** get_it + injectable
- **Code Generation:** freezed, json_serializable, build_runner
- **Testing:** mockito, bloc_test, integration_test
## Success Criteria
The implementation will be considered successful when:
- [ ] All 29 user stories implemented with acceptance criteria met
- [ ] Test coverage ≥ 80%
- [ ] All widget tests passing
- [ ] Integration tests for critical flows passing
- [ ] Performance benchmarks met (startup < 3s, 60 FPS scrolling)
- [ ] Security review completed
- [ ] Accessibility tested
- [ ] User acceptance testing completed
## Timeline Estimate
Based on the task breakdown in tasks.md:
- **Phase 1 (Foundation):** 1-2 weeks
- **Phase 2 (Server Management):** 1-2 weeks
- **Phase 3 (Action Mappings):** 1-2 weeks
- **Phase 4 (Cameras):** 1-2 weeks
- **Phase 5 (Monitors & Cross-Switching):** 1-2 weeks
- **Phase 6 (Configuration):** 1 week
- **Phase 7 (UI & Navigation):** 1 week
- **Phase 8 (Testing & Polish):** 2 weeks
- **Phase 9 (Deployment):** 1 week
**Total:** 10-13 weeks (2.5-3 months) with 2-3 developers
## Team Roles
**Recommended Team:**
- 1 Senior Flutter Developer (Architecture, Code Review)
- 2 Flutter Developers (Feature Implementation)
- 1 QA Engineer (Testing)
- 1 UI/UX Designer (Designs and Assets)
- 1 Product Owner (Requirements, Acceptance)
## Maintenance & Updates
This specification is a living document. Updates should be made when:
- New features are requested
- Technical architecture changes
- API endpoints are modified
- User feedback requires adjustments
**Version Control:**
- All changes tracked in Git
- Each major update creates a new version tag
- Breaking changes documented in CHANGELOG.md
## Questions or Clarifications
For questions about the specification:
1. Check the relevant document (constitution, spec, plan, tasks)
2. Review the quickstart guide for setup/development questions
3. Consult the team lead for architectural decisions
4. Create an issue in the project repository for tracking
## License
This specification is proprietary to the Geutebruck API project.
---
**Specification Version:** 1.0
**Last Updated:** December 19, 2025
**Status:** Ready for Implementation

View File

@@ -0,0 +1,142 @@
# 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

View File

@@ -0,0 +1,618 @@
# Geutebruck API Flutter App - Technical Implementation Plan
## Technology Stack
### Core Framework
- **Flutter 3.24+**: Cross-platform mobile framework
- **Dart 3.0+**: Programming language with sound null safety
### State Management
- **flutter_bloc 8.1+**: BLoC pattern implementation
- *Rationale*: Predictable state management, excellent testing support, separation of concerns
- *Alternatives considered*: Provider (simpler but less structured), Riverpod (newer but less mature ecosystem)
### HTTP Client & API
- **dio 5.4+**: HTTP client for API calls
- Features: Interceptors, request/response transformation, timeout handling
- Better than http package: More features, better error handling
- **retrofit 4.0+**: Type-safe HTTP client generator
- Auto-generates API client code from interface definitions
- Reduces boilerplate and errors
### Data Persistence
- **flutter_secure_storage 9.0+**: Secure storage for tokens and credentials
- **shared_preferences 2.2+**: App settings and preferences
- **hive 2.2+**: Local database for caching
- *Rationale*: Fast, lightweight, no SQL required, perfect for caching API responses
### Dependency Injection
- **get_it 7.6+**: Service locator pattern
- *Rationale*: Simple, explicit dependencies, excellent for testing
- **injectable 2.3+**: Code generation for get_it
- Reduces boilerplate in dependency registration
### UI Components
- **Material Design 3**: Modern, accessible UI components
- **cached_network_image 3.3+**: Efficient image loading and caching
- **shimmer 3.0+**: Loading skeletons
- **flutter_svg 2.0+**: SVG image support
### Navigation
- **go_router 13.0+**: Declarative routing
- *Rationale*: Deep linking support, type-safe navigation, excellent for web
### Form Handling & Validation
- **flutter_form_builder 9.1+**: Dynamic form creation
- **form_builder_validators 9.1+**: Reusable validators
### Testing
- **mockito 5.4+**: Mocking dependencies
- **bloc_test 9.1+**: Testing BLoCs
- **golden_toolkit 0.15+**: Widget screenshot testing
### Code Generation
- **freezed 2.4+**: Immutable data classes with union types
- **json_serializable 6.7+**: JSON serialization
- **build_runner 2.4+**: Code generation orchestrator
### Development Tools
- **flutter_launcher_icons 0.13+**: App icon generation
- **flutter_native_splash 2.3+**: Splash screen generation
- **very_good_analysis 5.1+**: Lint rules
## Architecture
### Clean Architecture + BLoC
```
┌─────────────────────────────────────────────────────┐
│ Presentation Layer │
│ ┌────────────┐ ┌────────────┐ ┌────────────┐ │
│ │ Screens │ │ Widgets │ │ BLoCs │ │
│ └────────────┘ └────────────┘ └────────────┘ │
└─────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────┐
│ Domain Layer │
│ ┌────────────┐ ┌────────────┐ ┌────────────┐ │
│ │ Entities │ │ Use Cases │ │ Repository │ │
│ │ │ │ │ │ Interfaces │ │
│ └────────────┘ └────────────┘ └────────────┘ │
└─────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────┐
│ Data Layer │
│ ┌────────────┐ ┌────────────┐ ┌────────────┐ │
│ │ Models │ │Repositories│ │Data Sources│ │
│ │ │ │ │ │ (Remote) │ │
│ └────────────┘ └────────────┘ └────────────┘ │
└─────────────────────────────────────────────────────┘
```
### Layer Responsibilities
#### Presentation Layer
- **Screens**: Full-page views (ServerListScreen, LoginScreen, etc.)
- **Widgets**: Reusable UI components (ServerCard, LoadingWidget, etc.)
- **BLoCs**: Business logic controllers, emit states based on events
#### Domain Layer
- **Entities**: Pure business objects (Server, ActionMapping, Camera)
- **Use Cases**: Single-responsibility business operations (GetServers, CreateServer)
- **Repository Interfaces**: Contracts for data access
#### Data Layer
- **Models**: Data transfer objects with JSON serialization
- **Repositories**: Implement repository interfaces, coordinate data sources
- **Data Sources**:
- **Remote**: API client using dio/retrofit
- **Local**: Hive cache
### Folder Structure
```
lib/
├── core/
│ ├── constants/
│ │ ├── api_constants.dart
│ │ ├── app_constants.dart
│ │ └── asset_constants.dart
│ ├── errors/
│ │ ├── exceptions.dart
│ │ └── failures.dart
│ ├── network/
│ │ ├── api_client.dart
│ │ ├── dio_client.dart
│ │ └── interceptors/
│ │ ├── auth_interceptor.dart
│ │ └── logging_interceptor.dart
│ ├── theme/
│ │ ├── app_theme.dart
│ │ └── colors.dart
│ └── utils/
│ ├── validators.dart
│ └── extensions.dart
├── data/
│ ├── models/
│ │ ├── server_model.dart
│ │ ├── action_mapping_model.dart
│ │ ├── camera_model.dart
│ │ └── auth_model.dart
│ ├── repositories/
│ │ ├── server_repository_impl.dart
│ │ ├── action_mapping_repository_impl.dart
│ │ ├── camera_repository_impl.dart
│ │ └── auth_repository_impl.dart
│ └── data_sources/
│ ├── remote/
│ │ ├── server_remote_data_source.dart
│ │ ├── action_mapping_remote_data_source.dart
│ │ └── auth_remote_data_source.dart
│ └── local/
│ ├── cache_manager.dart
│ └── secure_storage_manager.dart
├── domain/
│ ├── entities/
│ │ ├── server.dart
│ │ ├── action_mapping.dart
│ │ ├── camera.dart
│ │ └── user.dart
│ ├── repositories/
│ │ ├── server_repository.dart
│ │ ├── action_mapping_repository.dart
│ │ └── auth_repository.dart
│ └── use_cases/
│ ├── servers/
│ │ ├── get_servers.dart
│ │ ├── create_server.dart
│ │ ├── update_server.dart
│ │ └── delete_server.dart
│ ├── action_mappings/
│ │ ├── get_action_mappings.dart
│ │ └── create_action_mapping.dart
│ └── auth/
│ ├── login.dart
│ ├── refresh_token.dart
│ └── logout.dart
├── presentation/
│ ├── blocs/
│ │ ├── auth/
│ │ │ ├── auth_bloc.dart
│ │ │ ├── auth_event.dart
│ │ │ └── auth_state.dart
│ │ ├── server/
│ │ │ ├── server_bloc.dart
│ │ │ ├── server_event.dart
│ │ │ └── server_state.dart
│ │ └── action_mapping/
│ │ ├── action_mapping_bloc.dart
│ │ ├── action_mapping_event.dart
│ │ └── action_mapping_state.dart
│ ├── screens/
│ │ ├── auth/
│ │ │ └── login_screen.dart
│ │ ├── servers/
│ │ │ ├── server_list_screen.dart
│ │ │ ├── server_detail_screen.dart
│ │ │ └── server_form_screen.dart
│ │ ├── action_mappings/
│ │ │ ├── action_mapping_list_screen.dart
│ │ │ └── action_mapping_form_screen.dart
│ │ ├── cameras/
│ │ │ ├── camera_list_screen.dart
│ │ │ └── camera_control_screen.dart
│ │ └── settings/
│ │ └── settings_screen.dart
│ └── widgets/
│ ├── common/
│ │ ├── loading_widget.dart
│ │ ├── error_widget.dart
│ │ └── empty_state_widget.dart
│ ├── server/
│ │ └── server_card.dart
│ └── action_mapping/
│ └── action_mapping_card.dart
├── injection.dart
└── main.dart
```
## API Integration
### Base Configuration
```dart
class ApiConfig {
static const String baseUrl = 'http://localhost:8000';
static const Duration timeout = Duration(seconds: 30);
static const Duration receiveTimeout = Duration(seconds: 30);
}
```
### Dio Setup with Interceptors
```dart
@singleton
class DioClient {
final Dio _dio;
DioClient() : _dio = Dio(BaseOptions(
baseUrl: ApiConfig.baseUrl,
connectTimeout: ApiConfig.timeout,
receiveTimeout: ApiConfig.receiveTimeout,
)) {
_dio.interceptors.addAll([
AuthInterceptor(),
LoggingInterceptor(),
]);
}
}
```
### Auth Interceptor (Token Management)
```dart
class AuthInterceptor extends Interceptor {
@override
void onRequest(RequestOptions options, RequestInterceptorHandler handler) async {
final token = await secureStorage.read(key: 'access_token');
if (token != null) {
options.headers['Authorization'] = 'Bearer $token';
}
handler.next(options);
}
@override
void onError(DioException err, ErrorInterceptorHandler handler) async {
if (err.response?.statusCode == 401) {
// Token expired, try refresh
final refreshed = await refreshToken();
if (refreshed) {
// Retry original request
return handler.resolve(await _retry(err.requestOptions));
}
}
handler.next(err);
}
}
```
### Repository Pattern Example
```dart
@injectable
class ServerRepositoryImpl implements ServerRepository {
final ServerRemoteDataSource remoteDataSource;
final CacheManager cacheManager;
ServerRepositoryImpl({
required this.remoteDataSource,
required this.cacheManager,
});
@override
Future<Either<Failure, List<Server>>> getServers() async {
try {
// Try cache first
final cached = await cacheManager.getServers();
if (cached != null && !cached.isExpired) {
return Right(cached.data);
}
// Fetch from API
final servers = await remoteDataSource.getServers();
// Update cache
await cacheManager.saveServers(servers);
return Right(servers.map((m) => m.toEntity()).toList());
} on ServerException catch (e) {
return Left(ServerFailure(e.message));
} on NetworkException {
return Left(NetworkFailure());
}
}
}
```
## State Management Flow
### BLoC Pattern
```dart
// Event
abstract class ServerEvent {}
class LoadServers extends ServerEvent {}
class CreateServer extends ServerEvent {
final ServerCreateRequest request;
CreateServer(this.request);
}
// State
abstract class ServerState {}
class ServerInitial extends ServerState {}
class ServerLoading extends ServerState {}
class ServerLoaded extends ServerState {
final List<Server> servers;
ServerLoaded(this.servers);
}
class ServerError extends ServerState {
final String message;
ServerError(this.message);
}
// BLoC
class ServerBloc extends Bloc<ServerEvent, ServerState> {
final GetServers getServers;
final CreateServer createServer;
ServerBloc({
required this.getServers,
required this.createServer,
}) : super(ServerInitial()) {
on<LoadServers>(_onLoadServers);
on<CreateServer>(_onCreateServer);
}
Future<void> _onLoadServers(
LoadServers event,
Emitter<ServerState> emit,
) async {
emit(ServerLoading());
final result = await getServers();
result.fold(
(failure) => emit(ServerError(failure.message)),
(servers) => emit(ServerLoaded(servers)),
);
}
}
```
## Caching Strategy
### Cache Layers
1. **Memory Cache**: In-memory Map for frequently accessed data
2. **Disk Cache (Hive)**: Persistent storage for offline access
3. **Secure Storage**: Encrypted storage for tokens and credentials
### Cache Policy
```dart
class CachePolicy {
// Short-lived cache (5 minutes)
static const Duration shortCache = Duration(minutes: 5);
// Medium cache (30 minutes)
static const Duration mediumCache = Duration(minutes: 30);
// Long cache (24 hours)
static const Duration longCache = Duration(hours: 24);
}
// Server list: Short cache (changes frequently)
// Action mappings: Medium cache
// Configuration tree: Long cache
```
## Error Handling
### Error Types
```dart
abstract class Failure {
String get message;
}
class NetworkFailure extends Failure {
@override
String get message => 'No internet connection';
}
class ServerFailure extends Failure {
final String errorMessage;
ServerFailure(this.errorMessage);
@override
String get message => errorMessage;
}
class ValidationFailure extends Failure {
final Map<String, String> errors;
ValidationFailure(this.errors);
@override
String get message => 'Validation failed';
}
```
### UI Error Display
```dart
Widget buildError(Failure failure) {
if (failure is NetworkFailure) {
return ErrorWidget(
message: failure.message,
icon: Icons.wifi_off,
action: ElevatedButton(
onPressed: () => context.read<ServerBloc>().add(LoadServers()),
child: Text('Retry'),
),
);
}
// ... other failure types
}
```
## Testing Strategy
### Unit Tests
```dart
void main() {
late ServerRepositoryImpl repository;
late MockServerRemoteDataSource mockRemoteDataSource;
late MockCacheManager mockCacheManager;
setUp(() {
mockRemoteDataSource = MockServerRemoteDataSource();
mockCacheManager = MockCacheManager();
repository = ServerRepositoryImpl(
remoteDataSource: mockRemoteDataSource,
cacheManager: mockCacheManager,
);
});
group('getServers', () {
test('should return cached data when cache is valid', () async {
// Arrange
when(mockCacheManager.getServers())
.thenAnswer((_) async => CachedData([server1, server2]));
// Act
final result = await repository.getServers();
// Assert
expect(result, isA<Right<Failure, List<Server>>>());
verifyNever(mockRemoteDataSource.getServers());
});
});
}
```
### Widget Tests
```dart
void main() {
testWidgets('ServerListScreen displays servers', (tester) async {
// Arrange
final mockBloc = MockServerBloc();
when(mockBloc.state).thenReturn(ServerLoaded([server1, server2]));
// Act
await tester.pumpWidget(
MaterialApp(
home: BlocProvider<ServerBloc>.value(
value: mockBloc,
child: ServerListScreen(),
),
),
);
// Assert
expect(find.text('Server 1'), findsOneWidget);
expect(find.text('Server 2'), findsOneWidget);
});
}
```
## Build & Deployment
### Build Configurations
```yaml
# build.yaml
targets:
$default:
builders:
freezed:
enabled: true
json_serializable:
enabled: true
```
### Environment Configuration
```dart
// config.dart
abstract class Config {
static String get apiBaseUrl => _apiBaseUrl;
static String _apiBaseUrl = 'http://localhost:8000';
static void setDevelopment() {
_apiBaseUrl = 'http://localhost:8000';
}
static void setProduction() {
_apiBaseUrl = 'https://api.production.com';
}
}
```
### CI/CD Pipeline
```yaml
# .github/workflows/flutter.yml
name: Flutter CI
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: subosito/flutter-action@v2
- run: flutter pub get
- run: flutter analyze
- run: flutter test --coverage
- uses: codecov/codecov-action@v3
```
## Implementation Phases
### Phase 1: Foundation (Week 1-2)
- Project setup with dependencies
- Folder structure
- Dependency injection setup
- API client configuration
- Authentication flow
### Phase 2: Core Features (Week 3-4)
- Server management (list, create, update, delete)
- Action mapping management
- Camera list and details
### Phase 3: Advanced Features (Week 5-6)
- PTZ camera control
- Monitor management
- Cross-switching
- Configuration export
### Phase 4: Polish (Week 7-8)
- Offline support
- Error handling improvements
- Performance optimization
- UI/UX refinements
- Accessibility improvements
### Phase 5: Testing & Deployment (Week 9-10)
- Comprehensive testing
- User acceptance testing
- Bug fixes
- App store preparation
- Documentation
## Performance Optimization
### Image Loading
- Use `cached_network_image` with disk and memory cache
- Progressive JPEG for large images
- Thumbnail generation for lists
### List Performance
- Use `ListView.builder` for long lists
- Implement pagination for server/mapping lists
- Lazy loading of details
### Memory Management
- Dispose BLoCs and controllers properly
- Clear cache periodically
- Monitor memory usage in DevTools
### Network Optimization
- Batch API requests where possible
- Implement request debouncing for search
- Cancel pending requests on navigation
- Use HTTP/2 for multiplexing

View File

@@ -0,0 +1,583 @@
# Geutebruck API Flutter App - Quick Start Guide
## Prerequisites
Before you begin, ensure you have the following installed:
### Required Software
1. **Flutter SDK 3.24+**
- Download from: https://flutter.dev/docs/get-started/install
- Add to PATH: `C:\Users\{username}\develop\flutter\bin`
2. **Git for Windows**
- Download from: https://git-scm.com/downloads/win
3. **Code Editor**
- Recommended: Visual Studio Code with Flutter extension
- Alternative: Android Studio
### Platform-Specific Requirements
#### For Android Development
1. **Android Studio**
- Download from: https://developer.android.com/studio
- Install Android SDK
- Install Android SDK Build-Tools
- Install Android Emulator
2. **Java JDK 11+**
- Download from: https://www.oracle.com/java/technologies/downloads/
#### For iOS Development (macOS only)
1. **Xcode 14+**
- Download from Mac App Store
- Install Xcode Command Line Tools
2. **CocoaPods**
```bash
sudo gem install cocoapods
```
## Installation
### 1. Verify Flutter Installation
```bash
flutter doctor
```
Expected output should show checkmarks for:
- Flutter (Channel stable)
- Android toolchain
- Chrome (for web development)
- Visual Studio Code
- Connected device
### 2. Clone the Repository
```bash
cd C:\DEV\COPILOT
git clone <repository-url> geutebruck_app
cd geutebruck_app
```
### 3. Install Dependencies
```bash
flutter pub get
```
### 4. Generate Code
The app uses code generation for models, BLoCs, and dependency injection:
```bash
flutter pub run build_runner build --delete-conflicting-outputs
```
For continuous code generation during development:
```bash
flutter pub run build_runner watch --delete-conflicting-outputs
```
### 5. Configure API Endpoint
Edit the API configuration file:
**File:** `lib/core/constants/api_constants.dart`
```dart
class ApiConstants {
static const String baseUrl = 'http://localhost:8000'; // Change to your API URL
static const Duration timeout = Duration(seconds: 30);
}
```
## Running the App
### On Android Emulator
1. Start Android emulator:
```bash
flutter emulators --launch <emulator_id>
```
2. Run the app:
```bash
flutter run
```
### On iOS Simulator (macOS only)
1. Start iOS simulator:
```bash
open -a Simulator
```
2. Run the app:
```bash
flutter run
```
### On Physical Device
1. Enable USB debugging on your device (Android)
- Settings → About Phone → Tap Build Number 7 times
- Settings → Developer Options → Enable USB Debugging
2. Connect device via USB
3. Verify device is detected:
```bash
flutter devices
```
4. Run the app:
```bash
flutter run
```
### Hot Reload During Development
While the app is running:
- Press `r` to hot reload
- Press `R` to hot restart
- Press `q` to quit
## Development Workflow
### 1. Feature Development
Follow this workflow for each feature:
1. **Write Tests First (TDD)**
```bash
# Create test file
test/domain/use_cases/servers/get_servers_test.dart
# Run test (will fail)
flutter test test/domain/use_cases/servers/get_servers_test.dart
# Implement feature
lib/domain/use_cases/servers/get_servers.dart
# Run test (should pass)
flutter test test/domain/use_cases/servers/get_servers_test.dart
```
2. **Generate Code**
```bash
flutter pub run build_runner build
```
3. **Run App**
```bash
flutter run
```
### 2. Code Generation
The app uses several code generators:
#### Freezed (Immutable Models)
```dart
// Define model
@freezed
class Server with _$Server {
const factory Server({
required String id,
required String alias,
}) = _Server;
factory Server.fromJson(Map<String, dynamic> json) =>
_$ServerFromJson(json);
}
// Generate with:
flutter pub run build_runner build
```
#### Injectable (Dependency Injection)
```dart
// Annotate class
@injectable
class ServerRepository {
final ServerRemoteDataSource remoteDataSource;
ServerRepository(this.remoteDataSource);
}
// Register in injection.dart:
@InjectableInit()
void configureDependencies() => getIt.init();
// Generate with:
flutter pub run build_runner build
```
### 3. Testing
#### Run All Tests
```bash
flutter test
```
#### Run Specific Test File
```bash
flutter test test/domain/use_cases/servers/get_servers_test.dart
```
#### Run Tests with Coverage
```bash
flutter test --coverage
```
View coverage report:
```bash
genhtml coverage/lcov.info -o coverage/html
open coverage/html/index.html
```
#### Widget Tests
```dart
testWidgets('ServerListScreen displays servers', (tester) async {
await tester.pumpWidget(
MaterialApp(home: ServerListScreen()),
);
expect(find.text('Servers'), findsOneWidget);
});
```
#### Integration Tests
```bash
flutter test integration_test/app_test.dart
```
## Project Structure
```
lib/
├── core/ # Core utilities and configurations
│ ├── constants/
│ ├── errors/
│ ├── network/
│ └── theme/
├── data/ # Data layer
│ ├── models/ # JSON serializable models
│ ├── repositories/ # Repository implementations
│ └── data_sources/ # Remote and local data sources
├── domain/ # Domain layer
│ ├── entities/ # Business entities
│ ├── repositories/ # Repository interfaces
│ └── use_cases/ # Business logic
├── presentation/ # Presentation layer
│ ├── blocs/ # BLoC state management
│ ├── screens/ # Full-page screens
│ └── widgets/ # Reusable widgets
├── injection.dart # Dependency injection setup
└── main.dart # App entry point
```
## Common Commands
### Development
```bash
# Run app in debug mode
flutter run
# Run app in profile mode (for performance testing)
flutter run --profile
# Run app in release mode
flutter run --release
# Clean build artifacts
flutter clean
# Update dependencies
flutter pub upgrade
# Check for outdated packages
flutter pub outdated
# Analyze code
flutter analyze
```
### Building
```bash
# Build Android APK
flutter build apk --release
# Build Android App Bundle (for Play Store)
flutter build appbundle --release
# Build iOS (macOS only)
flutter build ipa --release
```
### Debugging
```bash
# Run with DevTools
flutter run --devtools
# Attach debugger to running app
flutter attach
# Get device logs
flutter logs
```
## Environment Configuration
### Development Environment
**File:** `lib/core/config/env_config.dart`
```dart
enum Environment { development, staging, production }
class EnvConfig {
static Environment currentEnv = Environment.development;
static String get apiBaseUrl {
switch (currentEnv) {
case Environment.development:
return 'http://localhost:8000';
case Environment.staging:
return 'https://staging-api.geutebruck.com';
case Environment.production:
return 'https://api.geutebruck.com';
}
}
}
```
Switch environments:
```dart
// In main.dart
void main() {
EnvConfig.currentEnv = Environment.production;
runApp(MyApp());
}
```
## Troubleshooting
### Flutter Doctor Issues
```bash
flutter doctor -v
```
Common fixes:
- **Android license not accepted**: `flutter doctor --android-licenses`
- **Xcode not configured**: `sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer`
### Build Runner Issues
```bash
# Clean and rebuild
flutter clean
flutter pub get
flutter pub run build_runner clean
flutter pub run build_runner build --delete-conflicting-outputs
```
### Dependency Conflicts
```bash
# Clear pub cache
flutter pub cache repair
# Clean and reinstall
flutter clean
rm pubspec.lock
flutter pub get
```
### Hot Reload Not Working
- Try hot restart (press `R`)
- Check for syntax errors
- Some changes require full restart (native code, assets)
### Emulator Performance
For better Android emulator performance:
1. Enable hardware acceleration (Intel HAXM or AMD Hypervisor)
2. Allocate more RAM to emulator (4GB+)
3. Use x86/x64 system images (not ARM)
## IDE Setup
### Visual Studio Code
Install extensions:
1. Flutter
2. Dart
3. Flutter Intl (for internationalization)
4. Error Lens
5. GitLens
**Settings (.vscode/settings.json):**
```json
{
"dart.lineLength": 120,
"editor.formatOnSave": true,
"dart.debugExternalPackageLibraries": false,
"dart.debugSdkLibraries": false,
"[dart]": {
"editor.formatOnSave": true,
"editor.formatOnType": true,
"editor.rulers": [120],
"editor.selectionHighlight": false,
"editor.suggest.snippetsPreventQuickSuggestions": false,
"editor.suggestSelection": "first",
"editor.tabCompletion": "onlySnippets",
"editor.wordBasedSuggestions": false
}
}
```
### Android Studio
Install plugins:
1. Flutter
2. Dart
Configure:
- File → Settings → Languages & Frameworks → Flutter
- Set Flutter SDK path
## API Testing
Before running the app, ensure the backend API is running:
```bash
# Start API server
cd C:\DEV\COPILOT\geutebruck-api
python -m uvicorn src.api.main:app --host 0.0.0.0 --port 8000
# Verify API is accessible
curl http://localhost:8000/api/v1/health
```
Test authentication:
```bash
curl -X POST http://localhost:8000/api/v1/auth/login \
-H "Content-Type: application/json" \
-d '{"username":"admin","password":"admin123"}'
```
## Continuous Integration
### GitHub Actions
**File:** `.github/workflows/flutter.yml`
```yaml
name: Flutter CI
on:
push:
branches: [ main, develop ]
pull_request:
branches: [ main, develop ]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Setup Flutter
uses: subosito/flutter-action@v2
with:
flutter-version: '3.24.0'
channel: 'stable'
- name: Install dependencies
run: flutter pub get
- name: Generate code
run: flutter pub run build_runner build --delete-conflicting-outputs
- name: Analyze
run: flutter analyze
- name: Run tests
run: flutter test --coverage
- name: Upload coverage
uses: codecov/codecov-action@v3
with:
files: ./coverage/lcov.info
build:
runs-on: ubuntu-latest
needs: test
steps:
- uses: actions/checkout@v3
- name: Setup Flutter
uses: subosito/flutter-action@v2
- name: Build APK
run: flutter build apk --release
- name: Upload APK
uses: actions/upload-artifact@v3
with:
name: app-release.apk
path: build/app/outputs/flutter-apk/app-release.apk
```
## Next Steps
1. **Review Specifications**
- Read `constitution.md` for coding standards
- Review `spec.md` for user stories
- Study `plan.md` for architecture
2. **Start Development**
- Begin with Phase 1 tasks in `tasks.md`
- Follow TDD approach (tests first)
- Use code generation for models and DI
3. **Join the Team**
- Set up development environment
- Clone repository
- Create feature branch
- Start with assigned tasks
## Support
For issues or questions:
- Check Flutter documentation: https://flutter.dev/docs
- BLoC documentation: https://bloclibrary.dev
- Project-specific questions: See team lead
---
**Happy Coding! 🚀**

View File

@@ -0,0 +1,552 @@
# Geutebruck API Flutter App - Functional Specification
## Overview
A mobile application for managing Geutebruck video surveillance systems through the REST API. The app provides administrators with full control over server configurations, action mappings, cameras, monitors, and cross-switching operations.
## Target Users
- **System Administrators**: Configure and manage Geutebruck servers
- **Security Operators**: Monitor and control video surveillance systems
- **Technicians**: Set up action mappings and camera configurations
## User Stories
### Epic 1: Authentication & Authorization
#### US-1.1: User Login
**As a** system administrator
**I want to** log in with my username and password
**So that** I can securely access the system
**Acceptance Criteria:**
- Login screen with username and password fields
- Secure credential storage using flutter_secure_storage
- JWT token received and stored on successful authentication
- Error message displayed for invalid credentials
- "Remember me" option to persist login
- Password visibility toggle
- Loading indicator during authentication
**API Endpoint:** `POST /api/v1/auth/login`
---
#### US-1.2: Automatic Token Refresh
**As a** logged-in user
**I want** my session to remain active without re-logging in
**So that** I don't lose access during normal usage
**Acceptance Criteria:**
- Access token automatically refreshed before expiration
- Refresh token used to obtain new access token
- User redirected to login if refresh fails
- Silent refresh (no UI disruption)
**API Endpoint:** `POST /api/v1/auth/refresh`
---
#### US-1.3: User Logout
**As a** logged-in user
**I want to** log out of the application
**So that** I can secure my session when done
**Acceptance Criteria:**
- Logout button in app drawer/menu
- All tokens cleared from secure storage
- User redirected to login screen
- Confirmation dialog before logout
---
### Epic 2: Server Management
#### US-2.1: View All Servers
**As a** system administrator
**I want to** see a list of all configured servers (G-Core and GeViScope)
**So that** I can manage my infrastructure
**Acceptance Criteria:**
- Combined list showing both G-Core and GeViScope servers
- Display: alias, host, type (G-Core/GeViScope), enabled status
- Search/filter by alias or host
- Pull-to-refresh to update list
- Server count displayed (total, G-Core, GeViScope)
- Visual indicator for enabled/disabled servers
- Tap to view details
**API Endpoint:** `GET /api/v1/configuration/servers`
---
#### US-2.2: View G-Core Servers
**As a** system administrator
**I want to** view only G-Core servers
**So that** I can focus on G-Core management
**Acceptance Criteria:**
- Filtered list showing only G-Core servers
- Display: ID, alias, host, user, enabled status
- Search and filter capabilities
- Sort by ID, alias, or host
**API Endpoint:** `GET /api/v1/configuration/servers/gcore`
---
#### US-2.3: View GeViScope Servers
**As a** system administrator
**I want to** view only GeViScope servers
**So that** I can focus on GeViScope management
**Acceptance Criteria:**
- Filtered list showing only GeViScope servers
- Display: ID, alias, host, user, enabled status, dialup settings
- Search and filter capabilities
**API Endpoint:** `GET /api/v1/configuration/servers/geviscope`
---
#### US-2.4: View Server Details
**As a** system administrator
**I want to** view detailed information about a specific server
**So that** I can review its configuration
**Acceptance Criteria:**
- All server properties displayed
- Connection status indicator
- Edit button to modify settings
- Delete button to remove server
- Test connection button
**API Endpoints:**
- `GET /api/v1/configuration/servers/gcore/{id}`
- `GET /api/v1/configuration/servers/geviscope/{id}`
---
#### US-2.5: Create G-Core Server
**As a** system administrator
**I want to** add a new G-Core server
**So that** I can expand my managed infrastructure
**Acceptance Criteria:**
- Form with fields: alias, host, user, password
- Optional fields: enabled, deactivate_echo, deactivate_live_check
- Input validation (required fields, valid IP/hostname)
- Server ID auto-generated
- Success/error feedback
- Return to server list on success
**API Endpoint:** `POST /api/v1/configuration/servers/gcore`
---
#### US-2.6: Create GeViScope Server
**As a** system administrator
**I want to** add a new GeViScope server
**So that** I can manage GeViScope systems
**Acceptance Criteria:**
- Form with standard fields plus dialup settings
- All dialup configuration options available
- Input validation
- Success/error feedback
**API Endpoint:** `POST /api/v1/configuration/servers/geviscope`
---
#### US-2.7: Update Server
**As a** system administrator
**I want to** modify an existing server's configuration
**So that** I can keep settings current
**Acceptance Criteria:**
- Pre-populated form with current values
- Editable fields (except ID)
- Validation before saving
- Confirmation dialog for changes
- Success/error feedback
**API Endpoints:**
- `PUT /api/v1/configuration/servers/gcore/{id}`
- `PUT /api/v1/configuration/servers/geviscope/{id}`
---
#### US-2.8: Delete Server
**As a** system administrator
**I want to** remove a server from the system
**So that** I can clean up unused configurations
**Acceptance Criteria:**
- Delete button with confirmation dialog
- Warning message about permanent deletion
- Success feedback
- Return to server list
- Server removed from list immediately
**API Endpoints:**
- `DELETE /api/v1/configuration/servers/gcore/{id}`
- `DELETE /api/v1/configuration/servers/geviscope/{id}`
---
### Epic 3: Action Mapping Management
#### US-3.1: View Action Mappings
**As a** system administrator
**I want to** see all configured action mappings
**So that** I can understand the automation rules
**Acceptance Criteria:**
- List of all action mappings with caption, ID
- Display input action parameters
- Display output action count
- Search by caption
- Pull-to-refresh
- Tap to view details
**API Endpoint:** `GET /api/v1/configuration/action-mappings`
---
#### US-3.2: View Action Mapping Details
**As a** system administrator
**I want to** see detailed information about an action mapping
**So that** I can understand its configuration
**Acceptance Criteria:**
- Display mapping caption and ID
- List all input action parameters with values
- List all output actions with:
- Action name
- Caption
- Server
- Parameters
- Edit and delete buttons
**API Endpoint:** `GET /api/v1/configuration/action-mappings/{id}`
---
#### US-3.3: Create Action Mapping
**As a** system administrator
**I want to** create a new action mapping
**So that** I can automate system responses
**Acceptance Criteria:**
- Form with mapping caption
- Dynamic input parameter builder
- Output action builder with:
- Action dropdown (GscAction/GCoreAction)
- Server selection
- Parameter configuration
- PTZ head selection for camera actions
- Add multiple output actions
- Validation of all fields
- Success/error feedback
**API Endpoint:** `POST /api/v1/configuration/action-mappings`
---
#### US-3.4: Update Action Mapping
**As a** system administrator
**I want to** modify an existing action mapping
**So that** I can adjust automation rules
**Acceptance Criteria:**
- Pre-populated form with current values
- Edit caption, input parameters, output actions
- Add/remove output actions
- Validation
- Success/error feedback
**API Endpoint:** `PUT /api/v1/configuration/action-mappings/{id}`
---
#### US-3.5: Delete Action Mapping
**As a** system administrator
**I want to** remove an action mapping
**So that** I can clean up unused automations
**Acceptance Criteria:**
- Delete button with confirmation
- Warning about permanent deletion
- Success feedback
- Removed from list immediately
**API Endpoint:** `DELETE /api/v1/configuration/action-mappings/{id}`
---
### Epic 4: Camera Management
#### US-4.1: View Camera List
**As a** security operator
**I want to** see all available cameras
**So that** I can select cameras for viewing or control
**Acceptance Criteria:**
- List of all cameras with ID and name
- Visual indicator for online/offline status
- Search by camera name
- Filter by status
- Pull-to-refresh
**API Endpoint:** `GET /api/v1/cameras`
---
#### US-4.2: View Camera Details
**As a** security operator
**I want to** see detailed camera information
**So that** I can understand its configuration
**Acceptance Criteria:**
- Camera ID, name, description
- Connection status
- Server assignment
- PTZ capabilities indicator
- Quick action buttons (if PTZ supported)
**API Endpoint:** `GET /api/v1/cameras/{id}`
---
#### US-4.3: Control PTZ Camera
**As a** security operator
**I want to** control PTZ camera movements
**So that** I can direct camera focus
**Acceptance Criteria:**
- PTZ control pad (Pan Left/Right, Tilt Up/Down)
- Zoom In/Out buttons
- Focus Near/Far buttons
- Stop button for all movements
- Speed control slider
- Preset position selector
- Save preset button
- Visual feedback during movement
**API Endpoints:**
- Pan: Actions like PanLeft, PanRight, PanStop
- Tilt: TiltUp, TiltDown
- Zoom: ZoomIn, ZoomOut, ZoomStop
- Focus: FocusNear, FocusFar, FocusStop
- Presets: PrePosSave, PrePosCall
---
### Epic 5: Monitor Management
#### US-5.1: View Monitor List
**As a** security operator
**I want to** see all available monitors
**So that** I can manage video displays
**Acceptance Criteria:**
- List of monitors with ID and description
- Status indicator
- Search and filter
- Tap to view details
**API Endpoint:** `GET /api/v1/monitors`
---
#### US-5.2: View Monitor Details
**As a** security operator
**I want to** see monitor configuration details
**So that** I can understand its setup
**Acceptance Criteria:**
- Monitor ID, description, layout
- Current camera assignments
- Quick actions (clear, assign camera)
**API Endpoint:** `GET /api/v1/monitors/{id}`
---
### Epic 6: Cross-Switching
#### US-6.1: Assign Camera to Monitor
**As a** security operator
**I want to** connect a camera to a monitor
**So that** I can view live video
**Acceptance Criteria:**
- Camera selector (dropdown or search)
- Monitor selector
- Preview of current assignments
- Connect button
- Success/error feedback
- Live video preview (optional)
**API Endpoint:** `POST /api/v1/crossswitch/connect`
---
#### US-6.2: Clear Monitor
**As a** security operator
**I want to** disconnect all cameras from a monitor
**So that** I can reset the display
**Acceptance Criteria:**
- Monitor selector
- Confirmation dialog
- Clear button
- Success feedback
**API Endpoint:** `POST /api/v1/crossswitch/clear`
---
### Epic 7: Configuration Management
#### US-7.1: Export Configuration
**As a** system administrator
**I want to** export the complete system configuration
**So that** I can back it up or migrate it
**Acceptance Criteria:**
- Export button in settings
- JSON format export
- Save to device storage
- Share option (email, cloud)
- Export includes all servers, action mappings, etc.
**API Endpoint:** `GET /api/v1/configuration/export`
---
#### US-7.2: View Configuration Tree
**As a** system administrator
**I want to** browse the raw configuration structure
**So that** I can troubleshoot or verify settings
**Acceptance Criteria:**
- Expandable tree view
- Search/filter nodes
- Display node types and values
- Read-only view
**API Endpoint:** `GET /api/v1/configuration/tree`
---
### Epic 8: User Interface & Navigation
#### US-8.1: App Navigation
**As a** user
**I want** intuitive navigation between app sections
**So that** I can efficiently access features
**Acceptance Criteria:**
- Bottom navigation bar with:
- Servers
- Action Mappings
- Cameras
- Monitors
- Side drawer with:
- Configuration
- Settings
- About
- Logout
- Back button support
- Clear visual hierarchy
---
#### US-8.2: Settings Screen
**As a** user
**I want to** configure app preferences
**So that** I can customize my experience
**Acceptance Criteria:**
- API base URL configuration
- Theme selection (Light/Dark/System)
- Language selection
- Notification preferences
- Cache management
- About section with version info
---
#### US-8.3: Error Handling
**As a** user
**I want** clear error messages and recovery options
**So that** I understand what went wrong and how to proceed
**Acceptance Criteria:**
- Network error: Retry button, offline indicator
- Authentication error: Redirect to login
- Validation error: Field-specific messages
- Server error: Error details with support contact
- Snackbar notifications for temporary messages
- Error logging for debugging
---
#### US-8.4: Loading States
**As a** user
**I want** visual feedback during operations
**So that** I know the app is working
**Acceptance Criteria:**
- Shimmer loading for lists
- Progress indicators for long operations
- Pull-to-refresh animation
- Button loading state (disabled with spinner)
---
## Non-Functional Requirements
### Performance
- App launch time: < 3 seconds on modern devices
- List scrolling: 60 FPS
- API response time: Visual feedback within 100ms
- Image loading: Progressive rendering with placeholders
### Security
- All data transmission over HTTPS
- Tokens stored in secure storage
- Auto-logout after 30 minutes of inactivity
- No sensitive data in logs
### Compatibility
- Android 8.0 (API level 26) and above
- iOS 12.0 and above
- Support for phones and tablets
### Accessibility
- Screen reader support
- Minimum touch target size: 48x48 dp
- Contrast ratio: 4.5:1 for text
- Semantic labels for all interactive elements
### Offline Support
- Cache server lists, action mappings
- Queue operations when offline
- Sync when connection restored
- Offline indicator in UI
## Review & Acceptance Checklist
- [ ] All user stories implemented with acceptance criteria met
- [ ] Unit test coverage 80%
- [ ] Widget tests for all screens
- [ ] Integration tests for critical flows
- [ ] API integration tested against live backend
- [ ] Performance metrics validated
- [ ] Security review completed
- [ ] Accessibility tested with screen reader
- [ ] User acceptance testing completed
- [ ] Documentation updated

View File

@@ -0,0 +1,811 @@
# Geutebruck API Flutter App - Implementation Tasks
## Implementation Status (Last Updated: 2025-12-23)
### ✅ Completed Features (Phase 1 & 2)
- **US-1.1**: User Login - Login screen with authentication ✅
- **US-1.2**: Token Management - Secure storage with flutter_secure_storage ✅
- **US-2.1**: View All Servers - Server list with filtering (All/G-Core/GeViScope) ✅
- **US-2.5**: Create G-Core Server - Full form implementation ✅
- **US-2.6**: Create GeViScope Server - Full form implementation ✅
- **US-2.7**: Update Server - Edit functionality with proper state handling ✅
- **US-2.8**: Delete Server - Delete with confirmation dialog ✅
- **Navigation**: App drawer with left menu navigation ✅
- **Offline-First**: Hive local storage with sync capabilities ✅
- **Server Sync**: Upload dirty changes to remote server ✅
- **Server Download**: Download latest configuration from server ✅
- **State Management**: BLoC pattern with shared state across routes ✅
### 🐛 Recent Bug Fixes
- Fixed "No data" display issue after server update (2025-12-23)
- Issue: BlocBuilder fallback showing "No data" during state transitions
- Solution: Changed fallback to show loading indicator instead
- File: `lib/presentation/screens/servers/servers_management_screen.dart:268`
### 🚧 In Progress
- Testing and validation of server management features
### 📋 Pending (Phase 3-9)
- US-3.x: Action Mapping Management
- US-4.x: Camera Management
- US-5.x: Monitor & Cross-Switching
- US-6.x: Cross-Switch Management
- US-7.x: Configuration Export/Tree View
- US-8.x: Additional UI/UX improvements
---
## Task Organization
Tasks are organized by user story and marked with:
- `[P]` - Can be done in parallel
- `[✅]` - Completed
- `[🚧]` - In Progress
- File paths indicate where code should be created/modified
- TDD tasks (tests) listed before implementation tasks
---
## Phase 1: Foundation & Setup
### Task Group: Project Setup
#### TASK-001 [P] [✅]: Create Flutter Project
**File:** N/A (command line)
```bash
flutter create geutebruck_app
cd geutebruck_app
```
#### TASK-002 [P] [✅]: Configure Dependencies
**File:** `pubspec.yaml`
- Add all required dependencies from plan.md
- Set Flutter SDK constraints
- Configure assets folder
#### TASK-003 [✅]: Setup Folder Structure
**Files:** Create folder structure as defined in plan.md
```
lib/core/
lib/data/
lib/domain/
lib/presentation/
```
#### TASK-004 [P] [✅]: Configure Analysis Options
**File:** `analysis_options.yaml`
- Add very_good_analysis
- Configure lint rules
- Enable strict mode
#### TASK-005 [P] [✅]: Setup Build Configuration
**File:** `build.yaml`
- Configure freezed
- Configure json_serializable
- Configure injectable
---
### Task Group: US-1.1 - User Login
#### TASK-010: Create Auth Entities (Test)
**File:** `test/domain/entities/user_test.dart`
- Test User entity creation
- Test equality
- Test copyWith
#### TASK-011: Create Auth Entities
**File:** `lib/domain/entities/user.dart`
```dart
@freezed
class User with _$User {
const factory User({
required String id,
required String username,
required String role,
}) = _User;
}
```
#### TASK-012: Create Auth Models (Test)
**File:** `test/data/models/auth_model_test.dart`
- Test JSON deserialization
- Test toEntity conversion
#### TASK-013: Create Auth Models
**File:** `lib/data/models/auth_model.dart`
```dart
@freezed
class AuthResponse with _$AuthResponse {
factory AuthResponse({
required String accessToken,
required String refreshToken,
required UserModel user,
}) = _AuthResponse;
factory AuthResponse.fromJson(Map<String, dynamic> json) =>
_$AuthResponseFromJson(json);
}
```
#### TASK-014: Create Secure Storage Manager (Test)
**File:** `test/data/data_sources/local/secure_storage_manager_test.dart`
- Test token storage
- Test token retrieval
- Test token deletion
#### TASK-015: Create Secure Storage Manager
**File:** `lib/data/data_sources/local/secure_storage_manager.dart`
```dart
@injectable
class SecureStorageManager {
final FlutterSecureStorage _storage;
Future<void> saveToken(String key, String token);
Future<String?> getToken(String key);
Future<void> deleteToken(String key);
Future<void> clearAll();
}
```
#### TASK-016: Create Auth Remote Data Source (Test)
**File:** `test/data/data_sources/remote/auth_remote_data_source_test.dart`
- Mock Dio client
- Test login API call
- Test error handling
#### TASK-017: Create Auth Remote Data Source
**File:** `lib/data/data_sources/remote/auth_remote_data_source.dart`
```dart
@injectable
class AuthRemoteDataSource {
final Dio _dio;
Future<AuthResponse> login(String username, String password);
Future<AuthResponse> refreshToken(String refreshToken);
}
```
#### TASK-018: Create Auth Repository (Test)
**File:** `test/data/repositories/auth_repository_impl_test.dart`
- Mock data sources
- Test login flow
- Test token storage
#### TASK-019: Create Auth Repository
**File:** `lib/data/repositories/auth_repository_impl.dart`
- Implement repository interface
- Coordinate data sources
- Handle errors with Either<Failure, T>
#### TASK-020: Create Login Use Case (Test)
**File:** `test/domain/use_cases/auth/login_test.dart`
- Mock repository
- Test successful login
- Test failed login
#### TASK-021: Create Login Use Case
**File:** `lib/domain/use_cases/auth/login.dart`
```dart
@injectable
class Login {
final AuthRepository repository;
Future<Either<Failure, User>> call(String username, String password);
}
```
#### TASK-022: Create Auth BLoC (Test)
**File:** `test/presentation/blocs/auth/auth_bloc_test.dart`
- Use bloc_test package
- Test all events and state transitions
- Mock use cases
#### TASK-023: Create Auth BLoC
**File:** `lib/presentation/blocs/auth/auth_bloc.dart`
```dart
@injectable
class AuthBloc extends Bloc<AuthEvent, AuthState> {
final Login login;
final RefreshToken refreshToken;
final Logout logout;
}
```
#### TASK-024: Create Login Screen (Widget Test)
**File:** `test/presentation/screens/auth/login_screen_test.dart`
- Test UI rendering
- Test form validation
- Test login button tap
#### TASK-025: Create Login Screen
**File:** `lib/presentation/screens/auth/login_screen.dart`
- Username and password fields
- Login button
- Loading state
- Error display
- BLoC integration
---
### Task Group: US-1.2 - Automatic Token Refresh
#### TASK-030: Create Auth Interceptor (Test)
**File:** `test/core/network/interceptors/auth_interceptor_test.dart`
- Test token injection
- Test 401 handling
- Test token refresh flow
#### TASK-031: Create Auth Interceptor
**File:** `lib/core/network/interceptors/auth_interceptor.dart`
```dart
class AuthInterceptor extends Interceptor {
@override
void onRequest(RequestOptions, RequestInterceptorHandler);
@override
void onError(DioException, ErrorInterceptorHandler);
}
```
---
## Phase 2: Server Management
### Task Group: US-2.1 - View All Servers
#### TASK-040: Create Server Entities
**Files:**
- `lib/domain/entities/server.dart`
- `lib/domain/entities/gcore_server.dart`
- `lib/domain/entities/geviscope_server.dart`
#### TASK-041: Create Server Models
**Files:**
- `lib/data/models/server_model.dart`
- Include JSON serialization
#### TASK-042: Create Server Remote Data Source
**File:** `lib/data/data_sources/remote/server_remote_data_source.dart`
```dart
@RestApi(baseUrl: '/api/v1/configuration')
abstract class ServerRemoteDataSource {
factory ServerRemoteDataSource(Dio dio) = _ServerRemoteDataSource;
@GET('/servers')
Future<ServerListResponse> getServers();
@GET('/servers/gcore')
Future<GCoreServerListResponse> getGCoreServers();
@GET('/servers/geviscope')
Future<GeViScopeServerListResponse> getGeViScopeServers();
}
```
#### TASK-043: Create Cache Manager
**File:** `lib/data/data_sources/local/cache_manager.dart`
- Implement Hive boxes
- Cache servers with expiration
- Cache action mappings
#### TASK-044: Create Server Repository
**File:** `lib/data/repositories/server_repository_impl.dart`
- Implement all server operations
- Cache-first strategy
- Error handling
#### TASK-045: Create Get Servers Use Case
**File:** `lib/domain/use_cases/servers/get_servers.dart`
#### TASK-046: Create Server BLoC
**File:** `lib/presentation/blocs/server/server_bloc.dart`
- Events: LoadServers, CreateServer, UpdateServer, DeleteServer
- States: Initial, Loading, Loaded, Error
#### TASK-047: Create Server List Screen
**File:** `lib/presentation/screens/servers/server_list_screen.dart`
- AppBar with title and actions
- ListView with ServerCard widgets
- Pull-to-refresh
- Search functionality
- Filter chips (All, G-Core, GeViScope)
- FAB for adding new server
#### TASK-048: Create Server Card Widget
**File:** `lib/presentation/widgets/server/server_card.dart`
- Display server alias, host, type
- Status indicator (enabled/disabled)
- Tap to view details
- Swipe actions (edit, delete)
---
### Task Group: US-2.4 - View Server Details
#### TASK-050: Create Server Detail Screen
**File:** `lib/presentation/screens/servers/server_detail_screen.dart`
- Display all server properties
- Edit and Delete buttons
- Connection status indicator
---
### Task Group: US-2.5/2.6 - Create Server
#### TASK-055: Create Server Form Screen
**File:** `lib/presentation/screens/servers/server_form_screen.dart`
- Use flutter_form_builder
- Dynamic form based on server type
- Validation
- Submit button with loading state
---
### Task Group: US-2.7 - Update Server
#### TASK-060: Create Update Server Use Case
**File:** `lib/domain/use_cases/servers/update_server.dart`
#### TASK-061: Update Server Form Screen
**File:** Same as TASK-055
- Pre-populate form with existing values
- Update mode vs create mode
---
### Task Group: US-2.8 - Delete Server
#### TASK-065: Create Delete Server Use Case
**File:** `lib/domain/use_cases/servers/delete_server.dart`
#### TASK-066: Add Delete Confirmation Dialog
**File:** `lib/presentation/widgets/common/confirmation_dialog.dart`
- Reusable confirmation dialog
- Customizable title and message
---
## Phase 3: Action Mapping Management
### Task Group: US-3.1/3.2 - View Action Mappings
#### TASK-070: Create Action Mapping Entities
**File:** `lib/domain/entities/action_mapping.dart`
```dart
@freezed
class ActionMapping with _$ActionMapping {
const factory ActionMapping({
required int id,
required String caption,
required Map<String, String> inputActions,
required List<OutputAction> outputActions,
}) = _ActionMapping;
}
@freezed
class OutputAction with _$OutputAction {
const factory OutputAction({
required String action,
required String caption,
String? server,
required Map<String, String> parameters,
}) = _OutputAction;
}
```
#### TASK-071: Create Action Mapping Models
**File:** `lib/data/models/action_mapping_model.dart`
#### TASK-072: Create Action Mapping Remote Data Source
**File:** `lib/data/data_sources/remote/action_mapping_remote_data_source.dart`
```dart
@RestApi(baseUrl: '/api/v1/configuration')
abstract class ActionMappingRemoteDataSource {
@GET('/action-mappings')
Future<List<ActionMappingModel>> getActionMappings();
@GET('/action-mappings/{id}')
Future<ActionMappingModel> getActionMapping(@Path() int id);
@POST('/action-mappings')
Future<void> createActionMapping(@Body() ActionMappingCreateRequest request);
@PUT('/action-mappings/{id}')
Future<void> updateActionMapping(
@Path() int id,
@Body() ActionMappingUpdateRequest request,
);
@DELETE('/action-mappings/{id}')
Future<void> deleteActionMapping(@Path() int id);
}
```
#### TASK-073: Create Action Mapping Repository
**File:** `lib/data/repositories/action_mapping_repository_impl.dart`
#### TASK-074: Create Action Mapping Use Cases
**Files:**
- `lib/domain/use_cases/action_mappings/get_action_mappings.dart`
- `lib/domain/use_cases/action_mappings/create_action_mapping.dart`
- `lib/domain/use_cases/action_mappings/update_action_mapping.dart`
- `lib/domain/use_cases/action_mappings/delete_action_mapping.dart`
#### TASK-075: Create Action Mapping BLoC
**File:** `lib/presentation/blocs/action_mapping/action_mapping_bloc.dart`
#### TASK-076: Create Action Mapping List Screen
**File:** `lib/presentation/screens/action_mappings/action_mapping_list_screen.dart`
#### TASK-077: Create Action Mapping Detail Screen
**File:** `lib/presentation/screens/action_mappings/action_mapping_detail_screen.dart`
---
### Task Group: US-3.3/3.4 - Create/Update Action Mapping
#### TASK-080: Create Action Mapping Form Screen
**File:** `lib/presentation/screens/action_mappings/action_mapping_form_screen.dart`
- Caption field
- Input parameter builder
- Add/remove parameters
- Key-value pairs
- Output action builder
- Action type selector
- Server selector
- Parameter configuration
- Add/remove actions
- Submit button
---
## Phase 4: Camera Management
### Task Group: US-4.1/4.2 - Camera List and Details
#### TASK-090: Create Camera Entities
**File:** `lib/domain/entities/camera.dart`
#### TASK-091: Create Camera Models
**File:** `lib/data/models/camera_model.dart`
#### TASK-092: Create Camera Remote Data Source
**File:** `lib/data/data_sources/remote/camera_remote_data_source.dart`
```dart
@RestApi(baseUrl: '/api/v1/cameras')
abstract class CameraRemoteDataSource {
@GET('')
Future<List<CameraModel>> getCameras();
@GET('/{id}')
Future<CameraModel> getCamera(@Path() String id);
}
```
#### TASK-093: Create Camera Repository
**File:** `lib/data/repositories/camera_repository_impl.dart`
#### TASK-094: Create Camera Use Cases
**Files:**
- `lib/domain/use_cases/cameras/get_cameras.dart`
- `lib/domain/use_cases/cameras/get_camera.dart`
#### TASK-095: Create Camera BLoC
**File:** `lib/presentation/blocs/camera/camera_bloc.dart`
#### TASK-096: Create Camera List Screen
**File:** `lib/presentation/screens/cameras/camera_list_screen.dart`
#### TASK-097: Create Camera Detail Screen
**File:** `lib/presentation/screens/cameras/camera_detail_screen.dart`
---
### Task Group: US-4.3 - PTZ Camera Control
#### TASK-100: Create PTZ Control Use Cases
**Files:**
- `lib/domain/use_cases/cameras/control_ptz.dart`
- Support all PTZ actions (pan, tilt, zoom, focus)
#### TASK-101: Create PTZ BLoC
**File:** `lib/presentation/blocs/ptz/ptz_bloc.dart`
#### TASK-102: Create Camera Control Screen
**File:** `lib/presentation/screens/cameras/camera_control_screen.dart`
- PTZ control pad widget
- Directional buttons (up, down, left, right)
- Zoom controls (+/-)
- Focus controls (near/far)
- Stop button
- Speed slider
- Preset selector
- Save preset button
#### TASK-103: Create PTZ Control Pad Widget
**File:** `lib/presentation/widgets/camera/ptz_control_pad.dart`
---
## Phase 5: Monitor & Cross-Switching
### Task Group: US-5.1/5.2 - Monitor Management
#### TASK-110: Create Monitor Entities
**File:** `lib/domain/entities/monitor.dart`
#### TASK-111: Create Monitor Models
**File:** `lib/data/models/monitor_model.dart`
#### TASK-112: Create Monitor Remote Data Source
**File:** `lib/data/data_sources/remote/monitor_remote_data_source.dart`
#### TASK-113: Create Monitor Repository
**File:** `lib/data/repositories/monitor_repository_impl.dart`
#### TASK-114: Create Monitor Use Cases
**Files:**
- `lib/domain/use_cases/monitors/get_monitors.dart`
- `lib/domain/use_cases/monitors/get_monitor.dart`
#### TASK-115: Create Monitor BLoC
**File:** `lib/presentation/blocs/monitor/monitor_bloc.dart`
#### TASK-116: Create Monitor List Screen
**File:** `lib/presentation/screens/monitors/monitor_list_screen.dart`
#### TASK-117: Create Monitor Detail Screen
**File:** `lib/presentation/screens/monitors/monitor_detail_screen.dart`
---
### Task Group: US-6.1/6.2 - Cross-Switching
#### TASK-120: Create Cross-Switch Use Cases
**Files:**
- `lib/domain/use_cases/crossswitch/connect_camera_to_monitor.dart`
- `lib/domain/use_cases/crossswitch/clear_monitor.dart`
#### TASK-121: Create Cross-Switch BLoC
**File:** `lib/presentation/blocs/crossswitch/crossswitch_bloc.dart`
#### TASK-122: Create Cross-Switch Screen
**File:** `lib/presentation/screens/crossswitch/crossswitch_screen.dart`
- Camera selector
- Monitor selector
- Preview of current assignments
- Connect button
- Clear button
---
## Phase 6: Configuration Management
### Task Group: US-7.1 - Export Configuration
#### TASK-130: Create Export Configuration Use Case
**File:** `lib/domain/use_cases/configuration/export_configuration.dart`
#### TASK-131: Add Export to Settings Screen
**File:** `lib/presentation/screens/settings/settings_screen.dart`
- Export button
- Save to file dialog
- Share option
---
### Task Group: US-7.2 - View Configuration Tree
#### TASK-135: Create Configuration Tree Screen
**File:** `lib/presentation/screens/configuration/configuration_tree_screen.dart`
- Expandable tree view
- Search functionality
- Node type indicators
---
## Phase 7: UI & Navigation
### Task Group: US-8.1 - App Navigation
#### TASK-140: Setup GoRouter
**File:** `lib/core/router/app_router.dart`
```dart
final router = GoRouter(
routes: [
GoRoute(
path: '/login',
builder: (context, state) => LoginScreen(),
),
GoRoute(
path: '/servers',
builder: (context, state) => ServerListScreen(),
),
// ... other routes
],
);
```
#### TASK-141: Create App Shell with Bottom Navigation
**File:** `lib/presentation/screens/app_shell.dart`
- Bottom navigation bar
- Side drawer
- Route management
---
### Task Group: US-8.2 - Settings Screen
#### TASK-145: Create Settings Screen
**File:** `lib/presentation/screens/settings/settings_screen.dart`
- API base URL configuration
- Theme selector
- Language selector
- Cache management
- About section
---
### Task Group: US-8.3/8.4 - Error Handling & Loading States
#### TASK-150: Create Common Widgets
**Files:**
- `lib/presentation/widgets/common/loading_widget.dart`
- Shimmer loading for lists
- Circular progress for buttons
- `lib/presentation/widgets/common/error_widget.dart`
- Error icon and message
- Retry button
- `lib/presentation/widgets/common/empty_state_widget.dart`
- Empty list message
- Illustration
---
## Phase 8: Testing & Polish
### Task Group: Comprehensive Testing
#### TASK-160 [P]: Write Unit Tests for All Use Cases
**Files:** `test/domain/use_cases/**/*_test.dart`
- Achieve 80%+ coverage
#### TASK-161 [P]: Write Widget Tests for All Screens
**Files:** `test/presentation/screens/**/*_test.dart`
#### TASK-162 [P]: Write Integration Tests
**Files:** `integration_test/app_test.dart`
- Login flow
- Server CRUD
- Action mapping CRUD
---
### Task Group: Performance Optimization
#### TASK-170: Implement List Pagination
**Files:** Update all list screens
- Infinite scroll
- Page size: 20 items
#### TASK-171: Optimize Image Loading
**Files:** Update image widgets
- Use cached_network_image
- Progressive loading
#### TASK-172: Implement Request Debouncing
**Files:** Update search fields
- Debounce duration: 300ms
---
### Task Group: Accessibility
#### TASK-175: Add Semantic Labels
**Files:** All widgets
- Proper semantic labels for screen readers
#### TASK-176: Test with Screen Reader
**Files:** N/A (manual testing)
#### TASK-177: Verify Contrast Ratios
**Files:** `lib/core/theme/colors.dart`
---
## Phase 9: Deployment Preparation
### Task Group: App Configuration
#### TASK-180: Configure App Icons
**File:** Run flutter_launcher_icons
#### TASK-181: Configure Splash Screen
**File:** Run flutter_native_splash
#### TASK-182: Update App Metadata
**Files:**
- `android/app/src/main/AndroidManifest.xml`
- `ios/Runner/Info.plist`
---
### Task Group: Build & Release
#### TASK-185: Create Release Build (Android)
```bash
flutter build apk --release
flutter build appbundle --release
```
#### TASK-186: Create Release Build (iOS)
```bash
flutter build ipa --release
```
---
## Dependencies Between Tasks
```
Foundation Tasks (001-005) → All other tasks
Authentication:
010-011 → 012-013 → 014-015 → 016-017 → 018-019 → 020-021 → 022-023 → 024-025
030-031 (depends on 022-023)
Servers:
040-041 → 042-043 → 044 → 045 → 046 → 047-048
050 (depends on 046)
055 (depends on 046)
060-061 (depends on 046)
065-066 (depends on 046)
Action Mappings:
070-071 → 072 → 073 → 074 → 075 → 076-077
080 (depends on 075)
Cameras:
090-091 → 092 → 093 → 094 → 095 → 096-097
100-103 (depends on 095)
Monitors:
110-111 → 112 → 113 → 114 → 115 → 116-117
Cross-Switching:
120-122 (depends on 095 and 115)
Configuration:
130-131
135
Navigation:
140-141 (depends on all screens being created)
Settings:
145
Common Widgets:
150 (can be done in parallel, used by many screens)
Testing:
160-162 (depends on all implementations)
Performance:
170-172 (depends on screens)
Accessibility:
175-177 (depends on all widgets)
Deployment:
180-186 (depends on everything)
```
## Parallel Execution Opportunities
Tasks marked with `[P]` can be executed in parallel:
- TASK-001, 002, 004, 005 (setup tasks)
- TASK-160, 161, 162 (testing can be distributed)
Multiple developers can work on different epics simultaneously once foundation is complete.