The Architecture used is MVVM:
- The View
The view has the sole purpose of showing information to the user and to inform the viewmodel of the user’s actions. The key concept of this app is that each viewController does not contain any logic which is easily identifiable by if statements 🙂
- The ViewModel
The viewModel – I have called this the presenter to make naming easier and avoid naming conflicts 🙂
The ViewModel is where the logic of the app sits. It also aggregates other services like repositories, router and analytics engine (if we had one).
I have set up mine in such a way that it uses closures instead of another
view protocol as a way that it calls back to the
view and all closures are
weak so as to avoid any retain cycles.
The model stores data that is directly related to the view and is easily usable by the view without much transformation: like:
User Friendly Dates,
`Strings that we’ll show on the screen“
etc, basically stores the view’s state.
The repository knows how and where it can fetch and return the requested data. The repository inturn uses the
dumb services that specializes in fetching data from a specific source like
Keystore , etc.
The Entity is simply used by the repository to store and query data. Usually maps one to one with the data returned from the services used within the repository. For example mapping one to one with JSON from server
The router is responsible for all the routing that each screen needs, it is is owned by the
ViewModel so that it easy to test.
The service specializes in data access eg from a
Other Notable Design Decisions
Contains all shared components of the app, components that are used by more than one screen, this includes
Each Feature has all its architecture components localized to that Features folder – It makes it easier to navigate the code therefore making it easy to maintain that screen
Each View has its
xib in the same folder. so that we avoid having a bloated main
xib that is difficult to merge because of merge conflicts. Having one
xib per view makes it easy to work on that screen and make any modifications.
I’ve used SDWebImage to download and cache images for me so that we have smooth scrolling experience
Final thoughts and Improvements
I would have love to write test for the presenters at the very least , but I’ve made sure that the each layer of the Archtecture is testible by using protocols so mock instacies can be injected when testing.
I would’ve also loved to try and secure the API KEY instead of leaving in plain sight as it is right now.
Logger.swift that only logs in development.
I didn’t do the following as I believe the current project clearly demonstrates my capabilities:
- Tapping on an item should open weather details view
- The settings screen demostrates moving from one screen to the next, the only thing missing is passing data to the next screen
- Local Notifications to show weather alert
- Offline/Local storage (preferably Realm Framework)
- Unit tests
- Update weather info frequently in the background
I mainly focused on the architecture of the application and showcasing my deep understanding of the iOS SDK and swift.
Looking forward to hearing from you and what are your thoughts and pitfalls of these architectural decisions 🙂