Day 38 - Phantom Errors
Today began with a discussion of Core Data, going into more depth than the reading from the night before. Essentially core data offers you a means of persisting data from one session to the next. There are other ways, but core data is the easiest and fastest way of doing it without using a network.
It’s fairly easy to set up. Xcode offers a nice way of adding entities and attributes, and creating the relationships between those. Then you just have to set up a context through which you can communicate with the database, which is just a SQLite file. Migrations aren’t quite as easy as with ruby on rails but they’re still easy.
Class was spent working on a simple diary app where users can write entries, attach photos, tag friends, and retrieve all of them in a table. Ran and I changed the theme a tad and made it an app to store secrets instead of entries in a diary. The whole point of the project was to get used to using core data. I felt like we achieved that goal and thanks to Ran's kickass design skills, our app looks great too.
At some point during the day, Ethan coined the term phantom errors for all the warnings and error marks that Xcode won't immediately discard even when the errors no longer exist. If you use Xcode, you know what I mean. And if you're not paying close attention, you can easily end up spending a lot of time debugging phantom errors.
After class Ned gave a lecture on depth first tree traversal. He used a variant of the knight’s travails ruby quiz as an example. In his variant, returning any path would suffice. In the actual quiz, which Eddie and I completed awhile back, you have to find the shortest path, which requires a breadth first approach.
