Set an app icon #13
@@ -1,6 +1,7 @@
|
||||
{
|
||||
"images" : [
|
||||
{
|
||||
"filename" : "Todo.png",
|
||||
"idiom" : "universal",
|
||||
"platform" : "ios",
|
||||
"size" : "1024x1024"
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 1.2 MiB |
@@ -6,11 +6,126 @@ In a nutshell, this basic app should allow a user to either create, update, and/
|
||||
|
||||
Given the requirements, the app should comply to the following criteria:
|
||||
|
||||
* each task should have a title, optional description, due date, and a flag indicating if it’s completed.
|
||||
* each task should have a title, optional description, due date, and a flag indicating if it's completed.
|
||||
* tasks should be grouped visually by their due date, such as Today, Upcoming, or Past.
|
||||
* users should also be able to reorder tasks within a group using drag and drop functionality.
|
||||
* data should be saved and loaded asynchronously, and the UI should remain responsive while these operations take place.
|
||||
* should be possible to simulate delays with built-in tools if needed.
|
||||
|
||||
Furthermore, the app is required to be built using SwiftUI with a clear structure that separates concerns. Any architectural style can be used, but the reasoning should be visible in how the code is organized.
|
||||
Furthermore, the app is required to be built using SwiftUI with a clear structure that separates concerns. Any architectural style can be used, but the reasoning should be visible in how the code is organized.
|
||||
It is expected that the app is modular and maintainable, so the source code must reflects this requirement. It is optional to include testable parts and anything extra that might improve the app.
|
||||
|
||||
## Summary
|
||||
|
||||
### What has been implemented
|
||||
|
||||
This is a comprehensive todo task management application with the following features:
|
||||
|
||||
- **Task Creation**: Create new tasks with title, optional note, and due date
|
||||
- **Smart Grouping**: Tasks are automatically organized into four categories:
|
||||
- **Today**: Tasks due today (incomplete)
|
||||
- **Upcoming**: Tasks due in the future (incomplete)
|
||||
- **Overdue**: Tasks with past due dates (incomplete)
|
||||
- **Completed**: All completed tasks regardless of due date
|
||||
- **Inline Editing**: Direct editing of task properties (title, note, due date, completion status)
|
||||
- **Task Management**: Toggle completion status with haptic feedback, swipe-to-delete, and drag-and-drop reordering within groups
|
||||
- **Visibility Control**: Show/hide completed tasks in non-completed groups
|
||||
- **Responsive UI**: Adaptive master-detail layout that adjusts for different device sizes
|
||||
- **Keyboard Management**: Smart keyboard focus handling with custom newline behaviors
|
||||
|
||||
### Architectural Choices
|
||||
|
||||
**Modern SwiftUI Stack**
|
||||
- **Swift Concurrency** setup for strict concurrency
|
||||
- **SwiftData** for data persistence and reactive data queries that automatically update the UI
|
||||
- **Observation** for view models (instead of traditional `ObservedObject` classes)
|
||||
- **Adaptative Layout** targeting iOS devices: iPhones & iPads
|
||||
- **Liquid Glass** UI interface
|
||||
|
||||
**Separation of Concerns**
|
||||
- Clear separation between Views, ViewModels, and Data layer
|
||||
- Views focus solely on presentation and user interaction
|
||||
- ViewModels handle business logic and state management
|
||||
- Repository pattern abstracts data persistence
|
||||
|
||||
**Reactive Data Flow**
|
||||
- SwiftData queries react to model changes automatically
|
||||
- Bindable properties enables direct model editing with immediate persistence
|
||||
- Computed bindings handle type conversion between optional and non-optional values
|
||||
- All state changes propagate through the observation system
|
||||
|
||||
**Dependency Injection**
|
||||
- `TodoRepository` protocol defines the data interface
|
||||
- `ModelContext` implements the protocol via extension
|
||||
- Mock implementations enable testing without database setup
|
||||
|
||||
### Used Patterns
|
||||
|
||||
**MVVM (Model-View-ViewModel)**
|
||||
- Each view has a dedicated ViewModel (`ContentViewModel`, `TaskListViewModel`, `TaskGroupListViewModel`, `NewTaskViewModel`)
|
||||
- ViewModels are `@Observable` classes that manage view state and business logic
|
||||
- Models (`Todo`) are SwiftData entities separate from presentation logic
|
||||
|
||||
**Repository Pattern**
|
||||
- Abstracts data persistence operations
|
||||
- `ModelContext` conforms to the protocol for production use
|
||||
- `MockTodoRepository` for unit testing
|
||||
- Enables testing without SwiftData infrastructure
|
||||
|
||||
**Protocol-Oriented Design**
|
||||
- `TodoRepository` protocol for dependency injection
|
||||
- Extension-based protocol conformance (`ModelContext+Conformances`)
|
||||
- Computed properties and methods in protocol extensions
|
||||
|
||||
**Custom View Modifiers**
|
||||
- `NewTaskButtonModifier`: Floating action button with glass morphism effect
|
||||
- `OnNewlineFocusModifier`: Transfer keyboard focus on Return key
|
||||
- `OnEmptyNewlineResignFocusModifier`: Clear and dismiss keyboard on empty newline
|
||||
- Reusable modifiers promote consistency and reduce duplication
|
||||
|
||||
**Computed Bindings**
|
||||
- Convert between optional and non-optional types for seamless two-way data binding
|
||||
- Example: `isCompleted: Binding<Bool>` converts `completedAt: Date?` to a boolean toggle
|
||||
- Enables clean SwiftUI forms without boilerplate conversion code
|
||||
|
||||
**Nested View Types**
|
||||
- Views are organized with nested types (e.g., `TaskListView.Content`, `TaskListView.Item`)
|
||||
- Promotes encapsulation and co-location of related views
|
||||
- Reduces file count while maintaining modularity
|
||||
|
||||
**Custom FetchDescriptors**
|
||||
- Extension on `FetchDescriptor<Todo>` provides convenience initializers
|
||||
- Each `TodoGroup` has a dedicated query builder
|
||||
- Centralizes filtering and sorting logic for reusability
|
||||
|
||||
**SwiftUI Advanced Techniques**
|
||||
- `@ViewBuilder` for conditional view composition
|
||||
- Computed properties returning `Binding<T>` for type conversion
|
||||
- `sensoryFeedback` for haptic feedback on interactions
|
||||
- Custom `ToggleStyle` for branded checkbox appearance
|
||||
- Spring animations for smooth transitions
|
||||
|
||||
## Minimum Requirements
|
||||
|
||||
### Platform & SDK
|
||||
- **iOS**: 26.0+ (iOS 26 or later)
|
||||
- **Swift**: 6.0
|
||||
- **Xcode**: 16.0+ (required for iOS 26 SDK and Swift 6.0)
|
||||
- **Device Support**: iPhone and iPad
|
||||
|
||||
### Frameworks & APIs
|
||||
- **SwiftUI**: Modern declarative UI framework
|
||||
- **SwiftData**: Data persistence (iOS 17+)
|
||||
- **Observation**: `@Observable` macro (iOS 17+)
|
||||
- **Swift Concurrency**: async/await support
|
||||
- **Swift Testing**: unit tests
|
||||
|
||||
### Device Capabilities
|
||||
- The app is optimized for both iPhone (compact size class) and iPad (regular size class)
|
||||
- Adaptive UI responds to different screen sizes and orientations
|
||||
- No special hardware requirements (camera, sensors, etc.)
|
||||
|
||||
### Development Environment
|
||||
- macOS with Xcode 16.0 or later
|
||||
- iOS Simulator or physical iOS device for testing
|
||||
- No external dependencies or third-party libraries required
|
||||
|
||||
Reference in New Issue
Block a user