Here’s a suggestion that I could probably learn a ton from:
- How to use Coordinator Pattern when an app is based on UITabBarViewController, with CoreData in-beetween to create a maintainable and readable code.
This could be demonstrated with a shopping app. The app would allow a user to 1) create a shopping lists, 2) to create and add new products to them, and 3) to archive lists. A product could be a simple object containing title only. All user data would be persisted using Core Data.
The app would have following screens: Current lists, Archived lists, List details (products that make a list).
The Current List View would display current shopping lists. Here user would be able to add a new list, display list details and archive the list. Current List View would be one of UITabBarController’s items.
The Archive List View would display all archived lists. Details or those lists should be also viewable. Moreover a user should be able to delete a list permanently. This view would be one of UITabBarController’s items.
List Detail View would display products that make a shopping list. A user would be able to add or delete the product, but only if the list isn’t archived.
The app could be made without storyboards or xib files. The Views would be of UITableView so maybe you could show how UITableDataSource and/or delegate could be decoupled from ViewControllers if it makes sense.
Such app could serve as a cool study for how to architect an app into layers and how to connect those layers so the code is maintainable in a MVC + Coordinator pattern with CoreData in-between.