What Online Learning Needs

Whilst thinking about the shortfalls of Udacity’s (and virtually everyone else’s) online classes, I struck upon this brilliant thought. Online learning needs the equivalent of a “Dragon’s Lair” video chat bot. While you are watching an instrutor video, you should be able to raise your virtual hand with a question, have the video pause, cut to a video of the instructor saying “Ah, you have a question. Yes, what is it?”, then you type or speak your question (“What is SQLite?”), the video cuts to a pre-recorded answer, and then cuts to the instructor saying, “Are we ready to return to our discussion?”, after which you say “Yes” and the original video resumes.

iOS Persistence and Core Data: VirtualTourist

“VirtualTourist” is supposed to be the app we create at the conclusion of this course. Like “On the Map”, it only gets the briefest of mentions during the course and none of the necessary resources are obviously available. There is an app from Udacity available in Apple’s App Store: “Virtual Tourist Portfolio App for iOS”. Unfortunately, and this does not bode well, the app appears to be relatively non-functional. It solitary usefulness in this course is in its description:

This app allows you to virtually tour any place on the planet! Simply drop a pin anywhere on the map, and instantly browse nearby Flickr photos. It’s like you’re there already…or something.

If you are still working on the earlier courses in the nanodegree, example “Pitch Perfect” and “On the Map” apps from Udacity are also available. They appear to be in working order.

Update! The “Virtual Tourist Portfolio App for iOS” actually works! You just need to use a long-press to drop a pin, and then you can tap that pin to see pictures from that area. Perhaps Udacity needs to add a course on onboarding?!

iOS Persistence and Core Data: Unsimple Persistence

I just finished the videos for the course, and I have to say it is a good thing I already have a lot of experience with Core Data. This course starts off so cute and friendly, like a little smiling snowman. But that smiling snowman is at the top of a mountain, and as he rolls inexorably down the mountain toward you and his inevitable conclusion, he just gets bigger and bigger and rolls faster and faster until—BAM!—he crushes you at the end!

This is a common problem with many courses, not just this one and not just in teaching computer programming. The course author knows exactly where to start, and starts off at a nice leisurely pace explaining every detail and inserting interesting tidbits and asides. But then soon comes the realization that we need to get down to business here, and subjects get glossed over as we desperately seek to come to some sort of conclusion quickly.

The best example of this in this course is a tacked-on Lesson 6 in Core Data and Concurrency. This is a topic almost deserving of its own course, but instead we get one long page of text. No video, no coding, no quizzes … nada. I can’t be positive, but it feels like this was added after the course was already “completed” and someone discovered that—oops!—our Core Data stack has concurrency issues and we better say something about it.

Courses should be written backwards. Start with where you want to end up. Look at everything your students need to know in order to do what you want them to do. Then take each of those things as your new endpoint and work backwards from them. That slow, gentle, congenial, leisurely pace should be your ending, as well as your middle and beginning. Yes, you should challenge your students. Yes, there should be a learning curve. But no one ever said it had to be exponential!

iOS Persistence and Core Data: Simple Persistence

As a fan of “Back to the Future”, I really appreciate the dramatic storyline setup for this course. It takes a while to get to the first “Great Scott!”, but they get there eventually.

As for the first lesson on the UserDefaults.standard singleton goes, I have no complaints other than the usual about how the video is using an old version of Swift and the text updates under the video give away everything about how to do the exercise, rather than just say “change all NSUserDefaults.standardUserDefaults to UserDefaults.standard”, etc.

iOS Networking with Swift: Final Thoughts

Wow, that took quite a while. To be fair, I was away on vacation for two weeks, but it has been a whole month since my last post and I only just now finished the “On the Map” app.

I cannot yet say whether having access to the complete documentation for the project would have made a big difference in how long I spent on the app. I suspect not. There were a great many unexpected twists and turns, and I did opt to implement the Facebook login as well. The Facebook Swift API is not exactly something you can just drop into, get what you need, and get out quickly.

