comentarios

Algunos comentarios sobre el ejercicio realizado, las decisiones de diseño tomadas, y los problemas que encontre:

-   Para realizar el ejercicio decidi utilizar una UITableView como componente principal de la vista, y cada celda de la tabla posee una UICollectionView respectivamente. Esto me da la flexibilidad de poder manejar una cantidad n de carouseles.

-   En cuanto al armado dinámico de los carouseles, lo simulo mediante la utilización del archivo carousel.json. Este archivo emula un posible JSON que podría obtener desde una API cada vez que recargo la pantalla. Al no contar con una API no puedo probar los cambios dinámicamente tras la carga inicial de la app, ya que debo cerrar la app, modificar dicho archivo manualmente, y volver a correr la app para ver reflejados los cambios. Sin embargo, el modelo de datos esta diseñado pensado en el armado dinámico de los componentes, solo faltaría modificar el componente que maneje el networking y obtener los datos de la API en vez de localmente. En el caso de contar con el serivcio para obtener el JSON dinámicamente, hubiera elegido Alamofire para manejar la llamada a la API, y ObjectMapper para parsear la respuesta a mi modelo local de datos.

-   Como las celdas de carousel del mismo tipo son todas iguales, y no hay carouseles con celdas de distinto tipo mezcladas, decidi que no era necesario utilizar un UICollectionViewFlowLayout custom.

-   En cuanto a la pantalla principal, encontre un crash cuando cambiaba de Portrait a Landscape, un index out of range. Investigando en internet descubrí que el problema se debe aparentemente al cambio de los limites de la pantalla, que la collection toma como referencia, y que sobreescribiendo un método del delegate llamado invalidateLayout se solucionaba. Sin embargo, este método no pude encontrarlo para sobreescribirlo en mi extension que implementaba UICollectionViewDelegateFlowLayout.
    TL;DR: Para evitar problemas, me fije como maneja Netflix su pantalla principal, y ví que no permiten el cambio de Portrait a Landscape, asi que decidí seguir el mismo patrón que ellos.

-   Para los dos tipos posibles de tipo de carousel, decidi utilizar dos componentes UICollectionViewCell distintos. Si bien su codigo es prácticamente idéntico y se podría haber utilizado un sólo compenente, me pareció más práctico y sencillo de actualizar a futuro si utilizaba dos componentes distintos.

-   Para reproducir el video, utilice la clase AVPlayerViewController debido a su sencillez. Podría haber construido un reproductor customizado recurriendo a la clase AVPlayerItem pero era una solución mas costosa en cuanto al tiempo de desarrollo.

-   Una cuestión que no me quedo del todo prolija es la configuración de los tamaños de las celdas, tanto de la tabla como de la collection. Los tamaños los estime a ojo basandome en el doc del drive, pero según me explicaron el otro día, ustedes lo configuran todo desde backend. Mi duda es como consumen esa información. En el ejemplo yo consumo un JSON que en realidad proviene de una API con la información sobre los datos de los carouseles, ¿debería tener otro servicio aparte que obtenga la informacion visual de los componentes? ¿Que pasa si mi llamada a esa API falla? Tendria la información que necesito mostrar, pero no podría configurar los componentes que me permitan mostrar dicha información al usuario.
    Yo estimo que deben tener siempre cacheada la ultima llamada realizada a la API con la informacion visual, así en el caso de que falle una nueva llamada estan cubiertos y pueden presentar la información.
    TL;DR: No use cache ni persistí la informacion en el device porque no tengo API real, pero si la hubiera tenido, hubiera elegido ese enfoque. Para este ejemplo sencillo hubiera utilizado NSUserDefaults, pero en una aplicación mas compleja hubiera optado por recurrir a un framework externo que me facilite el trabajo de la persistencia de datos, preferentemente Realm.