Lesson 9 from the finale added the steps to save to Core Data, after which I embarked on a project of my own.
I noted in my first post on this module that Chris was using a version of the Recipe App from Module 4 of the iOS Foundations course that didn’t include the work we’d done in the Bonus module. The bonus module enhanced the Recipe App to include a “category” screen that grouped/filtered the recipes based on their category attribute.
To do this module, I removed / commented-out all of the “category” additions from my Recipe App and proceded through Chris’ tutorials.
Having concluded the final lesson, I thought it would be enterprising to reintroduce the “category” code back into the app. I figured that I must have learned enough by now to be able to do that little thing.
I was wrong.
What I didn’t count on what the finicky way SwiftUI requires code to be written, and where it can be. Or that, if you get it wrong, Xcode comes up with unintelligible errors and warnings that do nothing to help you resolve the issue.
I spent more than one day going into the errors, searching the ‘net for clues to decipher the error message and hints and what I could do to fix it, but I got nowhere.
The main problem appears to be that any search result that comes up that’s more than a couple of months old is invariably dealing with UIKit and not SwiftUI. UIKit is the older language where, oftentimes it seems, the philosophy is “why have a short piece of understandable code when you can have several lines, several functions, all filled with unclear code and properties”. The last thing I wanted was to include even more (unneeded) code into the project to solve what should be a simple problem.
I even started watching the CWC Core Data Tutorials course that appeared on my CWC dashboard after a recent revamp, but that seems to be older lessons of Chris talking us through the UIKit way of doing things – with Delegates and all manner of other things.
I tried taking our current project from the end of this module and uncommenting the “category” code before altering the code to adapt to Core Data, but I couldn’t get by the errors.
I even went through the module again, this time keeping the “category” code live and tweaking it as necessary to fit the module, but I still can’t get beyond the errors.
After taking a break, I reluctantly realised that I’m going to have to mark this down as a “failure” and hope that, sometime in the future, I’ll be able to look back on this and know enough to fix the errors. As Clint Eastwood’s Dirty Harry once said : A man’s got to know his limitations. I think I’ve hit mine.
On acknowledging this, I also had a little revelation.
The code in question takes an attribute (category) from each of the recipes, and creates a Set to ensure there are no duplicates. Because I’d been bogged down in trying to solve the errors, it hadn’t occured to me until this point that this is the wrong way to handle this anyway. The categories should be in their own table set, with the recipes referencing which category they’re in by means of an index/id field. That’s how I’d do it, because that’s how I’ve always handled this kind of thing before.
Repeating something like a category name throughout the Recipe dataset isn’t adhering to the principle of DRY (Don’t Repeat Yourself). And having the category data in a separate table allows you the flexibility of renaming them, and using them elsewhere, without having to search & replace multiple copies strewn throughout the entire data set.
I would have seen this before if I hadn’t got bogged down in the error messages. Oh well, at least that’s a lesson learned. Maybe this is the reason, and maybe the errors too, why Chris didn’t use this version of the Recipe App in his tutorial?
Time to draw a line under this one for now and move on. I only have a limited time in which I can access CWC+ before my money runs out, and I can’t spend any longer on this one. Core Data is truly far more complicated and confusing than it needs to be.
