PoC for entire programatic UIKit app + SPM
It's a simple list + detail app for random characters from the Rick and Morty series
| Navigation | Dark mode support |
|---|---|
 |
 |
SPM dependencies used are my own
This project was built and compile on XCode 13.4.
The test API used was Rick and Morty public one. Complex handling of oauth was beyond the scope of this PoC so that one did the trick (mainly due to time constraints)
The inner project organization is based on Uncle's Bob Clean Architecture divided as follow:
Since the app is so simple, the only entities concerned are the endpoints descriptions. These are sort of the "core business objects" given than they are the less likely to change (in fact, they haven't in 2 years)
The only possible actions from the user (beyond scrolling vertically and horizontally where appropiate) are checking the random characters at the very beginning of a new app launch AND checking the details for any selected character from the main list.
The UI design pattern for this app is MVVM. Some of the helpers associated with it live in the previously mentioned "external library" MauriUtils.
The rest lives inside this folder:
- (View)Controllers
- UI code
- Data transfer objects (DTOs)
All external connections and implementation details are located here. For this case we're talking about endpoint consumption, iOS app setup and an in-house cache framework developed to speed image showing whenever it was previously loaded.
- SOLID is at the heart of this development, always favoring composition over inherence (that's why you can see so many files for such a "small" project). It was lego oriented design 😁
- Use of UIStackViews wherever possible to laverage its flexibility and layout power.
- Break down every delegate/data source across the project in order to avoid fat classes.
MainListViewControlleris the commander (sort of speak) of it all. - Cache handling to improve UX and diminish bandwidth footprint
ItemDataSourceis where the magic happens: Cache and MVVM is shared between components here and communication never touches view model or view controller.- Dark mode support
- Github action integration: CI setup for every PR and push made against the main branch
Given the app simplicity, most tests are unit tests and refer to repository consumption (the flow of data is the expected one). The naming for all test doubles is based on this great Martin Fowler post.
There are however a couple of integration tests that are worth mentioning:
-
NavigationTestCases: verifies the navigation is being properly invoked. Given that things are so losely couple (navigation occurs via a delegate that notifies the coordinator), the compiler itself offers no guarantee in this case. The connection could be lost/erased by accident and the app would keep compiling, therefore this safeguard was implemented.
-
SnapshotTestCases: even though snapshot tests tend to be flaky across different OS versions and environemnts, when dealing with only code UI they have more pros than cons. This one in particular checks both listing and details rendering layout looks as expected (in both light and dark mode)
There were tradeoffs in every major design decision behind the development. While it is true that SOLID principles are at the core of every choice made here, no peace of software is ever complete so there might be minor duplicated here and there for speeding sake. Some notes can be found across the project explaining the shortcomings of those implementations.
You might find odd for me to include this section since it looks like I'm sabotaging myself. The intention here is to acknowledge the things that, most likely due to lack of time, remain pending. Just to mention a few:
- Proper error handling for network requests
- Maybe give a second though on the responsibility of
ItemDataSource. For scalability reasons it might be broken down in smaller components with single responsibilities. - Add infinite scrolling
