Day 11-Catchup

Timeline:

• 0800-It looks like I’ve got the Dojo all to myself for now. I wrote up my objectives for the day on the whiteboard. This is what I’ve got so far: Complete My Dogs, finish the Frameworks modules, implement remove, removeAll, and toSortedArray in Swift for my Binary Search tree, and get a head start on next week’s modules (I know I’ll need it).
• 1000-I took a break to investigate an issue that we had with our Parkour app. When we were creating the different views we had to keep passing the same values over and over again between each view controller (namely, start and stop longitude and latitude). This came to be super annoying, replicating identical code across every single view controller. So this morning I set out to find a better way. The best answer I came across was using a Singleton object that all the view controllers could access. The controllers simply modify the singleton’s attributes and then the Singleton object is responsible for making CoreData database conform to its attributes. Meanwhile the view controllers don’t even know or care about CoreData, they just know they can get data whenever they need it from the singleton and store it in a way that will persist even after the app has closed. Pretty neat, huh? There’s just one problem. Singleton’s are evil. This is for several reasons. They promote tight coupling (no class can get by without them now) and persistent state (that’s what you built them for, right?), which in turn severely hinders unit testing. This is because both persistent state and tight coupling mean all of the view controllers are interconnected. Interconnected things are complex (as opposed to complicated) things. Complex things are difficult to predict (just ask a meteorologist). If you can’t predict how that thing will behave you can’t test its behavior, leading to difficult to reproduce bugs. Bugs lead to hate. Hate leads to the dark side. So what’s the alternative to the dark side? prepareForSegue, which it turns out is what we were using to begin with. Ultimately, the TLDR ends up being that for hackathon projects it’s probably best to go with hacky answers like the singleton pattern. But for commerical-grade projects the formal prepareForSegue is the safest, industry-accepted answer.
• 1200-Finally finished the My Dogs App. Moving on to the second half of the Frameworks modules.
• 1930-Made it through the Frameworks module. It covered CoreData migrations, relationships, as well as the AVFoundation and CoreMotion APIs. It was a lot of material to cover, but I think I’ve got a pretty good grasp on it. I won’t be able implement the BST functions like I had planned, although I did read a little bit into next week’s lessons. It looks like we’re going to be studying JSON and webservice integration.