TheRanking/theranking-ios-candidates — pull request #3 by jaimeat1 (2014-10-26 22:47:38+00:00)
Title: iOS Dev Test solution

Sobre la solución aplicada, he utilizado un patrón denominado de diseño VIPER.
http://mutualmobile.github.io/blog/2013/12/04/viper-introduction/

En VIPER la arquitectura de la app queda dividida en varios actores con responsabilidades claras y bien diferenciadas. VIPER se aplica siguiendo los casos de uso (en este caso existen dos casos de uso: “Show popular items” y “Show item details”) e implementando en ellos cada uno los siguientes actores:
* View: representa los view controllers y views. Carecen de toda lógica y simplemente se reducen a mostrar datos y comunicar eventos de interfaz.
* Interactor: representa toda la lógica del negocio. Obtiene los datos de las fuentes, y los prepara para poder ser mostrados en la View.
* Presenter: representa la lógica de la interfaz. Solicita datos en un formato determinado y se los pasa a la View, de la que recibe eventos. Coordina las View a través del Routing.
* Entity: representa el modelo de datos de la app, solamente conocido por el Interactor, que es quien las manipula para “curar” los datos y dárselos al Presenter.
* Routing: o también Wireframe, representa la lógica de transición entre unas Views y otras.

Con respecto a librerías de terceros, he utilizado SDWebImage para cargar las imágenes.