These are good exercises, worth doing, with the following caveats.

For the Animals Exercise, I found it completely unnecessary to write any code. I just looked at the raw JSON file and answered the questions using that. Thankfully, the next exercise data set was both large enough and complicated enough that writing code appears to be the quicker solution.

For the Hearthstone Exercise, I could not successfully get the hearthstone.playground (or the hearthstone-solution.playground for that matter) to execute more than once. Any changes to the code would send Xcode off into NeverNeverLand until I completely quit Xcode and restarted the playground. (This is Xcode version 8.3.2, by the way.)

My solution to the problem was two-fold, but perhaps only one of these is necessary:

1. Set the playground to “Manually Run”. By default, the playground will automatically run. To change it to only run when you want it to run, long-click the square (if the playground is currently running) or the right-facing “play” triangle (if the playground is paused or “Ready”) at the bottom-left of the Editor area and select “Manually Run”. Now, when you want the playground to run, click the right-facing “play” triangle.
2. Rebuild the playground from scratch. In particular, I removed all forced unwrapping (‘!’) and references to NSDictionary. Furthermore, there is no need to pass the parsedHearthstoneJSON variable into the parseJSONAsDictionary() function. (You will note that the argument dictionary is never referenced anywhere inside the function.) Although putting the parsing into a function is a good idea for app code, it is unnecessary here in this playground.

First off, I wouldn’t mind the course designer getting cute and starting with Lesson 0 instead of Lesson 1 if the Udacity system supported it. Unfortunately, Udacity does not. Therefore, Lesson 0 is listed as “Lesson 1” in the Udacity menu system, and each Lesson n is listed as Lesson n+1. Although not very confusing, it is still pointlessly confusing.

Secondly, unlike the previous course, the menu system only lists one lesson at a time. This would not be quite so annoying if I had not already experienced the benefits of being able to look back and look ahead without jumping all the way back to the course roadmap.

I like the presenters and, for the most part, the way the material is presented. In Lesson 1: Using Web Services and APIs (I am using their lesson numbers, not Udacity’s), there is still way too much of “Here, look at this code, copy it into your project, and then run it.”

Lesson 0: Making a Network Request was entertaining and informative enough. As it has been some time since I viewed the lesson and there was not much new to me within it, that analysis will have to suffice. On to Lesson 1.

I both like and dislike the use of Flikr for this app. I like that we are using a real, honest-to-goodness commercial API that we might want to actually use for some future app. I dislike the confusion of “photo-this” and “photo-that” though, and the presenter even acknowledges the problem. They chose fairly well however because that API, and particularly the JSON data it returns, show considerable depth and expose a variety of JSON object types.

Please note that even the new code in this lesson is slightly out-of-date. Nothing too difficult to handle though. Xcode’s auto-fix will generally guide you in the right direction.

This post probably concludes my look at the UIKit Fundamentals course. I am still finishing up MemeMe 2.0, but I doubt I will have anything to add after completing it. There were two additional bits and pieces I wanted to address though.

The first is a line of code that you may or may not encounter in step6.1-bondVillains-noTabs. In that code is a left-over call (from an Xcode 6 template, I believe) to registerClass(_, forCellWithReuseIdentifier:). If you fail to delete that line of code, any attempt at creating a cell in the storyboard will be for naught. The line has been deleted from subsequent iterations of the Bond Villains app (steps 6.2 through 6.4), so it will only cause you grief if you try to add a cell in the storyboard in step 6.1 (as I did).

The second issue is the complete lack of a textual rubric or outline or list of requirements or checklist for the MemeMe 2.0 project near the end of this lesson. There were checklists for other, less challenging apps in this course; why not for the biggest, most complex app? Instead, I have to go back through the videos and try and find every last little requirement and make my own checklist. That may be an important skill to have, but I know this omission was not an intentional teaching device.  I just can’t understand this oversight.

I am through with the online content of this final lesson, and therefore the course, but I still need to complete the project. I have to say that they dropped the ball a bit at the end here, mixing up tab controllers and collection view controllers was not such a good idea. There is not much to implementing tab controllers, but it is made much more confusing than it needs to be because of introducing collection view controllers at the same time.

What is worse, the introduction of collection view controllers is haphazard at best. They use things before they present and explain them, and then they explain other things twice in a row. Explaining things twice in a row is in and of itself is not so bad — there is something positive to be said for repetition — but considered alongside the lack of explaining other things makes it clear that this final lesson was rushed and poorly planned-out.

I will try to wrap things up after I finish the final project.

