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.
I can’t help but think that we are rushing through so very many parts of this code that would benefit from a slower pace, and I already know what is going on here! I really dislike it whenever I am just handed some code in an educational course. People don’t learn well when they are given a big chunk of code and told what is going on in the code. It is much better to explain it in small chunks as you go along and have them actually build it.
Kudos though for showing some of the many things that can go wrong in Interface Builder and what to do about it.
Just a note that you may have a very difficult time getting your PlaySoundsViewController layout to look just like theirs, because they reworked it with two vertical stacks nested into another vertical stack after the video. Getting things into the right place is pretty simple in Interface Builder if you do it correctly the first time and work your way from the outside in to the details, but often quite difficult or nearly impossible if you start on the inside details and try to add outside containers after the fact. Many times, IB will just completely remove all constraints when you move something inside something else.
On to “UIKit Fundamentals” and MemeMe!
I was not too happy with the mix of disparate subjects here: AVFoundation, delegation, and segues. I am also disappointed in the sloppy coding practices employed. I really don’t think it would be too much trouble to teach error handling the right way, right at the beginning. Or at a minimum, to use proper error-handling code and say “This is error handling code. We will get into that later on down the road, but for now just copy it in” so people get used to seeing it and doing it. Instead, people get used to seeing how to avoid doing error handling and consequently get used to avoiding error handling.
It took me awhile to getting around to this next lesson; a lot longer than I would have liked. I was about to defect to working with Firebase, but I did not have time for that either. So when I did get some time, I came back to finish at least this first course on the path to attaining a nano degree.
This section was a little bit more involved, so it took a little bit longer than the first two at about sixty minutes. Not much to comment on here as none of the material was new or particularly enlightening for me. I did notice that my stop recording button is the same size as the record button. I’m not certain if the instructor added additional constraints on the image or if the instructor’s image has different dimensions than the stop recording button offered in the download. No matter, the button works the same whether it is large or small. For the record, I think the width and height have each been constrained to a size of fifty points. You can do that if you want your button to look like the instructor’s button.
Also, don’t drag all of the provided images into the Assets.xcassets folder. Everything that starts with “Icon” will eventually go into the AppIcon squares, so leave them out for now. If the instructors don’t come back to it, I will explain them here in a future post.
I have finished the first two sections of “Intro to iOS App Development with Swift”. Each section took me approximately forty-five minutes to watch, following along as I did so. Your mileage may vary, depending on whether or not you have Xcode installed and how familiar you are with it.
I am glad to see that the course has (mostly) kept up with the latest versions of Xcode and Swift. This is especially important with Swift, because Swift 3 is dramatically improved over earlier iterations of the language. I was also pleased to actually learn some things: 1) Some useful keyboard shortcuts (that, had I been paying attention, I should have known already), and 2) How to quickly identify which user-interface elements are connected to bits of IBAction and IBOutlet code. Small things, yes, but at this rudimentary level I was not expecting anything really. I was also pleased that they demonstrated how things can go slightly awry and that this is normal and OK in the short-term and can eventually be overcome with a little thought and care.
Overall, a very good beginning.
I have decided to (re)attempt Udacity’s “Become an iOS Developer” Nanodegree program and blog about it here. This should be somewhat of a different take, as I am already an iOS developer. My odyssey begins now!
#learningSwift with @Udacity
I am starting to rework the RedQuark website. If you are looking for something that used to be on RedQuark.com but cannot find it, drop me a line or leave a comment and I will try to accommodate you.
Clearly, my plans for posting within the week did not pan out. What is more, I have temporarily stepped away from learning Android development to get a nanodegree in iOS development. Toward that end, I am currently involved in the “Intro to iOS App Development with Swift” class.
I am generally pleased with the class so far, although I have a great deal of familiarity with iOS app development already. Swift is new to me — of course, because Swift is a new language to everyone — but not much of the course has been about Swift. We have been promised more Swift in a future class toward the iOS Developer nanodegree.
I can tell Udacity has been learning more and more about what makes a successful online course. We are being strongly encouraged to participate in the forums and to create a community. In that vein, we are supposed to make a blog post about some particular subject. I need to go back and find that request and make that post here, but I am once again out of time, so look for that in the next post.