I'm working on a watchOS app to track my golf stats. I've got the UI set up, but I'm running into problems when trying to get data to show up in the different views. Here's my pseudo code to give you an idea of how I've structured things. Each View is its own script, with the Main Menu View being the main one.
I'm using Core Data and I've set up all the entities with attributes and one to many relationships: course, rounds, holes. I can get the course name to load in the main ContentView, but I'm stuck on how to send this data to other parts like Course Cell View or Round Cell View.
I've saved and loaded data with JSON before, my experience mostly lies in working with Unity in C#. But I'd like to use Core Data in this app.
I've watched a lot of the videos from the 'Hacking with Swift' 100 days course, and tried to implement that code into my project, but it's just not working, I'm missing some overarching understanding, and I'm just getting more mixed up.
I've tried using @State, @Binding, @ObservedObject, @EnvironmentObject, and I've googled them to figure out what they are, but I'm just not getting it. The tutorials I've found online just don't seem an exact match for my use case, or I'm just not understanding it.
I'm sorry if this has been asked before or if I'm going over old ground. I'm just not sure what to do now.
Anyone have any advice / ideas / tips on how I can save, fetch, and disseminate data in my app using CoreData?
Thanks for any help you can give!
@Olorin has shanked a ball into the rough...
Welcome to Hacking WIth Swift!
Most students follow the course a day-at-a-time to pick up concepts, work thru the assignements, confirm their understanding, and build on their knowledge as they progress.
Then there's folks like you who have a bunch of programming on their resume and are looking for the HackingWithSwift - Fast Pass course. This course, as you found out thru the YouTubes, doesn't exist and you're frustrated because you're missing some overarching understanding.
Bad luck though, you've also come to HackingWIthSwift at a time when the lastest versions of Swift and SwiftUI had significant updates in June and our host @twoStraws hasn't updated his course videos yet. (In progress!)
See -> What's New in Swift?
In particular, @
But let's see if I can bridge some of the overarching understanding with some simple examples.
Think of a room in your house, your computer room perhaps. What's the state of the overhead fan? Is it on or off? What's the state of the room's window? Is it open or closed? @
Maybe your room object has a sub-view you've designed to use in other rooms. A fancy wall switch, for example. When you flip the switch up or down, you want to take the state of the switch, and push the switch's state to the overhead fan. In this case, you'll define the fan state in your Room object, and bind that state to the on-off state in the switch subview. This way when you flip the switch, the actual value that is changing is the fan's state in the room.
@ObservedObject & @ObservableObject
Your house may have a central control panel that you'd like to use to control lights and fans in the entire house. In this case, you'll define a class object with the states of electrical devices in your home. Because it's a class, the object will stay in memory as long as some part of your program has a pointer to the class. Also, because it's a class, all objects linking to it will share the one object. You'll need to mark properties as
You define the class as being an
Whenever the state of one of the published properties changes (turn on the bubbles in the HotTub), any object that is observing the shared ControlPanel object will have the opportunity to react. In this case, your computer room will be notified that the ControlPanel object was updated, but will ignore the notification because it involves the outdoor hot tub. On the otherhand, the outdoor deck space might respond by queuing up your favorite smoooooooth jazz playlist and dimming the lights.
CoreData vs SwiftData
Also, keep in mind that CoreData was written dog's years ago for ObjectiveC programmers. It was quite clunky to use, and had a steep learning curve for many wanna-be app developers. This year, Apple introduced a Swiftier version of CoreData named SwiftData. This was a welcome relief to many. Now we don't have to learn CoreData and can start fresh with an easier-to-use native framework for persistence. Donny Wals has a great series (and a terriffic book!) about CoreData. But think hard! Do you really want to start this path? If you're new to SwiftUI and iWatch programming, perhaps is just best to let CoreData wallow in the sandtrap. Instead, tee-up on a brand new Par-3 on the front 9.
@twoStraws held a terriffic live event on June 26th and 27th. He spent most of the second day going through the new syntax for
So Far, So Good?
Well if this helps get you back on the green, great. Now that you're selecting your next iron, we're changing the course. The fairway is a little straighter, and there are fewer sandtraps.
@ObservedObject has been deprecated. Don't use it anymore, learn the new way.
@twoStraws relayed to his followers that he's updating the course. It will, naturally, have better examples, and will explain the syntax in full. But his is a work in progress.
In the meantime, FloCodes, Karin Prater, Stewart Lynch, Code WIth Chris, Vincent Pradeilles, Swiftful Thinking, and many other Swift bloggers have posted snips, vids, and commentary on the latest SwiftUI syntax. And aren't you lucky!? Sean Allen just dropped a new 30 minute SwiftData tutorial this week.
Please go find your answers, then come back here, share your findings, contribute to the lessons, and provide links to your app in the AppStore.
Thank you for the detailed response.
That makes sense that I'm having issues as a new version was just released and I'm using older tutorials.
I might sub to HWS+ to view that live event on SwiftData. Also will eagerly await new tutorials for the newest version of Swift.
I appreciate the time you took to respond, and the details you provided for @State, @Binding, etc.. So helpful in understand their use cases.
I will practice more and come back stronger. haha
Fantastic! I've been watching the tutorial and am learning alot.
But his tutorial has given me a question.
Currently I have been structuring my data as such:
A course has rounds, and rounds have holes. So a class for Course, a class for Round, and a class for Hole.
That way the user will be able to select which course they are playing on, and can add a round to it when they play.
However, his tutorial made me think; should there just be rounds, and each round has a course name? Then I can simply sort the Rounds by Course name on the main screen?
I guess my question is, how should I be structuring this data? What do you more experienced coders think?
SPONSORED Take the pain out of configuring and testing your paywalls. RevenueCat's Paywalls allow you to remotely configure your entire paywall view without any code changes or app updates.
You need to create an account or log in to reply.
All interactions here are governed by our code of conduct.
Link copied to your pasteboard.