[Intro to iOS] Week 2 Assignment: Review my app

[marcel]

/cc @codepath

[codepathreview]

:+1: nice work. The primary challenge of this homework was to learn how to use UITableView to manage a complex form, establish communication between view controllers, and apply the correct Auto Layout constraints.

+1 on the 3d touch!

Here's a checklist of things that I'm looking for in this project. You should review the checklist, and make any changes to your project, if necessary.

• For the restaurant cell, note that the subviews should be private and only updated in the Swift property observer.
• All screens in Storyboard and nibs should contain Auto Layout constraints. Make sure to resolve all the Auto Layout constraint warnings.
• In the filter view controller, make sure the cells are being recycled and dequeued and appropriately linked to the model. See this popular form library for an alternative to implementing forms manually.
• The restaurants view controller and the filters view controller should be connected via a custom filter delegate. This is a popular pattern for handling events between view controllers.
• Note: Connecting the filter view controller directly to a global filter settings is convenient, but the downside is if you cancel the filters, the values have already been saved.

This was a challenging assignment, congrats on completing it successfully!

-- dirk

[codepathreview]

:+1: nice work. The primary challenge of this homework was to learn how to use UITableView to manage a complex form, establish communication between view controllers, and apply the correct Auto Layout constraints. For each point in the homework feedback checklist, I'll either confirm that you're on the right track with the implementation, or I'll provide some feedback:

• totally awesome all the extra work!
• For the restaurant cell, note that the subviews should be private.
• Great work on restaurant updates handled by the Swift property observer.
• Nice work specifying the Auto Layout constraints.
• Nice work linking the filter model with the controls. See this popular form library for an alternative to implementing forms manually.
• Nice work connecting the view controllers via the custom filter delegate. This is a popular pattern for handling events between view controllers.

This was a challenging assignment, congrats on completing it successfully!

-- dirk

[sandofsky]

Here are some thoughts…

Assets

You'll want to keep your assets inside an asset catalogue, rather than just in the project file. In iOS 9, it'll be able to support App Thinning, and only download the resources required for the platform the app runs on. Also, the number of resource naming combinations gets pretty nuts, so it's just more tenable.

Swift

I dig that you're using structs wherever possible. I'm assuming you saw the Protocol Oriented Programming WWDC video, but if you didn't, it's worth checking out.

All in all, you're practicing what feels like very idiomatic Swift, if such a thing exists for a language less than two years old.

You're writing the most safe code I've seen out of the class. I'm happy to see guard statements and failable initializers. I want to experiment with the new "try" syntax in Swift 2 when processing results, to find the least obtrusive sanity checking.

With the Secure URL class, I'd consider adding that on top of NSURL as an extension (with appropriate prefix, of course).

I'd consider using CLLocation rather than your own coordinate class, for easier interoperability.

View Controllers

One area that might be good for refactoring is thinning out the view controllers. Fat model, skinny controller is old news, but the problem gets exacerbated because everyone starts out making their view controller the delegate for views. Which is fine to start out. But Cocoa devs have adopted the joke, "MVC stands for Massive View Controller."

One way to thin out the Business Details VC would be remove a lot of the layer setup code, probably by creating a UIView subclass. I'd lean against one-subclass-per-view in favor of composition.