I am designing an exam practice app that will have the following format, requiring the user to rank the answer 1-5 to sections A-E (using a scroll view) for the same question that will be displayed at the top.
Here is an image:
Each question therefore has 5 parts. I am unsure of what is the best way to store the questions and answers. I read something about plists. Would that be the way to do it? If so, could you recommend any tutorials with images?
Just to clarify, the labels A-E are where the text for the subsections will go and the user will have to rank the appropriateness for each of these.
Thank you!
Few options here:
1. Core Data
Prepopulate .sqlite file with questions and include with app. Keep track of user's progress and attempts and whatever other stats.
This approach also give your ability to label questions by a topic (or any other criteria) and present questions to user that they need or that they failed most.
2 Get data from server
A bit more complicated but offers more benefits. With this approach you would be getting questions in json format.
Benefit of this approach is that you can add any number number of questions and tests without resubmitting your app.
3. Store as text/plist with app
Yes, you can also store your questions as text in plist or json format and as app loads populate core data or keep it in memory to display. The latter approach, however, would offer the least amount of benefit and flexibility to the user.
I suggest using SQLite. See Ray Wenderlich's Tutorial on SQLite for iOS
And there is obviously a not so suitable but easy way and that is using property lists as key and value pairs which i do not recommend.
Related
I am creating a very simple flashcard app. It is a very basic app, the initial screen asks users to select a language. From there they pick from 5 categories. After selecting a category the user should get a random question (out of 20 possible questions).
My question is I want a question to not show up again within that set of 20 until all the other questions in that set have been shown. Similar to a deck of cards where the viewed card goes to the bottom of the deck.
The second question is what framework would be best for this application. There are 200 questions in total, all text, no images. My inclination would be to use something like core data or would that be overkill?
Any help on how to best implement this would be appreciated! I've attached a picture for further clarification.Storyboard Layout
You're doing a great job so far.
There are many ways to track your cards. The simplest might be to add a Boolean property to the card definition. Call it something like "hasBeenAnswered" and set it to false. As a card is retired you can set this to true. Refresh your data source after a correct answer by removing the card from your data source and also setting the book to true, or simply set it to true and replace your data source with all cards which are set to false. (Perform the same fetch you used to get your initial set of data: all cards where hasBeenAnswered is false)
On your second question I'd try to learn Realm. It's easier to pick up than core data, and as a cross-platform tool, you can leverage what you learn on iOS if you ever try to develop on mac or android platforms.
You can also refactor the project to core data after it works the way you want to. And learn even more.
The suggestions I've made are not the most resource efficient, but you won't have any performance issues given the size/scope of your project.
Good luck 🍀
I'm creating an iOS trivia game that will have between 1,000 - 10,000 questions in it. Each question will have only two possible answers, so the amount of data per question will be very small.
I'm wondering if I should use Core Data to store the questions or if I can use a large dictionary that I populate when the app loads up?
Would either of those choices work or is there a better solution I haven't considered?
The 'best' way to store these questions depends heavily on your internal data structures, memory usage and source data structures.
How do you receive the questions? If they are an XML then you might like to preserve that structure and implement an XML parser. If Excel format, export to CSV and read from that. JSON: load into an NSDictionary.
If you want to add these into Core Data or sqlite and the source questions are in a different format, you will have to write a parser and importer. Then, if you update questions you will have to create a merge policy etc.
Personally, if you can keep the original format of the data without complicating code/exceeding memory I would keep it simple and go for that - that way, you can replace the source file and it will just work.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have an app that showcases paintings, the number of paintings is about 600 ( so thats 600 png's ). The client wants me to include those images in the app build, so that they are always available to view even if the user if not online. Of course with every image comes some fields like description, painter, and price estimate, so this app will not stream anything and will have all of its data locally.
Anyway I am thinking of the best way to build this app, I thought of core data, and even encoding decoding, but since These images wil never change, I can put them in an images folder and on viewdidload just loop over contents of the folder and build my tableviewcells.
my question is :
1 : Is this a good architecture?
2 : I need to associate those images with the relevant description of them? whats the best way of doing this? If I jump into core data and create models I feel this would be an overkill.
Keep in mind that these images will never change, nor will the data be updated.
Thanks.
A couple of thoughts:
As discussed in your other question, I think that loading all of these images in the app has its disadvantages, given that you say that the app ends up being 300mb. If it is, indeed, going to be larger than 50mb, then I think you might want try to dissuade your customer from insisting that all of the images be included in the app, itself. I understand that you might not be able to convince them, but at least make sure they understand the implication of including all of these images (that it makes it harder to install the app and therefore, they may experience a lower adoption rate of their new app).
Storing the relevant description of the images in Core Data is a good approach. You could also use SQLite (e.g., via the FMDB wrapper), but I'd really encourage you to just use Core Data unless you have some other considerations you haven't shared with us. But a lot of other traditional solutions for simplified persistent data (plists, NSUserDefaults, etc.) might not be appropriate for this many records. Core Data is great and really isn't that complicated. Sure, the first time you use Core Data, it takes a little getting used to, but it seems well suited for this amount of data.
You talk about "encoding and decoding" of the images, and you haven't described anything that would lead us to suggest that sort of process. What encoding/decoding are you contemplating? It's probably easier to just store the images in the local file system (in the bundle if included in the app, elsewhere in the file system if you're downloading the images on the fly).
You mention that you might have "viewDidLoad just loop over contents of the folder and build my tableviewcells". Perhaps I'm reading too much into this (in conjunction with your other question's comments about receiving memory warnings), but given that you are talking about keeping the images descriptions in Core Data, you don't need to be iterating through anything in viewDidLoad. Your UITableViewDataSource methods will simply query the Core Data database and present the appropriate information. I don't see any need to be iterating through anything in viewDidLoad.
I did a similar kind of application some time ago. I used unique code names for the images and created a Core Data DB that would have one column associating the according line of data (description, author, ...) with the "code" name of the image (i.e., 2347.png).
My model was something simple like this:
NSNumber *imageCode // the number that you would use to associate to your images
NSString *name
NSString *author
NSString *description
I'm assuming that you know how to use Core Data.. if you don't, you can refer to this website: Core Data on iOS 5 Tutorial: Getting Started .. it is really helpful!
Hello Oracles of StackOverflow,
First time I managed to ask a question on stack overflow, so feel free to throw your cabbages at me. (or correct the way I should be asking my question)
I have this problem. I'm using HDF5 to store massive quantities of cookie information.
My Data is structured in the following way:
CookieID -> Event -> Key_value Pair
There are multiple events for each cookieID. But only one key_value pair per event.
I'd like to know what the best way I should store this in a HDF5.
Currently, I'm storing each cookie as a seperate table within a group in the HDF5, using the cookieID as the name of the table. Unfortunately for me, with 10,000,000 cookies, HDF5 (or specifically PyTables) doesn't approve of this type of storage.
Specifically throwing this error:
/CookieData`` is exceeding the recommended maximum number of children (16384)
I'm wondering if you could recommend the best way of storing this information.
Should I create a flat table? Should I keep this method? Is there something else I can do?
Help is appreciated. Thanks for reading.
Several hours of research later, I've discovered that what I was attempting to do was categorically impossible.
The following link gives details as to the impossibility of using HDF5 with variable-length nested children.
I've decided to go with a flat file for the time being and hope that this is more efficient than a database store. The problem with a flat file in the end is that I have to replicate values in the file, which otherwise should not exist.
If anyone else has any better ideas it would be appreciated.
I am struggling improve the search speed of my iOS app which uses core data. Can anyone help or suggest alternative solutions to improve my search speed? I've listed details to my situation below.
Project Details
I am currently creating a data reference app which uses core data with a preloaded SQLite database. I want to be able to search on one or more attributes of an entity which could contain over 100000 records and return results quickly.
The best results I have achieved so far(searching still quiet slow though) is to load a view with a search display controller, set the fetch limit(currently 100) for the fetch request of the fetchResultController. I've also used search scopes to simplify the predicates. I do use the 'contains' keyword in my predicates, but I am not sure how to implement the suggestion in session 137 of WWDC 2010 and what keywords I should be storing or how many I should store.
Here is a link to one of my classes,
http://pastebin.com/cHHicc1s
Thank you for your time and help.
Regards
Jing Jing Tao
You may want to normalize an existing attribute as a new attribute then index it. Remove the "CONTAINS" from your predicate and instead use >= or < etc values. Also, normalize the search text so that the comparison balances. Apple documents all this in the 'Derived Property' example and in WWDC 2010 session # 118 video.
If you are doing large searches on attributes, you should create indexes. You can do this in Xcode when you define the model. Click on the entity, and right under where you specify the entity name, you can create additional indexes.
Note, however, that you will incur additional file size overhead, and inserts/deletes will also take a bit more time. But, your searches will be very fast.