You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
-`lib/` holds app code: `core/` for shared services, `features/` for UI flows, `hive/` for adapters, and entry points in `main.dart`, `main_development.dart`, and `classipod_app.dart`.
5
+
- Platform scaffolding lives in `android/`, `ios/`, `linux/`, `macos/`, `windows/`, and `web/`; assets and fonts sit in `assets/`; automation scripts live in `fastlane/` and `scripts/`.
6
+
- Tests mirror production code under `test/unit_tests/` and `test/widget_tests/`, with reusable fixtures in `test/test_files/` and caches in `test/cache/`.
7
+
8
+
## Build, Test, and Development Commands
9
+
-`flutter pub get --suppress-analytics` refreshes dependencies after any `pubspec.yaml` change.
10
+
-`flutter pub run build_runner build --delete-conflicting-outputs` regenerates Hive TypeAdapters before building.
11
+
-`flutter gen-l10n` keeps `lib/l10n/` synced with `l10n.yaml`.
12
+
-`flutter analyze --suppress-analytics` or `dart run custom_lint` must be clean prior to committing.
13
+
- Format with `flutter format --set-exit-if-changed lib/ test/`.
14
+
-`flutter test --no-pub --coverage --suppress-analytics` is the required test invocation; upload `coverage/lcov.info` when CI or reviewers ask.
15
+
- Release builds are standardized through Fastlane, e.g. `bundle exec fastlane build_flutter_app type:apk` (swap `ipa`, `appbundle`, etc. as needed).
- Use `snake_case.dart` filenames, `UpperCamelCase` for classes, and suffix Riverpod notifiers/controllers (`PlaybackController`, `LibraryNotifier`) inside `lib/features/`.
20
+
- Factor reusable UI into `lib/core/widgets/`, include trailing commas, and avoid relative imports (`../`) entirely.
21
+
22
+
## Testing Guidelines
23
+
- Store pure logic specs in `test/unit_tests/` and widget scenarios in `test/widget_tests/`, mirroring the folder layout under `lib/features/`.
24
+
- Name every file `_test.dart`, group cases by behavior (`group('cover_flow', ...)`), and prefer golden tests for UI regressions.
25
+
- Maintain coverage by extending suites whenever playback, persistence, or routing code changes; reuse fixtures from `test/test_files/` instead of adding new binaries.
26
+
27
+
## Commit & Pull Request Guidelines
28
+
- Match the existing history with emoji-prefixed, present-tense commits such as `🐛 fix thumbnail path` or `✨ add coverflow filter`, referencing issues (`fixes #51`) when applicable.
29
+
- Complete the checklist in `pull_request_template.md`, note platform verification (Android/Windows/Web), and include before/after screenshots for UI work.
30
+
- Summarize any Fastlane or build-runner commands you ran so reviewers can reproduce the environment.
31
+
32
+
## Security & Configuration Tips
33
+
- Keep store credentials and service accounts outside the repo; point Fastlane to them via environment variables like `GOOGLE_SERVICE_ACCOUNT_JSON_PATH`.
34
+
- When bumping dependencies or assets, cross-check platform builds and update `CHANGELOG.md` alongside the code change.
This document provides a comprehensive overview of the ClassiPod project, including its purpose, architecture, and development conventions.
4
+
5
+
## Project Overview
6
+
7
+
ClassiPod is a local music player app designed to emulate the nostalgic experience of the iPod Classic. It features a click wheel interface and focuses on providing a simple, distraction-free music listening experience. The app is built with Flutter and supports Android, iOS, Linux, macOS, Windows, and web.
flutter run --flavor dev --target=lib/main_development.dart
34
+
```
35
+
36
+
### Testing
37
+
38
+
The project includes unit and widget tests. To run the tests, use the following command:
39
+
40
+
```bash
41
+
flutter test
42
+
```
43
+
44
+
The project also has a GitHub Actions workflow that runs the tests on every pull request.
45
+
46
+
## Development Conventions
47
+
48
+
The project follows a strict set of development conventions to ensure code quality and consistency.
49
+
50
+
### Coding Style
51
+
52
+
The project uses the linting rules defined in the `analysis_options.yaml` file. These rules enforce a consistent coding style and help to prevent common errors. Some of the key style guidelines include:
53
+
54
+
* Always declarereturn types.
55
+
* Always use package imports.
56
+
* Avoid relative lib imports.
57
+
* Use `const` constructors where possible.
58
+
* Require trailing commas.
59
+
* Sort pub dependencies.
60
+
61
+
### Contribution Guidelines
62
+
63
+
The `CONTRIBUTING.md` file provides detailed instructions for contributing to the project. Key guidelines include:
64
+
65
+
* Discuss changes via an issue before making a pull request.
66
+
* Follow the code of conduct.
67
+
* Provide clear and detailed bug reports and feature requests.
68
+
69
+
## Architecture
70
+
71
+
The project follows a feature-based architecture, with each feature located in its own directory under `lib/features`. The core functionality is located in the `lib/core` directory.
72
+
73
+
### Routing
74
+
75
+
The app uses the `go_router` package forrouting. The routes are definedin the `lib/core/navigation/routes.dart` file. The `Routes` enum provides a type-safe way to navigate between screens.
76
+
77
+
### State Management
78
+
79
+
The app uses the `flutter_riverpod` package for state management. Providers are used to manage the state of the app and to provide dependencies to widgets.
80
+
81
+
### CI/CD
82
+
83
+
The project uses GitHub Actions for CI/CD. The `.github/workflows` directory contains two workflows:
84
+
85
+
*`pr-checker.yaml`: This workflow runs on every pull request and checks for linting errors and runs the tests.
86
+
*`build-and-deploy.yaml`: This workflow is triggered manually and can build and deploy the app for Android, Linux, Windows, and the web.
0 commit comments