This document is going to explain architectural decision taken in developing this sample app.
Flickr sample app has a modular architecture. One of the pillars of it is creating independent units of code that can be tested in isolation. The project consists following modules from the lowest to highest order:
- Entities
- NetworkServices
- Adapters
- FlickerSample
Using modules in such a tiny app is an overengineering. However, the reason behing using modules is to showcase its benefits:
- Separation concerns, units are clearly cut.
- Isolated, independent units
- Reusable code
- Better parallel development
- Running unit test quicker by not need of attaching compiled file to Simulator every time unit tests run.
The app dependency graph is created inside the CompositionRoot class. By that way, the code welcome future change requests by having one centralized place to inject dependencies. If we want to support offline data support, the only place we need to change is this central dependency injection. Also, flow of the app is controlled here which makes our views agnostic of navigation logic. https://blog.ploeh.dk/2011/07/28/CompositionRoot/
The code is developed via test driven development. However, due to time constraint not a broad compassing test coverage is implemented. Also, UI tests, integration tests and snapshot tests are not implemented for the same reason stated above.
The entire app is developed using Combine framework and UI of the app is built by SwiftUI. In a real life scenario, UI module can be the sole consumer of Combine and the rest of the app can communicate with closures to support older version of the app by just changing the UI.
- A generic networking can be created.
- Add more details to the photo details, with requesting user data.
- Adding more animations and better UI and UX
- Implementing offline mode
- Can using URLCache be better instead of NSCache?