This just basically lists todos. If the todos are not found locally (first launch, etc), it checks the API for the todos and caches them. Current persistence method is Core Data, but the code is abstract enough that any other can be substituted later on, using Realm, etc perhaps.
- Allow user to add new Todos
- Allow user to edit/delete Todos
- Allow user to mark a todo as done
- View: all view related code. Actual
view's are implemented using storyboard scenes/xibs. - Presenter: takes care of both event handling (receives input from user via the view) and presentation of data/content.
- Interactor: the module's business logic belongs here.
- Wireframe/Router: responsible for preparing a module, navigating to other modules
- LocalDataManager: responsible for retrieval and persistence of data on the device
- RemoteDataManager: responsible for interacting with a remote API.
- To see how the different components within a module communicates with each other, check the respective
Protocols.swift - Each module's entry point is done via the respective
Wireframeclasses. - Instead of including an additional protocols for the datamanager -> interactor flow , I opted to use promises (provided by
Hydra). - We don't like segues here so scenes in the storyboards should basically be "unhooked." In a real app, we'll be using multiple storyboards per epic, and divide them as necessary to allow more simultaneous work by multiple developers.
- This connects to a simple API in heroku. Not all endpoints are supported here so far.
- I normally sort files alphabetically in folders but I intentionally didn't in the modules; instead i listed them according to how a developer would probably inspect/work on each module.