# FetchingRecipe FetchingRecipe is a SwiftUI app that displays recipes from an API endpoint. ## Features - Displays a list of recipes with name, photo, and cuisine type - Details view with additional recipe information - Pull-to-refresh functionality - Custom image caching to disk - Error handling for different scenarios (malformed data, empty data) - Unit tests for core functionality ### Summary <p float="left"> <img src='https://hackmd.io/_uploads/SJ-ZbT71xx.gif' width=250 alt='Screenshot #1'/> <img src='https://hackmd.io/_uploads/HJ5-ZamJgl.gif' width=250 alt='Screenshot #2'/> </p> The FetchingRecipe App is a modern iOS application that fetches and displays recipes from an API. ### Focus Areas I chose to prioritize the following areas: 1. **Architecture & Clean Code**: I implemented a clear MVVM architecture with proper separation of concerns. 2. **Custom Image Caching**: Based on the requirement, I built a robust file-based image caching system that saves images to disk to minimize network requests. 3. **Error Handling & User Experience**: I created a seamless user experience even when things go wrong, with clear error messages and visual feedback. 4. **Swift Concurrency**: I leveraged Swift's modern concurrency model with async/await throughout the app to handle asynchronous operations cleanly. ### Time Spent I spent approximately 8.5 hours on this project, allocated as follows: - 1.5 hour: Planning the architecture and project setup - 3 hours: Implementing core functionality (models, networking, image caching) - 2 hours: Building the UI and user experience - 1.5 hours: Writing unit tests - 0.5 hours: Documentation and final review ### Trade-offs and Decisions 1. **Simple Image Caching vs. Complex Cache Management**: I implemented a straightforward file-based caching system without advanced features like size limits. For a production app, I would implement more sophisticated cache management. 2. **Error Handling Strategy**: I chose to display full-screen error states rather than inline errors or toasts. This was a design decision based on the limited scope of the app. 3. **UI Design**: I focused on functionality over elaborate design. In a production app, I would invest more time in UI polish and animations. 4. **Test Coverage**: I prioritized testing the core logic (network requests and image caching) rather than aiming for comprehensive test coverage of the entire app, given the time constraints. ### Weakest Part of the Project The weakest part of the project is likely the lack of a more sophisticated image caching system. In a production environment, I would improve this by: 1. Adding cache eviction policies (LRU, TTL) 2. Implementing cache size limits 3. Adding memory caching in addition to disk caching for faster access to recently viewed images 4. Including more robust error handling for image loading failures ### Additional Information - The app is built with iOS 15+ in mind to leverage the latest SwiftUI features like `async/await` and the refreshable modifier - The codebase follows Swift style guidelines and best practices - I've made some assumptions about the API error handling that would need to be validated in a real-world scenario