NEW: My new book Pro SwiftUI is out now – level up your SwiftUI skills today! >>

SOLVED: How would you structure this in Core Data?

Forums > Swift

Hi,

I am relatively new to swift and I am making an app where there is the following data structure:

An excercise can contain multiple stages and each stage can be one of two types. One type is a count down timer, the other a tap counter, and possibly in the future at most 3 more types will be added, that won't have to store many new attributes.

I am using core data and I have everything working regarding adding the stages, but I was wondering if you would create a separate entity for each type of stage, or just have one entity for the stages like I have now where the unused attributes for the particular type (for instance tap count when it's a count down timer) are left empty. These stages are then related in a many to one relationship with the practice.

Or is there a better solution? Since I am relatively new I would like to avoid unnecessary complexity, but would still like to make an appstore worthy app that could grow in the future.

Best regards,

Florian

   

Florian wrestles with data structures in his exercise application:

An excercise can contain multiple stages and
each stage can be one of two types.
One type is a count down timer, the other a tap counter, ... snip ... would [you] create a separate entity for each type of stage, or just have one entity for the stages?

It seems you defined a one-to-many relationship. One Exercise object might contain many Stages.

From your description, a Stage object might contain different properties. That is, one type of Stage might have a Counter property collecting repetitions. (Perform 15 Push-Ups.) Another Stage object instead will have a Timed property containing the value indicating how long a Stage should be performed. (Hold a plank position for 90 seconds.)

Protocols

I think this is where the power of Protocols may help. Map your two Stage objects and determine what is similar to both. This might form the basis of your Stage protocol.

Your Exercise object will contain an array of objects that define the particular goals of that exercise. Each object in the array should conform to your Stage protocol.

This will allow you to build views using ForEach and list all the Stages for an exercise regardless of some of the design differences. Additionally, you should be able to add more Stage types to your appliction without much change, as long as the new objects conform to your Stage protocol.

Using protocols, you can enforce the similarities between Exercise goals, and eliminate the need to define properties that would be unused because of its Type.

   

In addition to @Obelix.

You can create an abstract entity in CoreData for your Stage. Just check the box in the inspector tab. Then you can use this abstract entity as a base for your specific stage and you can define the special needs for it there.

   

Thank you very much for your responses, I just wanted to confirm something about the setup in Core Data:

Excercise has a one to many relationship with Stage and stage is an abstract entity

The entitities TimerStage and CounterStage have set Stage as their parent entity, but don't have relationships themselves

Is this correct? Or should Stage not have the relationships, and should TimerStage and CounterStage have the relationships?

   

If I remember correctly Stage should have the relationship.

   

Hacking with Swift is sponsored by Play

SPONSORED Play is the first native iOS design tool created for designers and engineers. You can install Play for iOS and iPad today and sign up to check out the Beta of our macOS app with SwiftUI code export. We're also hiring engineers!

Click to learn more about Play!

Sponsor Hacking with Swift and reach the world's largest Swift community!

Reply to this topic…

You need to create an account or log in to reply.

All interactions here are governed by our code of conduct.

 
Unknown user

You are not logged in

Log in or create account
 

Link copied to your pasteboard.