It's time to put your skills to the test!
You are called to implement the RemoteFeedLoader
to load a collection of images from a backend.
Your implementation must:
- Conform to the
<FeedLoader>
protocol creating an array ofFeedImage
:
- Follow the backend contract below:
Property | Type |
---|---|
image_id |
UUID |
image_desc |
String (optional) |
image_loc |
String (optional) |
image_url |
URL |
200 RESPONSE
{
"items": [
{
"image_id": "a UUID",
"image_desc": "a description",
"image_loc": "a location",
"image_url": "https://a-image.url",
},
{
"image_id": "another UUID",
"image_desc": "another description",
"image_url": "https://another-image.url"
},
{
"image_id": "even another UUID",
"image_loc": "even another location",
"image_url": "https://even-another-image.url"
},
{
"image_id": "yet another UUID",
"image_url": "https://yet-another-image.url"
}
...
]
}
The goal of this exercise is to get you used to the TDD flow.
We've provided you with appropriate tests to guide and validate your solution. You need to make all the tests pass, one by one, by implementing the load
method in the existing RemoteFeedLoader
class.
-
Fork the latest version of the challenge repo. Here's how forking works.
-
Open the
FeedAPIChallenge.xcodeproj
project on Xcode 12.5.-
Older Xcode versions are not supported.
-
Challenges submitted with branches other than
xcode12_5
will be rejected.
-
-
There are two main folders in the project:
-
The
FeedAPIChallenge
folder contains the production types, including theRemoteFeedLoader
and dependencies for requesting and loading the feed remotely.-
⚠️ Important: You should only change theRemoteFeedLoader.swift
file to implement theload
method. -
Do not change any other files in the folder.
-
-
The
Tests
folder contains the test cases.-
⚠️ Important: You should only change theLoadFeedFromRemoteUseCaseTests.swift
file to implement all test cases. -
Do not change any other files in the test folder.
-
-
Do not change the indentation in the project.
-
Do not rename the existing classes and files.
-
Important: Every time you build the project, it'll automatically reformat the modified files with SwiftFormat to maintain the code consistent.
-
-
Use the
Tests/LoadFeedFromRemoteUseCaseTests.swift
to validate your implementation.-
Uncomment (CMD+/) and implement one test at a time following the TDD process:
- Make the test pass, commit, and move to the next one.
-
While developing your solutions, run all tests with CMD+U.
-
-
Errors should be handled accordingly.
-
There shouldn't be any force-unwrap
!
orfatalError
in production code. -
There shouldn't be empty
catch
blocks. -
There shouldn't be any
print
statements, such asprint(error)
.
-
-
The
FeedImage
should not implementDecodable
- even in extensions.-
That's because the
CodingKeys
to decode the JSON are API-specific details defined in the backend. So declaring theCodingKeys
in theFeedImage
will couple it with API implementation details. And since other modules depend on theFeedImage
, they'll also be coupled with API implementation details. -
Suggestion: Create an API-specific struct in the 'Feed API' module to perform the decoding. Thus, preventing API details from leaking into other modules. So, for example, if there's a change in the backend, it doesn't propagate everywhere in the codebase. You just update the Feed API module without affecting others.
-
-
Make careful and proper use of access control, marking as
private
orinternal
any implementation details that aren’t referenced from other external components. -
When all tests are passing and you're done implementing your solution:
-
Create a Pull Request from your branch to the main challenge repo's matching branch.
- For example, if you implemented the challenge using the
xcode12_5
branch, your PR should be from your fork'sxcode12_5
branch into the main repo'sxcode12_5
branch (DO NOT MIX Xcode versions or you'll have merge conflicts!).
- For example, if you implemented the challenge using the
-
The title of the Pull Request should be: Your Name - Feed API Challenge.
-
-
Review your code in the Pull Request (PR) and make sure it follows all the instructions above.
- If it doesn't, make the appropriate changes, push, and review your code in the PR again.
-
After you review your code and it follows all the instructions above:
- Post a comment in the challenge page in the academy with the link to your PR, so we can review your solution and provide feedback.
-
Aim to commit your changes every time you add/alter the behavior of your system or refactor your code.
-
Aim for descriptive commit messages that clarify the intent of your contribution which will help other developers understand your train of thought and purpose of changes.
-
The system should always be in a green state, meaning that in each commit all tests should be passing.
-
The project should build without warnings.
-
The code should be carefully organized and easy to read (e.g. indentation must be consistent).
-
Aim to write self-documenting code by providing context and detail when naming your components, avoiding explanations in comments.
Happy coding!