Learning Core Data sanity check

I have an app that is like a questionaire/survey form in format. I'm building for iOS9 and above using Swift, and Core Data. I created my Core Data model simply by having the Xcode template generate the boilerplate code in the AppDelegate when I created the project. I created an Entity called "Person" with attributes for name as a String and date as an NSDate. The rest of the questionaire/form consists of radio buttons that the user can check from a series of sections and areas through out the form where they can actually type in a response for "other". In the end the last screen compiles every selected answer with there name and date at the top. I think this could be a real simple introduction to finally learning Core Data and using it in a project.


My question is: Should I create a boolean attribute for every possible selectable question or is there a better way to handle that? It seems quite repititous to create an attribute for every possible selection? If I supplied an "answers" attribute for the Person Entity of type NSArray would it be a better solution? I would have to hold all those answers til the end I suppose since you can't add to the array over the course of filling out the form I would think? (I can't keep adding to the Array every time they select an answer right?) I have seven screens with questions and spots through out the form for text entries. It seems like even making an attribute for all the "other" selections where they type in an answer is quite repititous too. However typing in an answer (a String) is different from "is something selected or not?"


How would somene experienced with Core Data handle this? Is it best to just make an attribute for everything? Something about getting the Entity portion right seems important and more uncomfortable to change later so I want to make sure I set this up for a better chance of success than otherwise. Any advice on breaking down the attributes of the Person entity would be much appreacited.

I'm not sure if I'd use Core data to do a questionaiire app like this..how many questions are in the survey?


You could create relationships between entities, so you don't have to store everything as attributes.

You could create an entity for questions, too. Then you make a relationship between these entities as already mentioned. In the question entity you can now create a Boolean attribute which you could use in your code. Hope this helps.

I have 102 questions broken up in sections so not all 102 will ever be answered yes. For examle where does this meeting take place is one of the questions the answers are "Home" "Office" or "Other" so they would just touch the radio button that applies and that answer would be the correct one. Maybe I shouldn't use boolean values at all for that. I just thought is something selected vs is it not selected is easier. I'm open to what would be an easier solution than Core Data if you have something in mind.

I currently have an Entity for the person taking the suvery and another entity for the questions on the survey. However I'm not sure if I have to list 102 boolean value answers in that questionaire/survey entitiy. If so I guess setting them all to false to start is best? When I press the custom radio button to mark the question as yes in my tableview cells I'm not sure how that will translate to changing the default false value in the survey entity to true. I have this survey broken up between seven screens each screen with a table view on it. Maybe an entity for each table of yes/no questions is better?

If you only have 102 questions, using Core Data seems unnecessary. You could just store them in a plist file. If there are multiple choice questions, make the plist file as an array of dictionaries.... key value pairs for the question and potential answers.

This sounds very compelling. Let me give you a little more context to see if this still makes sense. I'm making a client survey form so the app would have a list of clients. (Those would build up in a tableView) Each client is giving the same types of questions (hence the form) and each client would have its own set of answers based on the questions. For example one client might have "home" selected for where did this meeting take place. While another might have "office" for that same question. I like this idea better because its easier for me to type out the list of hiearchies of arrays and dictionaries. What do you think?

I second a plist, but only if your needs are generally straight forward, such as multiple choice/drill down with just a report/score at the end.


Or are the responses analyzed? Just for the user, or are they exported and then processed? What type of backup is needed? Who will use any exported data and what form does it need to be in for them? What type of security will the data require?

Accepted Answer

What I would do, as a first try is:


  • An entity to identify each person, say Person with:
    • Relationship (to many) to SurveyQuestionAnswer
    • Whatever attributes needed
  • An entity to identify each question, say SurveyQuestion

    Whatever attributes the question needs, such as question text

  • An entity for each answer, say SurveyQuestionAnswer, with:
    • Relationship (to one) to Person
    • Relationship (to one) to SurveyQuestion
    • Attribute to represent the answer entered
    • Whatever other attributes are needed, such as the time the answer was entered

Maybe that's overkill if you're just storing yes/no answers, but it gives you the ability to examine answers either on a per-person basis or on a per-question basis.

But this is really the point where you need to be deciding what you're going to be using the data for.

I see what your saying. I think I will give it a go the way you mentioned since the whole point is to learn Core Data.

Quick question....

The design of the app makes the set of questions span across seven differnet table view screens. If I create the Person entity on the first screen when its loaded is there any problems with keeping that entity alive with its selected questioned saved between screens? Like how does Core Data know that that the Entity created in screen 1 should move over to screen 2 and keep going with updating the answers to questions? I assume I have to pass the entity along all seven screens saving "in progress" during segues until I can hit the save button to finalize the survey/questionnaire?

Big thanks to everyeone for the recommendations and suggestions with crafting this model portion of the project. Its been a big help.

Learning Core Data sanity check
 
 
Q