I created a Core Data store to hold up to 10 recent recipes. The same rules apply. I save a new recipe every time we load a new recipe in the HomeViewModel. This works when viewing a random recipe, showing another recipe, opening a search result, opening a recent recipe, and deep linking to a recipe. On the home screen, I do a fetch request to sort all the recipes by timestamp (with animations when the recipes shift around).
Unlike the web app, I don't create entities for all sub-types of the recipe. To make things simple, I transform the whole recipe into a dictionary and only extract the id as a primary key. The timestamp acts as the sort key. It was cool learning about where this and UserDefaults was stored on the simulator and real devices and how to lookup the device and app UUID using some obscure CLI commands.
I found it interesting that Apple now recommends using the default SQLite store, but save files to /dev/null. Previously (and I was taught that), Core Data had a designated in-memory store type for unit testing. But I guess sticking with SQLite and using this workaround ensures all operations are compatible for testing and improves performance.
One of the biggest challenges I faced was getting the SwiftUI previews to work using the in-memory store. It was a scenario where the app runs fine on the simulator, but crashes the previews, even if I use the in-memory store in both cases. The solution was to remove the NSEntityDescription from the convenience initializer for my custom RecentRecipe model class. Following Apple's sample SwiftUI Core Data code to the tea helped with understanding Apple's demon magic.
Inb4 I start migrating to SwiftData once iOS 17.0 becomes the deployment target...
While working on this PR, I realized the build error was due to how the path was specified in project.pbxproj. It's not the first time I encountered an absolute path in these files. (Maybe because the model had a space in it to match the project name?) Thankfully, I was able to edit the path manually without corrupting the Xcode project.
The iOS implementation of https://github.com/Abhiek187/ez-recipes-web/issues/14
Me after implementing Core Data: 😵
I created a Core Data store to hold up to 10 recent recipes. The same rules apply. I save a new recipe every time we load a new recipe in the
HomeViewModel. This works when viewing a random recipe, showing another recipe, opening a search result, opening a recent recipe, and deep linking to a recipe. On the home screen, I do a fetch request to sort all the recipes by timestamp (with animations when the recipes shift around).Unlike the web app, I don't create entities for all sub-types of the recipe. To make things simple, I transform the whole recipe into a dictionary and only extract the id as a primary key. The timestamp acts as the sort key. It was cool learning about where this and UserDefaults was stored on the simulator and real devices and how to lookup the device and app UUID using some obscure CLI commands.
I found it interesting that Apple now recommends using the default SQLite store, but save files to
/dev/null. Previously (and I was taught that), Core Data had a designated in-memory store type for unit testing. But I guess sticking with SQLite and using this workaround ensures all operations are compatible for testing and improves performance.One of the biggest challenges I faced was getting the SwiftUI previews to work using the in-memory store. It was a scenario where the app runs fine on the simulator, but crashes the previews, even if I use the in-memory store in both cases. The solution was to remove the
NSEntityDescriptionfrom the convenience initializer for my customRecentRecipemodel class. Following Apple's sample SwiftUI Core Data code to the tea helped with understanding Apple's demon magic.Inb4 I start migrating to SwiftData once iOS 17.0 becomes the deployment target...
While working on this PR, I realized the build error was due to how the path was specified in
project.pbxproj. It's not the first time I encountered an absolute path in these files. (Maybe because the model had a space in it to match the project name?) Thankfully, I was able to edit the path manually without corrupting the Xcode project.