It's your turn!
ListenUp! has gotten better and we know the sky is the limit - there’s always room for improvement! There are a couple of points we could address:
Limited media selection: It uses "mix" as the only search term to request a media list using iTunes API. It’s alright at first, but after a while it gets boring and hardly updated - only when iTunes selection changes and different items can be served in the beginning.
Static swag items: It’s alright to use static mocked data for demo purposes. However, in preparation for the app to face the world, it must present relevant content.
Not quite SOLID implementation. It’s important to always write clean code and follow the principles of good quality code. It’s also necessary to weigh the resources vs technical perfection. In the beginning, for narrower functionality, some principles may be considered compromised. As the code base expands, some compromised points must be revisited and refactored.
Expanding media selection
The requirement now is to present the user with a different list of media items every time the user opens the app. There are a number of options here:
Explore API request parameters and play with requesting different sections from the search results, i.e. number of items and starting item.
Come up with a list of fun search terms and make a random selection in your code to use for the search each time a user opens the app.
Go further and provide the user with an opportunity to input their own search terms and use it to query iTunes. This can be done in a few ways in order of complexity of the implementation:
Show an alert with input field. You can either display an alert on app load or have a button that would make it pop up.
Provide an input field at the top of the list.
Utilize the search component of collection view. This would be a referred choice from the quality of the implementation point of view, but this may be a new element to you. Using this approach is not mandatory or favorable in any way for the assessment.
Feel free to choose any of the options above (or any combination of them), as well as come up with your own.
Fetching dynamic swag items
To make the content truly dynamic, you now need to source the swag items from an external resource.
Find a suitable external API that would deliver dynamic list of swag items of your choosing.
Implement the networking components to deliver the list to the application.
Connect the remote data to the corresponding UI elements of the application.
Go further and implement a clever algorithm to serve a list of swag items "related" to a selected media item. There are a couple of options to explore here:
Load "all available" swag items and then use your algorithm to select the most applicable once per media item.
Load only "relevant" swag items once you know which media item was selected.
Making networking SOLID
Re-architect the code responsible for networking. Now that another context is added to the app - the swag selection - the structure becomes more sophisticated and provides a great opportunity to restructure and abstract the networking part of the code following SOLID principles. Some of the variations may include creating separate classes for the following functionality:
A class responsible exclusively for sending requests and receiving results.
A class responsible exclusively for creating requests using provided API end-points, call parameters, and request methods.
A class per content type responsible for delivering context specific data (i.e. media, swag, image).
A class responsible for parsing data (this is a more complex level of abstraction) and methods within content specific classes responsible for parsing data.
Go further and implement a class to process errors and present a user with various messages communicating issues (i.e. analyzing the response status code beyond 200).
As you choose your approach, describe the following:
The principle(s) your decisions cover and how it improved the architecture.
The principle(s) your decisions violate and why you believe it’s acceptable for the current state of the application.
Check your work!
Check that the following elements are present:
External API is utilized to access remote content
Datasource and presentation improvements are completed to support the new content
At least one clean code principle is addressed in the new code architecture of the networking functionality
A clear description is provided describing the improvements and principles addressed as well as those violated
A new networking component is implemented to deliver the dynamic swag content from remote server
The new content is adequately presented within the app
