lib/
├── core/ # Core functionality and utilities
├── features/ # Feature-specific implementations
├── models/ # Data models and state management
├── screens/ # UI screens and widgets
├── services/ # Service layer implementations
│ ├── knowledge_graph/ # Knowledge graph components
│ ├── library/ # ZIM library management
│ ├── payment/ # Payment processing
│ └── sync/ # Offline sync and queue management
└── themes/ # Theme and styling definitions
- Snake case for files:
download_manager.dart - Pascal case for classes:
DownloadManager - Camel case for variables and functions:
downloadFile() - Knowledge graph entities:
EntityTypeName - Test files:
*_test.dart
- Use strong-mode analysis
- Enable and respect all lint rules in
analysis_options.yaml - Maximum line length: 80 characters
- Use meaningful variable names
- Implement error handling for all async operations
- Use const constructors when possible
- Prefer final variables
- Entity names must be unique and descriptive
- Relationships should use active voice
- Include metadata for all entities
- Document relationship types
- Implement healing strategies
- Use typed relationships
- Cache graph queries appropriately
- Achievement IDs follow pattern:
category_achievement_name - Knowledge nudges must be non-intrusive
- Social sharing respects privacy settings
- Achievement triggers must be measurable
- Implement cooldown periods for notifications
- Document gamification elements
- Track engagement metrics
- Always queue operations that modify data when offline
- Use the SyncManager for all network-dependent operations
- Implement proper error handling and retry mechanisms
- Provide clear feedback about sync status to users
- Use Drift for structured data storage
- Implement proper encryption for sensitive data
- Cache images and heavy content for offline use
- Clean up old cached data periodically
- Show offline status clearly in the UI
- Provide feedback for queued operations
- Handle errors gracefully with user-friendly messages
- Support seamless online/offline transitions
- Every public API must have dartdoc comments
- Include code examples in complex functions
- Document state management decisions
- Add TODO comments with ticket numbers
- Knowledge graph changes must be documented
- Document engagement triggers
- Include metrics for features
- Unit tests for all business logic
- Widget tests for UI components
- Integration tests for critical flows
- Graph consistency tests
- Achievement trigger tests
- Engagement metric tests
- Maintain 80%+ code coverage
- Use Provider for simple state
- Bloc pattern for complex state
- Keep state close to where it's used
- Document state flow in comments
- Graph state management
- Achievement state tracking
- Engagement state monitoring
- Use Result type for operations
- Log all errors with context
- User-friendly error messages
- Graceful degradation
- Graph consistency errors
- Achievement tracking errors
- Network resilience
- Lazy load when possible
- Cache appropriately
- Minimize rebuilds
- Profile regularly
- Optimize graph queries
- Batch achievement updates
- Monitor engagement metrics
The app supports the following Android architectures:
-
ARM64 (arm64-v8a)
- Primary architecture for modern Android devices
- Optimized for performance and energy efficiency
- Used in most current smartphones and tablets
-
ARM32 (armeabi-v7a)
- Legacy support for older ARM devices
- Ensures compatibility with budget devices
- Important for accessibility in developing markets
-
x86_64
- Support for Intel/AMD 64-bit processors
- Used in Android emulators and some tablets
- Important for development and testing
-
x86
- Legacy Intel/AMD 32-bit support
- Maintains compatibility with older x86 devices
- Used in some older tablets and development environments
- ARM64
- Modern iOS devices
- Optimized for Apple Silicon
- Windows: x86_64
- macOS: ARM64, x86_64
- Linux: x86_64, ARM64
- Split APKs enabled for optimized downloads
- Universal APK available for broader compatibility
- Play Store will serve the appropriate version based on device architecture
- Feature branches from master
- Conventional commits
- PR reviews required
- Squash merge to master
- Document knowledge graph changes
- Track engagement feature additions
- Custom ZIM parser implementation instead of using existing libraries
- Flutter-specific architecture patterns
- Offline-first approach affecting state management
- Custom knowledge graph implementation
- Engagement system architecture
-
Documentation Style: All documentation will follow the Google Developer Documentation Style Guide.
-
Code Style: Dart code will adhere to the Effective Dart style guide.
-
Commit Messages: Commit messages should follow the Conventional Commits specification.
-
Branching Strategy: We will use a simplified version of Gitflow, with
mainrepresenting the production-ready code and feature branches for new development.
- Currently, there are no deviations from the all-project SOPs.
These conventions are designed to ensure code consistency, readability, and maintainability. They support our vision by promoting collaboration and knowledge sharing.