```markdown # PRD.md ## 1. Introduction This document outlines the Product Requirements for a mobile Task Management Application. The primary goal is to provide users with a simple and effective tool to manage their daily tasks, organize them into categories, receive timely reminders, and track their productivity. The application aims to solve the common problem of forgetting tasks by offering a centralized platform with notification capabilities. ## 2. Objectives * Develop a user-friendly mobile application for task management. * Allow users to create, view, edit, and delete tasks. * Enable task organization using folders or categories. * Implement due date functionality with push notification reminders. * Provide users with basic statistics on task completion. * Ensure data persistence and synchronization across user sessions (assuming a single device initially, but designed for potential cloud sync). ## 3. Target Audience Individuals who need assistance organizing personal or work-related tasks, students managing assignments, or anyone looking for a simple digital tool to improve productivity and task recall. Users are expected to be comfortable using standard mobile applications. ## 4. Scope **In Scope:** * User account creation and login (local or simple email/password). * CRUD operations for Tasks (Create, Read, Update, Delete). * CRUD operations for Folders (Create, Read, Update, Delete). * Assigning tasks to folders. * Setting due dates and times for tasks. * Local push notifications for task reminders based on due dates. * Marking tasks as complete/incomplete. * Viewing tasks by list (all, by folder, by due date - today/upcoming). * Displaying a simple weekly count of completed tasks. **Out of Scope:** * Cloud synchronization across multiple devices. * Advanced collaboration features (sharing tasks/folders). * Recurring tasks. * Subtasks. * Priority levels beyond due dates. * Advanced reporting or analytics beyond weekly completion count. * Calendar integration. * Web or desktop versions. ## 5. User Stories * **US001:** As a user, I want to create an account or log in so that my tasks are saved securely. * **US002:** As a user, I want to add a new task with a title, optional description, and optional due date so that I can capture what needs to be done. * **US003:** As a user, I want to view a list of all my tasks so that I can see what I need to do. * **US004:** As a user, I want to mark a task as complete so that I can track my progress. * **US005:** As a user, I want to edit an existing task (title, description, due date, folder) so that I can update its details. * **US006:** As a user, I want to delete a task I no longer need. * **US007:** As a user, I want to create folders (e.g., "Work", "Home") so that I can categorize my tasks. * **US008:** As a user, I want to assign a task to a specific folder when creating or editing it. * **US009:** As a user, I want to view tasks filtered by a specific folder. * **US010:** As a user, I want to receive a push notification on my phone when a task's due date/time arrives so that I don't forget it. * **US011:** As a user, I want to see a simple count of how many tasks I completed in the current week so that I can gauge my productivity. * **US012:** As a user, I want to manage my folders (rename, delete). ## 6. Functional Requirements * **FR001: User Authentication:** * The system must allow users to register with an email and password. * The system must allow registered users to log in. * User session should persist locally. * **FR002: Task Creation:** * The system must provide an interface to create a new task. * Required field: Task Title (string, max 255 chars). * Optional fields: Description (text), Due Date (Date & Time), Folder ID (reference). * Newly created tasks default to 'incomplete'. * **FR003: Task Viewing:** * The system must display a list of tasks. * Default view should show incomplete tasks, possibly sorted by due date. * Users must be able to filter tasks by folder. * Users must be able to view completed tasks (perhaps in a separate section or via a filter). * Task list items should display title, due date (if set), and associated folder (if set). * **FR004: Task Update:** * The system must allow users to modify the title, description, due date, and folder assignment of an existing task. * The system must allow users to toggle the completion status of a task (complete/incomplete). * **FR005: Task Deletion:** * The system must allow users to permanently delete a task. A confirmation prompt should be considered. * **FR006: Folder Management:** * The system must allow users to create named folders. * The system must allow users to rename existing folders. * The system must allow users to delete folders. Deleting a folder should handle associated tasks (e.g., unassign them or prompt the user). Default: Unassign tasks from the deleted folder. * **FR007: Notifications:** * The system must schedule a local push notification for tasks with a set due date and time. * The notification should trigger at the specified due date/time. * The notification content should include the task title. * Tapping the notification should ideally open the app, potentially highlighting the relevant task. * **FR008: Statistics:** * The system must calculate and display the total number of tasks marked as completed within the current calendar week (e.g., Monday-Sunday or Sunday-Saturday). * This statistic should be displayed in a dedicated section or dashboard area. ## 7. Non-Functional Requirements * **NFR001: Platform:** The application must run on iOS and Android mobile platforms. * **NFR002: Performance:** The application UI must be responsive. Task list loading and filtering should be near-instantaneous for typical user data volumes (< 1000 tasks). * **NFR003: Usability:** The application must have a clean, intuitive, and simple user interface suitable for non-technical users. Core actions (add task, view list, mark complete) must be easily accessible. * **NFR004: Reliability:** Task data must be persisted locally on the device. Notifications must trigger reliably even if the app is not in the foreground. * **NFR005: Storage:** Local storage (e.g., SQLite, Realm, or platform-specific storage) must be used to store user data (tasks, folders). * **NFR006: Security:** If email/password auth is used, passwords must be stored securely (hashed). Local data should be stored within the app's sandboxed storage. * **NFR007: Maintainability:** Code should follow standard conventions and architectural patterns for the chosen technology stack to facilitate future updates. ## 8. Data Model * **User:** `user_id` (PK), `email`, `password_hash`, `created_at` * **Folder:** `folder_id` (PK), `user_id` (FK), `name` (string, unique per user), `created_at` * **Task:** `task_id` (PK), `user_id` (FK), `folder_id` (FK, nullable), `title` (string, not null), `description` (text, nullable), `due_date` (datetime, nullable), `is_completed` (boolean, default: false), `created_at` (datetime), `completed_at` (datetime, nullable) ## 9. Release Criteria * All defined User Stories (US001-US012) are implemented and pass testing. * Core functionality (CRUD tasks/folders, notifications, stats) operates reliably on target platforms. * No critical or major bugs identified in testing. * Application meets basic performance and usability NFRs. ``` ```markdown # frontend_guidelines.md ## 1. Overview This document provides guidelines for the frontend development of the Task Management Mobile Application. The target platforms are iOS and Android. A cross-platform framework like React Native or Flutter is recommended for efficiency, but native development is also an option. Guidelines assume a cross-platform approach using Flutter with the Provider/Riverpod package for state management, but principles can be adapted. ## 2. UI Architecture * **Pattern:** Model-View-ViewModel (MVVM) or a similar state management pattern like BLoC/Cubit (Flutter) or Provider/Riverpod (Flutter). * **Model:** Represents the data structures (Task, Folder). Resides in the data layer. * **View:** Represents the UI components (Screens, Widgets). Stateless widgets are preferred, reacting to state changes from the ViewModel/Provider. * **ViewModel/Provider/Bloc:** Manages the state for the View, handles user interactions, fetches data from repositories, and exposes streams/notifiers for the View to listen to. * **Separation of Concerns:** UI logic should be strictly separated from business logic and data access logic. ViewModels/Providers should not contain platform-specific UI code. ## 3. Component Library & Styling * **UI Toolkit:** Use the standard widgets provided by the chosen framework (e.g., Flutter's Material or Cupertino widgets, React Native's core components). * **Consistency:** Maintain a consistent visual style across the application. Define a primary color palette, typography (font sizes, weights), and spacing rules in a central theme file (`theme.dart` in Flutter). * **Key Components:** * `TaskListScreen`: Displays the list of tasks, includes filtering/sorting options. * `TaskListItem`: Widget representing a single task in the list (shows title, due date, checkbox, folder indicator). * `TaskDetailScreen`: Displays full task details, allows editing. * `TaskEditForm`: Form for creating/editing tasks (input fields for title, description, date picker, folder selector). * `FolderListScreen`: Displays list of folders, allows management (add, rename, delete). * `FolderListItem`: Widget representing a single folder. * `StatsScreen`: Displays the weekly completion count. * `AuthScreen`: Handles user login/registration forms. * `AppLayout/Scaffold`: Consistent app bar, navigation (e.g., Bottom Navigation Bar or Drawer). * **Responsiveness:** While primarily phone-focused, ensure layouts adapt reasonably to different screen sizes and orientations where applicable (e.g., using `LayoutBuilder`, `MediaQuery` in Flutter). ## 4. State Management * **Strategy:** Utilize a central state management solution (e.g., Provider, Riverpod, BLoC/Cubit for Flutter; Context API/Redux/Zustand for React Native; ViewModel/LiveData/StateFlow for Android Native; SwiftUI State/Combine for iOS Native). * **Scope:** State should be scoped appropriately (e.g., global state for user authentication, screen-level state for UI controls, feature-level state for task/folder data). * **Immutability:** Prefer immutable state updates where possible to simplify state management and improve predictability. * **Data Flow:** Maintain a unidirectional data flow (e.g., UI triggers action -> ViewModel/Provider updates state -> UI rebuilds based on new state). ## 5. Routing and Navigation * **Strategy:** Implement a clear navigation system. Use a dedicated routing package (e.g., `Navigator 2.0` or `go_router` for Flutter, `React Navigation` for React Native). * **Routes:** Define named routes for all major screens: * `/auth` * `/taskList` (Home screen) * `/taskDetail/{taskId}` * `/taskEdit/{taskId}` (or `/taskAdd`) * `/folders` * `/stats` * **Transitions:** Use standard platform transitions unless custom animations add significant value. ## 6. Design Patterns * **Repository Pattern:** Abstract data access logic behind repository interfaces. ViewModels/Providers interact with repositories, not directly with data sources (local DB, API). * **Dependency Injection:** Use DI (e.g., `get_it` or Provider/Riverpod's built-in capabilities in Flutter) to provide dependencies like repositories, services (e.g., NotificationService) to ViewModels/Providers. * **Observer Pattern:** State management solutions typically implement this pattern (e.g., `ChangeNotifierProvider`, `StreamProvider`, `BlocBuilder` in Flutter) for Views to react to state changes. ## 7. Assets * Optimize images and icons for mobile use. * Use vector icons (e.g., Material Icons, FontAwesome) where possible for scalability. * Manage assets clearly within the project structure (e.g., `assets/images`, `assets/icons`). ## 8. Error Handling * Display user-friendly error messages for common issues (e.g., invalid input, failed data saving). * Use mechanisms like Snackbars, Dialogs, or inline error text. * Log detailed errors for debugging purposes. ``` ```markdown # backend_structure.md ## 1. Overview This document outlines the backend structure for the Task Management Mobile Application. Given the requirements (single-user focus, basic features, mobile platform), a Backend-as-a-Service (BaaS) like Firebase or Supabase is highly recommended to handle authentication, database, and potentially notifications with minimal custom backend code. Alternatively, if a custom backend is required, a simple REST API built with a lightweight framework (e.g., Node.js/Express, Python/Flask, Go/Gin) connected to a relational database (e.g., PostgreSQL, SQLite) would suffice. This document primarily describes the structure assuming a **BaaS (Firebase/Supabase)** approach, focusing on the data model and core logic interactions. If a custom backend were built, API endpoints would map closely to the described functionalities. ## 2. Architecture * **Type:** Backend-as-a-Service (BaaS) - e.g., Firebase Firestore/Realtime Database or Supabase (PostgreSQL). * **Key Services:** * **Authentication:** Managed by BaaS (Firebase Auth, Supabase Auth) - Handles email/password sign-up, login, session management. * **Database:** Managed by BaaS (Firestore, Supabase DB) - Stores user data, tasks, and folders. Realtime capabilities are beneficial for UI updates. * **Cloud Functions/Edge Functions (Optional):** For server-side logic if needed (e.g., complex validation, data aggregation not suitable for client-side). Not strictly required for core functionality described. * **Push Notifications:** While local notifications are specified, BaaS could facilitate future cloud-based notifications if needed (e.g., Firebase Cloud Messaging). For local-only, this is handled client-side. ## 3. Database Schema * **Database Type:** NoSQL (like Firestore) or Relational (like PostgreSQL via Supabase). Schema below assumes relational for clarity, adaptable to NoSQL collections/documents. * **Tables/Collections:** * **`users`** * `user_id` (PK, String/UUID - often managed by BaaS Auth) * `email` (String, Unique) * `created_at` (Timestamp) * *(Password hash managed by BaaS Auth service)* * **`folders`** * `folder_id` (PK, UUID) * `user_id` (FK referencing `users.user_id`, Indexed) * `name` (String, Not Null) * `created_at` (Timestamp) * *(Constraint: `user_id` + `name` should be unique)* * **`tasks`** * `task_id` (PK, UUID) * `user_id` (FK referencing `users.user_id`, Indexed) * `folder_id` (FK referencing `folders.folder_id`, Nullable) * `title` (String, Not Null, Max 255 chars) * `description` (Text, Nullable) * `due_date` (Timestamp, Nullable, Indexed) * `is_completed` (Boolean, Default: `false`, Indexed) * `created_at` (Timestamp) * `completed_at` (Timestamp, Nullable) * *(Indexes recommended on `user_id`, `due_date`, `is_completed` for efficient querying)* * **Relationships:** * One User has many Folders. * One User has many Tasks. * One Folder can contain many Tasks (or Task has one optional Folder). ## 4. Authentication Flow 1. **Registration:** * Client collects email/password. * Client calls BaaS Auth service (`createUserWithEmailAndPassword`). * On success, BaaS creates the user record and returns user info (including `user_id`). * Client may optionally create a corresponding document in the `users` collection if additional profile data is needed beyond what Auth provides. 2. **Login:** * Client collects email/password. * Client calls BaaS Auth service (`signInWithEmailAndPassword`). * On success, BaaS returns user info and establishes a session (e.g., JWT token). * Client stores session info securely and uses it for subsequent requests. 3. **Session Management:** * BaaS SDKs typically handle token refresh and session persistence automatically. * Database access rules must be configured to ensure users can only access their own data (`user_id` based rules). ## 5. Business Logic & Data Access * **Location:** Primarily resides within the mobile application's data layer (Repositories) interacting directly with the BaaS SDKs. * **Data Validation:** Basic validation (e.g., required fields, length limits) should occur on the client-side before sending data to the BaaS. More critical validation can be enforced using Database Security Rules (e.g., ensuring `user_id` matches the authenticated user). * **Database Queries (Examples):** * Fetch incomplete tasks for user: `SELECT * FROM tasks WHERE user_id = ? AND is_completed = false ORDER BY due_date ASC` * Fetch tasks in a specific folder: `SELECT * FROM tasks WHERE user_id = ? AND folder_id = ?` * Fetch folders for user: `SELECT * FROM folders WHERE user_id = ? ORDER BY name ASC` * Count completed tasks this week: `SELECT COUNT(*) FROM tasks WHERE user_id = ? AND is_completed = true AND completed_at >= start_of_week AND completed_at <= end_of_week` (Date range calculation done client-side or via DB function if available). * **Security Rules (Crucial for BaaS):** * Define rules in the BaaS console (e.g., Firestore Security Rules, Supabase Row Level Security Policies). * Ensure users can only read/write their own tasks and folders (match `request.auth.uid == resource.data.user_id`). * Validate data types and required fields where possible within the rules. ## 6. API Endpoints (Conceptual - Handled by BaaS SDKs) If a custom REST API were built, endpoints would align with CRUD operations: * `POST /auth/register` * `POST /auth/login` * `GET /tasks?folderId={id}&completed={bool}&sortBy=dueDate` * `POST /tasks` (Body: { title, description?, dueDate?, folderId? }) * `GET /tasks/{taskId}` * `PUT /tasks/{taskId}` (Body: fields to update) * `DELETE /tasks/{taskId}` * `GET /folders` * `POST /folders` (Body: { name }) * `PUT /folders/{folderId}` (Body: { name }) * `DELETE /folders/{folderId}` * `GET /stats/weekly-completed` **Note:** With BaaS, these operations are performed using the provided SDK methods (e.g., `firestore.collection('tasks').add(...)`, `supabase.from('tasks').select('*').eq('user_id', userId)`). ``` ```markdown # app_flow.md ## 1. Overview This document describes the primary user flows, state transitions, and error handling mechanisms within the Task Management Mobile Application. ## 2. User Flows ### 2.1. Onboarding & Authentication Flow 1. **App Launch:** * **State:** Initializing. * **Action:** Check for existing valid user session (e.g., stored token/session info). * **Transition:** * If valid session exists -> Go to Main App Flow (Task List). * If no valid session -> Go to Authentication Screen. 2. **Authentication Screen (Login/Register View):** * **State:** Awaiting authentication. * **User Action (Login):** Enters email/password, taps "Login". * **Action:** Call Authentication Service (`signInWithEmailAndPassword`). * **Transition:** * On Success -> Store session, navigate to Main App Flow (Task List). * On Failure (invalid credentials, network error) -> Display error message on Auth Screen. * **User Action (Register):** Taps "Register", enters email/password, taps "Register". * **Action:** Call Authentication Service (`createUserWithEmailAndPassword`). * **Transition:** * On Success -> Store session, navigate to Main App Flow (Task List). * On Failure (email exists, weak password, network error) -> Display error message on Auth Screen. ### 2.2. Main Task Management Flow 1. **View Task List:** * **State:** Displaying Task List Screen (Default: Incomplete tasks, sorted by due date). * **Action:** Fetch tasks for the logged-in user from the Repository/BaaS. Listen for real-time updates if applicable. * **User Action (Add Task):** Taps "Add Task" button. * **Transition:** Navigate to Task Add/Edit Screen (in 'Add' mode). * **User Action (Tap Task):** Taps on a specific task item. * **Transition:** Navigate to Task Detail Screen (passing `taskId`). * **User Action (Mark Complete):** Taps the checkbox on a task item. * **Action:** Update task status (`is_completed = true`, set `completed_at`) via Repository/BaaS. * **Transition:** UI updates (task may move/change appearance). Update weekly stats count implicitly. * **User Action (Filter/Sort):** Uses filter controls (e.g., select folder, view completed). * **Action:** Re-fetch/filter tasks based on selected criteria. * **Transition:** Task list updates in place. * **User Action (Navigate):** Taps navigation element (e.g., Folders tab/icon, Stats tab/icon). * **Transition:** Navigate to Folder List Screen or Stats Screen. 2. **Add/Edit Task:** * **State:** Displaying Task Add/Edit Screen (populated with task data if editing). * **User Action (Input Data):** Enters/modifies title, description, selects due date (via date/time picker), selects folder (via dropdown/modal). * **User Action (Save):** Taps "Save" button. * **Action:** Perform client-side validation (e.g., title not empty). * **Action:** Call Repository/BaaS to create or update the task. * **Transition:** * On Success -> Navigate back to Task List Screen (list should refresh). * On Failure (validation error, network error) -> Display error message on Add/Edit Screen. * **User Action (Cancel/Back):** Taps "Cancel" or back navigation. * **Transition:** Navigate back to the previous screen (Task List or Detail) without saving changes (confirm if changes were made). 3. **View Task Detail:** * **State:** Displaying Task Detail Screen with data for a specific `taskId`. * **Action:** Fetch full task details from Repository/BaaS. * **User Action (Edit):** Taps "Edit" button. * **Transition:** Navigate to Task Add/Edit Screen (in 'Edit' mode, passing `taskId`). * **User Action (Delete):** Taps "Delete" button. * **Action:** Show confirmation dialog. * **Action (Confirm Delete):** Call Repository/BaaS to delete the task. * **Transition:** Navigate back to Task List Screen (list should refresh). * **User Action (Mark Complete/Incomplete):** Taps toggle/checkbox. * **Action:** Update task status via Repository/BaaS. * **Transition:** UI updates in place. Navigate back to Task List or stay on detail view reflecting change. ### 2.3. Folder Management Flow 1. **View Folder List:** * **State:** Displaying Folder List Screen. * **Action:** Fetch folders for the logged-in user from Repository/BaaS. * **User Action (Add Folder):** Taps "Add Folder" button/icon. * **Action:** Show dialog/input field for new folder name. * **Action (Save New):** Call Repository/BaaS to create the folder. Handle potential name conflicts. * **Transition:** Folder list updates. Display success/error message. * **User Action (Select Folder):** Taps on a folder item. * **Transition:** Navigate to Task List Screen, filtered by the selected folder. * **User Action (Edit Folder):** Taps "Edit" icon on a folder item. * **Action:** Show dialog/input field pre-filled with the current folder name. * **Action (Save Edit):** Call Repository/BaaS to update the folder name. Handle potential name conflicts. * **Transition:** Folder list updates. Display success/error message. * **User Action (Delete Folder):** Taps "Delete" icon on a folder item. * **Action:** Show confirmation dialog (mentioning task handling - e.g., "Tasks in this folder will be unassigned"). * **Action (Confirm Delete):** Call Repository/BaaS to delete the folder. Update associated tasks (`folder_id = null`). * **Transition:** Folder list updates. ### 2.4. View Statistics Flow 1. **View Stats Screen:** * **State:** Displaying Stats Screen. * **Action:** Fetch tasks completed within the current week (based on `completed_at` timestamp) from Repository/BaaS. Calculate the count. * **Transition:** Display the calculated count (e.g., "You completed X tasks this week!"). ## 3. State Transitions (Summary) * **`Initializing`** -> (`Authenticated`) -> `TaskList` * **`Initializing`** -> (`Not Authenticated`) -> `Authentication` * **`Authentication`** -> (`Login/Register Success`) -> `TaskList` * **`Authentication`** -> (`Login/Register Failure`) -> `Authentication` (with error) * **`TaskList`** -> (`Tap Add`) -> `TaskAddEdit` * **`TaskList`** -> (`Tap Task`) -> `TaskDetail` * **`TaskList`** -> (`Navigate Folders`) -> `FolderList` * **`TaskList`** -> (`Navigate Stats`) -> `Stats` * **`TaskAddEdit`** -> (`Save Success`) -> `TaskList` * **`TaskAddEdit`** -> (`Save Failure`) -> `TaskAddEdit` (with error) * **`TaskAddEdit`** -> (`Cancel/Back`) -> `TaskList` / `TaskDetail` * **`TaskDetail`** -> (`Tap Edit`) -> `TaskAddEdit` * **`TaskDetail`** -> (`Delete Success`) -> `TaskList` * **`FolderList`** -> (`Select Folder`) -> `TaskList` (filtered) * **`FolderList`** -> (`Navigate Back`) -> `TaskList` (or previous screen) ## 4. Error Handling & Edge Cases * **Network Errors:** Display a non-intrusive indicator (e.g., Snackbar) when BaaS operations fail due to network issues. Allow user to retry actions where appropriate. Cache data locally for offline viewing if possible (though editing might be disabled offline). * **Authentication Errors:** Provide clear feedback on the Auth screen (e.g., "Invalid email or password", "Email already exists"). * **Validation Errors:** Display inline errors on forms (e.g., "Title cannot be empty") before attempting to save. * **Data Sync Conflicts (Less likely with BaaS/single device focus):** If cloud sync were added, implement a conflict resolution strategy (e.g., last write wins). * **Notification Permissions:** Prompt the user for notification permissions at an appropriate time (e.g., when they first set a due date). Handle cases where permission is denied gracefully (inform the user notifications won't work). * **Folder Deletion:** Clearly communicate the impact on tasks within the folder being deleted. Ensure tasks are correctly updated (e.g., `folder_id` set to null). * **Empty States:** Provide informative messages when lists are empty (e.g., "No tasks yet. Tap '+' to add one!", "No folders created."). ``` ```markdown # tech_stack.md ## 1. Overview This document outlines the recommended technology stack for building the Task Management Mobile Application, targeting iOS and Android platforms. The choices prioritize development speed, ease of use for core features (auth, DB, notifications), and maintainability. ## 2. Platform Target * **Primary:** Mobile (iOS and Android) ## 3. Frontend (Mobile App) * **Framework Recommendation:** **Flutter** * **Rationale:** Allows building natively compiled applications for mobile from a single codebase. Offers excellent performance, a rich widget library (Material & Cupertino), strong community support, and good integration with Firebase. Hot reload significantly speeds up development. * **Alternatives:** * **React Native:** Another strong cross-platform option, especially if the development team has React experience. Uses JavaScript/TypeScript. * **Native iOS (Swift/SwiftUI) & Native Android (Kotlin/Jetpack Compose):** Provides the best platform integration and performance but requires separate codebases and development efforts. Suitable if platform-specific features are paramount or if separate native teams exist. * **Language (if Flutter):** Dart * **State Management (if Flutter):** **Riverpod** or **Provider** * **Rationale:** Provide flexible and scalable ways to manage application state, facilitating dependency injection and separation of concerns (MVVM/BLoC patterns). Riverpod is generally considered more modern and compile-safe. * **Routing (if Flutter):** **go_router** or Flutter Navigator 2.0 API * **Rationale:** Provides robust, declarative navigation and deep linking capabilities. `go_router` simplifies Navigator 2.0 usage. * **Local Notifications:** **flutter_local_notifications** package * **Rationale:** A popular and well-maintained plugin for scheduling and displaying local notifications on both iOS and Android. ## 4. Backend * **Backend Type Recommendation:** **Backend-as-a-Service (BaaS)** * **Specific BaaS Recommendation:** **Firebase** * **Rationale:** Offers a comprehensive suite of services tightly integrated and well-suited for mobile apps. Easy setup and generous free tier. * **Authentication:** Firebase Authentication (Handles email/password, potentially social logins later). * **Database:** Firestore (NoSQL, real-time, scalable, good querying capabilities, offline support) or Realtime Database (Simpler JSON structure, very low latency). Firestore is generally preferred for more complex data structures and querying. * **Cloud Functions (Optional):** For any server-side logic if needed in the future. * **Alternatives:** * **Supabase:** An open-source alternative to Firebase, providing PostgreSQL database, Authentication, Edge Functions, and Realtime subscriptions. Excellent choice if relational data structure is preferred or open-source is a requirement. * **AWS Amplify:** Comprehensive BaaS offering from AWS. * **Custom Backend:** (Node.js/Express, Python/Flask/Django, Go/Gin, etc. with PostgreSQL/MySQL/MongoDB). More control but significantly higher development and maintenance overhead for this project's scope. Not recommended unless specific needs dictate it. ## 5. Database * **Recommendation (if Firebase):** **Firestore** * **Rationale:** Flexible NoSQL document database, real-time updates, offline persistence, robust security rules, scales automatically. Well-suited for the proposed data model. * **Recommendation (if Supabase):** **PostgreSQL** * **Rationale:** Powerful relational database provided by Supabase, allows for structured data, constraints, and SQL querying. * **Recommendation (if Custom Backend):** **PostgreSQL** or **SQLite** (if strictly local/no sync planned) * **Rationale:** PostgreSQL is a robust open-source relational database. SQLite is file-based and suitable for purely local storage within the app. ## 6. Hosting * **Not Applicable (if using BaaS):** The BaaS provider handles backend hosting. * **If Custom Backend:** * **Platform-as-a-Service (PaaS):** Heroku, Google Cloud Run, AWS Elastic Beanstalk. (Easy deployment and scaling). * **Serverless Functions:** AWS Lambda, Google Cloud Functions, Azure Functions. (Cost-effective for event-driven logic). * **Virtual Private Server (VPS):** DigitalOcean, Linode, AWS EC2. (More control, more management overhead). ## 7. Third-Party Services * **Local Notifications:** Handled by a client-side package (e.g., `flutter_local_notifications`). * **(Optional) Analytics:** Firebase Analytics, Google Analytics for Mobile Apps (To understand user engagement if needed later). * **(Optional) Crash Reporting:** Firebase Crashlytics, Sentry (To monitor application stability). ## 8. Development Tools * **IDE:** VS Code (excellent Flutter/Dart support) or Android Studio / IntelliJ IDEA. * **Version Control:** Git (using platforms like GitHub, GitLab, Bitbucket). * **Package Management:** Pub (Dart/Flutter), npm/yarn (React Native). * **Design:** Figma, Sketch, Adobe XD (For UI mockups and prototypes). ## 9. Summary Table | Category | Recommendation | Rationale | Alternatives | | :--------------- | :---------------------------- | :------------------------------------------------- | :------------------------------------------------- | | **Platform** | Mobile (iOS, Android) | User requirement | - | | **Frontend FW** | Flutter | Single codebase, native performance, fast dev | React Native, Native Swift/Kotlin | | **State Mgmt** | Riverpod / Provider (Flutter) | Scalable state handling, DI | BLoC/Cubit, Redux, Zustand, Context API | | **Backend** | BaaS (Firebase) | Integrated Auth/DB, fast setup, scalable | Supabase, AWS Amplify, Custom Backend | | **Database** | Firestore (via Firebase) | Real-time, NoSQL flexibility, offline, security | Realtime DB (Firebase), PostgreSQL (Supabase) | | **Notifications**| `flutter_local_notifications` | Cross-platform local notification scheduling | Platform-specific APIs | | **Version Ctrl** | Git / GitHub | Standard for source code management | GitLab, Bitbucket | | **IDE** | VS Code | Excellent cross-platform & Flutter support | Android Studio, IntelliJ, Xcode | ``` ```markdown # file_structure.md ## 1. Overview This document outlines a recommended file structure for the Task Management Mobile Application, assuming **Flutter** and the **Riverpod/Provider** state management pattern with a **Repository** pattern for data access. This structure promotes separation of concerns, maintainability, and scalability. ## 2. Root Directory Structure ``` task_manager_app/ ├── android/ # Android native project files ├── ios/ # iOS native project files ├── lib/ # Main Dart application code │ ├── main.dart # App entry point, initializes Firebase, sets up providers │ ├── app.dart # Root application widget (MaterialApp/CupertinoApp), theme, routing │ │ │ ├── **core**/ # Core utilities, constants, base classes │ │ ├── constants/ # App-wide constants (strings, numbers, keys) │ │ │ └── app_constants.dart │ │ ├── error/ # Error handling classes (Failure, Exceptions) │ │ │ ├── exceptions.dart │ │ │ └── failure.dart │ │ ├── navigation/ # Routing configuration (e.g., go_router setup) │ │ │ └── app_router.dart │ │ ├── theme/ # App theme data │ │ │ └── app_theme.dart │ │ ├── usecases/ # Base use case class (optional) │ │ │ └── usecase.dart │ │ └── utils/ # Utility functions (date formatters, validators) │ │ └── date_formatter.dart │ │ │ ├── **data**/ # Data layer: models, sources, repositories │ │ ├── datasources/ # Data sources (local DB, remote API/BaaS) │ │ │ ├── local/ # Local data storage (e.g., using sqflite, hive, shared_prefs) │ │ │ │ └── task_local_datasource.dart │ │ │ └── remote/ # Remote data interaction (e.g., Firebase SDK calls) │ │ │ ├── firebase_auth_service.dart │ │ │ ├── firestore_folder_service.dart │ │ │ └── firestore_task_service.dart │ │ ├── models/ # Data models (Plain Dart objects) │ │ │ ├── folder_model.dart │ │ │ └── task_model.dart │ │ └── repositories/ # Repository implementations (abstracting data sources) │ │ ├── auth_repository_impl.dart │ │ ├── folder_repository_impl.dart │ │ └── task_repository_impl.dart │ │ │ ├── **domain**/ # Domain layer: entities, repository interfaces, use cases │ │ ├── entities/ # Core business objects (independent of data layer) │ │ │ ├── folder.dart │ │ │ └── task.dart │ │ ├── repositories/ # Abstract repository interfaces │ │ │ ├── auth_repository.dart │ │ │ ├── folder_repository.dart │ │ │ └── task_repository.dart │ │ └── usecases/ # Business logic units (interactors) │ │ ├── auth/ │ │ │ ├── login_user.dart │ │ │ └── register_user.dart │ │ ├── folders/ │ │ │ ├── add_folder.dart │ │ │ ├── delete_folder.dart │ │ │ ├── get_folders.dart │ │ │ └── update_folder.dart │ │ └── tasks/ │ │ ├── add_task.dart │ │ ├── delete_task.dart │ │ ├── get_tasks.dart │ │ ├── get_weekly_completed_count.dart │ │ └── update_task.dart │ │ │ ├── **presentation**/ # Presentation layer: UI (Widgets/Screens), State Management (Providers/ViewModels/Blocs) │ │ ├── providers/ # State management logic (Riverpod Providers, ChangeNotifiers, BLoCs) │ │ │ ├── auth_provider.dart │ │ │ ├── folder_provider.dart │ │ │ ├── stats_provider.dart │ │ │ └── task_provider.dart │ │ ├── screens/ # Top-level view for each route/feature │ │ │ ├── auth/ │ │ │ │ └── auth_screen.dart │ │ │ ├── folders/ │ │ │ │ └── folder_list_screen.dart │ │ │ ├── stats/ │ │ │ │ └── stats_screen.dart │ │ │ └── tasks/ │ │ │ ├── task_add_edit_screen.dart │ │ │ ├── task_detail_screen.dart │ │ │ └── task_list_screen.dart │ │ └── widgets/ # Reusable UI components shared across screens │ │ ├── common/ # Very generic widgets (buttons, inputs, loaders) │ │ │ └── loading_indicator.dart │ │ ├── folders/ # Widgets specific to folder features │ │ │ └── folder_list_item.dart │ │ └── tasks/ # Widgets specific to task features │ │ ├── task_list_item.dart │ │ └── task_form.dart │ │ │ └── **services**/ # External service integrations │ └── notification_service.dart # Wrapper for local notifications plugin │ ├── test/ # Unit, widget, and integration tests │ ├── core/ │ ├── data/ │ ├── domain/ │ └── presentation/ │ ├── pubspec.yaml # Project dependencies and metadata ├── pubspec.lock # Locked dependency versions ├── README.md # Project description └── .gitignore # Files/folders to ignore in Git ``` ## 3. Layer Descriptions * **`lib/`**: Contains all the Dart code for the application. * **`lib/core/`**: Foundational code used across multiple layers. Includes constants, base classes, utility functions, error handling definitions, theme, and navigation setup. Does not depend on other layers except potentially `domain` for base use cases. * **`lib/data/`**: Responsible for data retrieval and storage. Contains data source implementations (how to talk to Firebase, local DB), data models (often with serialization logic), and concrete repository implementations that fulfill the contracts defined in the `domain` layer. Depends on `core` and `domain` (for interfaces). * **`lib/domain/`**: The core business logic layer. Contains pure business entities, abstract repository interfaces (defining *what* data operations are needed, not *how*), and use cases (interactors) that orchestrate data flow between presentation and repositories. Should be independent of `data` and `presentation`. Depends only on `core` (optional). * **`lib/presentation/`**: The UI layer. Contains screens (widgets representing full views), smaller reusable widgets, and state management logic (Providers, ViewModels, BLoCs). Responsible for displaying data and handling user input. Depends on `domain` (to call use cases) and `core`. * **`lib/services/`**: Wrappers or handlers for external services like notifications, analytics, etc. Often used by `presentation` or `data` layers via dependency injection. Depends on `core`. * **`test/`**: Contains all automated tests, mirroring the structure of the `lib/` directory. ## 4. Key Files * **`lib/main.dart`**: Initializes the app, sets up dependency injection (if needed), initializes Firebase/BaaS, and runs the main App widget. * **`lib/app.dart`**: Defines the root `MaterialApp` or `CupertinoApp`, configures the theme, and sets up the router. * **`lib/core/navigation/app_router.dart`**: Configures all the application routes using the chosen routing package (e.g., `go_router`). * **`lib/core/theme/app_theme.dart`**: Defines colors, typography, and other UI styling constants. * **`pubspec.yaml`**: Defines all project dependencies (Flutter SDK, packages like `firebase_core`, `cloud_firestore`, `firebase_auth`, `flutter_riverpod`, `go_router`, `flutter_local_notifications`, etc.). This structure provides a clear separation that helps in managing complexity, testing components in isolation, and adapting to changes. ``` ```markdown # trigger_prompt.md ## AI Code Generation Prompt **Objective:** Generate source code for a Task Management Mobile Application using Flutter and Firebase (Firestore & Auth). **Target Platform:** iOS & Android. **Core Requirements:** 1. **Technology Stack:** * Frontend: Flutter (latest stable version) * Language: Dart * State Management: Riverpod * Backend: Firebase (Authentication, Firestore) * Routing: `go_router` * Local Notifications: `flutter_local_notifications` * Architecture: Follow MVVM/Clean Architecture principles (separate Presentation, Domain, Data layers). 2. **File Structure:** Implement the following structure: ``` lib/ ├── core/ (constants, error, navigation, theme, utils) ├── data/ (datasources/remote, models, repositories_impl) ├── domain/ (entities, repositories, usecases) ├── presentation/ (providers, screens, widgets) ├── services/ (notification_service.dart) ├── main.dart └── app.dart ``` *(Refer to `file_structure.md` for detailed breakdown)* 3. **Firebase Setup:** * Assume Firebase project is pre-configured. * Initialize Firebase in `main.dart`. * Use `firebase_auth` for email/password registration and login. * Use `cloud_firestore` for data storage. 4. **Database Schema (Firestore Collections):** * `users`: (Managed primarily by Firebase Auth, potentially a doc per user for profile data if needed) * `folders`: Fields: `userId` (string, FK), `name` (string), `createdAt` (timestamp). Ensure unique `name` per `userId`. * `tasks`: Fields: `userId` (string, FK), `folderId` (string, nullable), `title` (string), `description` (string, nullable), `dueDate` (timestamp, nullable), `isCompleted` (bool), `createdAt` (timestamp), `completedAt` (timestamp, nullable). Index relevant fields (`userId`, `isCompleted`, `dueDate`). 5. **Authentication:** * Implement `AuthScreen` with forms for email/password Login and Registration. * Use Riverpod providers (`auth_provider.dart`) to manage auth state (logged in/out, user ID). * Implement `AuthRepository` interface (domain) and `AuthRepositoryImpl` (data) interacting with `FirebaseAuth`. * Implement `LoginUser` and `RegisterUser` use cases (domain). * Redirect users to `TaskListScreen` upon successful login/registration, otherwise show errors on `AuthScreen`. * Persist login state. 6. **Task Management Features:** * Implement `TaskRepository` interface and `TaskRepositoryImpl` using Firestore. * Implement use cases: `AddTask`, `UpdateTask`, `DeleteTask`, `GetTasks` (with filtering by completion status, folderId, sorting by `dueDate`). * Implement `TaskListScreen`: Display tasks (use `StreamProvider` for real-time updates from Firestore). Allow marking tasks complete via checkbox directly on the list item (`TaskListItem` widget). Include a FloatingActionButton to navigate to `TaskAddEditScreen`. Allow filtering (e.g., via dropdown or tabs). * Implement `TaskAddEditScreen`: Form (`TaskForm` widget) to create/edit tasks (title, description, due date picker, folder selector dropdown populated from user's folders). Use Riverpod provider (`task_provider.dart`) to manage form state and interaction with use cases. * Implement `TaskDetailScreen` (Optional, or combine view/edit): Display full task details. Allow navigation to edit mode. 7. **Folder Management Features:** * Implement `FolderRepository` interface and `FolderRepositoryImpl` using Firestore. * Implement use cases: `AddFolder`, `UpdateFolder`, `DeleteFolder`, `GetFolders`. * Implement `FolderListScreen`: Display user's folders (`FolderListItem` widget). Allow adding, renaming, deleting folders (with confirmation). Tapping a folder should navigate to `TaskListScreen` filtered by that folder. Use Riverpod provider (`folder_provider.dart`). * When deleting a folder, update associated tasks to set their `folderId` to null. 8. **Notifications:** * Implement `NotificationService` wrapper around `flutter_local_notifications`. * When a task with a `dueDate` is created or updated, schedule a local notification using the service to trigger at the specified time. Include task title in the notification. * Handle notification permissions request. 9. **Statistics:** * Implement `StatsScreen`: Display a simple text widget showing the count of tasks completed in the current week. * Implement `GetWeeklyCompletedCount` use case interacting with `TaskRepository` (query tasks where `isCompleted` is true and `completedAt` falls within the current week). Use Riverpod provider (`stats_provider.dart`). 10. **UI/UX:** * Use Material Design components. * Implement basic navigation using `go_router` between Auth, TaskList, TaskAddEdit, FolderList, and Stats screens. Consider a `BottomNavigationBar` or `Drawer` for main navigation. * Provide user feedback for actions (loading indicators, snackbars for success/error messages). * Implement empty states for task and folder lists. * Ensure basic form validation (e.g., task title required). 11. **Code Quality:** * Follow Dart/Flutter best practices. * Use Riverpod for dependency injection and state management. * Separate concerns according to the defined layers (Presentation, Domain, Data). * Add comments where necessary. * Prioritize readability and maintainability. **Generate the Flutter code based on these specifications.** ```