Oh, thank goodness they return to the Make Your Own Adventure App and do it the right way, or at least a better way. I am so relieved that I am writing this post even though I have yet to complete the lesson.

Although we have been left to do a lot of coding on our own here in this unit, I don’t feel like we were thrown into the deep end this time. The written prompts have been fairly clear and helpful. (They did leave out the label for the Bond Villains app, but I hope most people can fill in those gaps themselves.)

Make it stop! Aaaaaagh!

I’m only part way into the Navigation lesson, but my eyes are bleeding at the copy/paste implementation of the Make Your Own Adventure app. There has to be a better way of demonstrating how to use Navigation Controllers — one that does not encourage people to use this insidious, hideous pattern of abuse!

I can’t say there was much that surprised me about this lesson, except perhaps that we added a table view into a custom UIViewController, rather than start with a UITableViewController. That is understandable though, because the UITableViewController is ultimately more limited. Given the number of times I have forgotten to hook up a table view delegate and table view data source to my table view and wondered just what was going on, it is probably best to start off where you absolutely have to hook those up for yourself. (In case you don’t know, if you use a UITableViewController in a storyboard, it automatically hooks those up for you.)

This rant is not about the UIKit Fundamentals course per se, but rather the difficulty of finding decent documentation on the NSAttributedString class. If you are looking for it, here it is: NSAttributedString iOS Swift. You will note that link does not go to developer.apple.com. The information needed for the v1.0 build of the MemeMe app may be on Apple’s website, but I spent a great deal of time not finding it.

The particular bit of needed information I was looking for is not easily guessed either, as it is both complicated and non-intuitive:

• NSStrokeWidthAttributeName will override NSForegroundColorAttributeName, such that the foreground color is clear, if the specified stroke width is positive.
• NSStrokeWidthAttributeName with a negative stroke width on the other hand will use the NSForegroundColorAttributeName as the fill color.

Kudos to Eva Diaz-Santana (@evdiasan) for providing that information on a web page that is everything Apple should have provided easy reference to from the NSAttributedString class documentation: a clear, visual representation of just what all of those attributes mean and how to use them.

Imagine you have never gone swimming in your life. You decide to take swimming lessons. Your first lesson, you spend the first half of the class sitting in a classroom while the instructor shows you a series of static images demonstrating the breaststroke, backstroke, and butterfly. You are then taken out to the deep end of the pool and told to jump in and demonstrate all three strokes.

That is what this particular lesson feels like. Almost all of the lesson is “Here is some code; look at it.” At the end, you are asked to build an app that presents a view controller three different ways. What should have been a series of small steps leading up to a completed major project ended up being one giant leap. There is no reason the lesson could not have been structured such that you build the final project in three steps corresponding to the three different ways to present a view controller: learn then build, learn then build, and learn then build.

I am also starting to have major quibbles with the quizzes. I know from past experience that Udacity courses can have problems grading quizzes with open-ended responses. There are ways around this, but this particular course appears to have thrown up its hands and decided that whatever you want to write is a perfectly respectable correct answer. And much of the time, that is because the quizzes are not doing what quizzes should be designed to do: assess learning. Reflection is all fine and dandy, but some of the time (actually, most of the time) you need an accurate and impartial assessment of how you are doing, along with steps for remediation when how you are doing is not very well!

On the positive side, kudos for continuing to display common problems that arise when writing iOS apps, how to diagnose them, and how to fix them.

There are many good things about this first lesson, “Outlets and Actions”, in the “UIKit Fundamentals” course. Among them:

• (Almost) Comprehensive use of Interface Builder for connecting outlets and actions
• Debugging Storyboard connection issues

I say “almost comprehensive” because they left out the easiest and most intuitive way to connect objects to outlets and actions. That way is by control-dragging from the object in the storyboard to the outlet or action in the Assistant editor. The other methods of connecting that they show in the videos are really only useful if you are restricted to a single standard-width display instead of a widescreen display or multiple displays.

Unfortunately, there are also some issues with the lesson. The biggest one is that the second debugging issue recap refers to a problem that just is not there in the actual sample project. Fortunately, the quiz does reflect the proper answer.

Another big issue is due to the changes in Swift between when the video was made and now (Swift 3.1). The button property “.on” was renamed to “.isOn” between versions. Unfortunately, “.isOn” is listed as a potential answer for a quiz question. Although “.isOn” is (now) the correct answer, you won’t get the quiz correct unless you select “.on”.

Quibbles include the frequent use of “self” where “self” is not needed. I would also prefer that the changeColorComponent() function be called in viewDidLoad() so that the colorView properly reflects the state of the buttons at startup.