On to “iOS Persistence and Core Data”!

iOS Networking with Swift: “On the Map”–Part 2

After a little further exploration, I discovered that the requirements for the “On the Map” app are indeed public (but not publicized). You can read them here. Be certain to follow the link to the rubric if you plan on pursuing the Nanodegree. Those documents do not include the API for Udacity user authentication, but a little poking around in GitHub will probably reward you with the information you seek by way of the repositories of prior students’ projects.

iOS Networking with Swift: Where is “On the Map”?

Apparently, the “On the Map” app is a Nanodegree-only exercise. That is very disappointing, as I would like to accomplish as much as possible of the Nanodegree prior to signing up for the Nanodegree program (because you are charged monthly for the Nanodegree program until the work is completed). This is a blatant money-grab by Udacity. There is no reason the “On the Map” resources and requirements could not be made available publicly.

Perhaps the Udacity API is not public, but then why expose it to the Nanodegree participants?

iOS Networking with Swift: Strongly Discouraged, but it Works!

At first it appears that the authentication flow has been significantly changed away from the flow presented in Lesson 5: Authentication Requests, because basically it has. Instead of entering in your TMDb credentials (username and password) into the app (where presumably the app could surreptitiously co-opt them), TMDb wants app developers to let TMDb authenticate users directly through their (TMDb’s) website. You can do this using a segue to an authentication view controller with a web view and a web view delegate, but that is not as spiffy as handling login in your own login view.

But while implementing this new flow, I stumbled across the following URL request:

GET/authentication/token/validate_with_login

It is listed as strongly discouraged, but by golly that is the request that this course is looking to use in the loginWithToken() method, and it still works! I might go back and finish the new authentication flow, since I actually have it fully implemented, but for now I’m sticking with old school. If you want to go old school too, here is the link to the appropriate documentation: https://developers.themoviedb.org/3/authentication/validate-request-token

Also, the instructor’s notes in step 18 of Lesson 5 include example code on how to use validate-request-token.

iOS Networking with Swift: Lesson 5: Authenticating Requests

If you are attempting the quiz “Which Methods to Use?” in “Lesson 5: Authenticating Requests” (aka “Lesson 3”), don’t bother. The API has changed since the quiz was written and finding the old API is darn near impossible. I eventually had to get on “The Movie Database Support” website (after a long, round-about search of the internet) and find a support request that just happened to mention the genres method. For completists, here are the methods old and new:

Old (Quiz Answers)

/genre/{id}/movies
/account/{id}/favorite/movies
/account/{id}/favorite

New (For Actual Use)

/genre/movie/list
/account/{account_id}/favorite/movies
/account/{account_id}/favorite

iOS Networking with Swift: Lesson 4: Chaining Asynchronous Requests

In “Lesson 4: Chaining Asynchronous Requests” (or “Lesson 2” in the video; now our count is off by two!), there is a ridiculous claim that you cannot retrieve any photos beyond 4000 (or possibly less). That is pure nonsense!

Here is what the Flickr API is trying to tell you. Flickr is only going to return one page of results. If you do not ask for a particular page, you are going to get the default page (which is Page 1).

That page is going to have between zero and (the current maximum of) 500 results. (See `per_page` in the Flickr API documentation.) I believe at one time you could request up to 4000 results per page (hence the warning “Please note that Flickr will return at most the first 4,000 results for any given search query”), but that has since been reduced to 500. This does not limit you to only the first 500 (or even 4000) results though!

You can certainly request page 41 and receive valid results that are beyond the first 40 pages of 100 results each. I know this to be true, because my FlickrFinder app can and has done just that.

Is this because asking for a specific page is “a more specific query”? Yes, it is.

Maybe Flickr’s API was broken when the video for this lesson was made, but now it isn’t, so all of the discussion about 4000 and the limitations of retrieving photos is now obsolete. This line of code:

let pageLimit = min(totalPages, 40)

is completely unnecessary. Just use totalPages as the pageLimit.