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 7 years ago.
Improve this question
I'm confused about what would be the best data storage (plists, SQLite, Core Data etc.) for my iPhone app that is navigation based and has all kinds of lists and info. I'm very new to this and the multiple types get me confused.
For example, first view is a table view for type of recipe (Ex. Cookie Recipes), second view is also a table view for all kinds of cookie recipes (Ex. Chocolate Cookies), third view would be the recipe for the Chocolate Cookie (numbers, text etc. stored).
It would be a non-static app, that would make the USER create the table cell "Cookie Recipes" and then create the "Chocolate Cookies" and also input the info for the chocolate cookies.
Property lists are very handy when you have static data. There's a structured editor built right into Xcode and they show up in code as instances of NSArray and NSDictionary. But they aren't really designed for managing changing data, they are just a serialisation format.
If the user is editing complex data, you're better off using Core Data or SQLite. Core Data is a higher level interface designed to be used with Cocoa. SQLite would do the job as well, but I'd probably suggest only using that if you are already familiar with it.
Related
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 yesterday.
Improve this question
I'm from a development team at a large Telecom, I'm migrating an API within an app, the new version of the api will have a completely new model, with a new structure, the data coming from the api is recorded in the coredata and then extracted from this to be displayed by the viewcontroller (cashe), the client asked to do it in stages, and the first stage is to migrate to the next api to deliver value quickly, I am in doubt if I implement the entire model at this first moment, having to change the entire structure that extracts the model from coredata to display, or if I just create a mapping from the new model to the old one (mapping the new values to the old ones), just to record the data, maintaining the structure of extracting data from coredata and display, leaving this to be removed in a next step. Which of the two ways will take more work? Changing the model and also the recording and extracting structure will be much more costly, which will extend the work to unacceptable deadlines?
One of the goals is to completely remove the CoreData.
I'm in the process of renaming all the fields, changing the model's structure and the model's recording and extraction flows, but I'm thinking that this work will be huge, not having any value delivery in the short term.
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 6 months ago.
Improve this question
I am brand new to ios development and am looking for some advice on the best way to structure my user data and access it throughout my app.
Data is retrieved via HTTPS requests that query a database for the desired information. There are separate calls for the different tables containing information of interest. The returned data is formatted as nested dictionaries where the outermost key is the column and the subsequent dictionary is key-value pairs of the index and the table value. Example:
{"column1":{"0":"value1-1", "1":"value1-2", "2":"value1-3"},"column2":{"0":"value2-1", "1":"value2-2", "2":"value2-3"}...}
My primary requirement is that I will need to be able to filter this data by the innermost values (some will be dates, some will be numbers, etc). I would like to have the data in a format that will make this simple to do and will not cause delays as there is no limit on the number of possible rows.
I have looked into reconstructing a user-specific SQLite database with the information and querying that throughout the app as necessary. I have also explored dataframes as this app was originally developed in python - don't ask - and relied on pandas dataframes.
I know this decision will impact me heavily and am trying to do my best to make an informed decision. I appreciate any feedback and am happy to give more useful context that might be missing.
TIA
You can use SQLite database for persistent storage. This is ideal for your main requirement of filtering the data. You should also create a structure or a class modelled on your data to store and use during runtime. You can refer this for deciding between a class or structure.
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 want to create a searchable database in Xcode - for example, of different trees. The database would consist of the tree name, two images, price, and a short description. What is the best and most efficient way of creating such a database?
I am aware of: Core Data, SQLite3, and Parse. I am leaning towards SQLite3 but have not found a good place to learn how to implement this. Any suggestions?
Seeing as you are new to Objective-C and I doubt this will evolve into something need direct SQL I would suggest using CoreData. Although it is not technically a data base it is an object graph, it is built for exactly what you are wanting to do. Apple was even nice enough to build wrappers for everything you want to do.
CoreData to store your tree name, two images, price, and a short description.
NSFetchedResultsController for grabbing it.
UISearchBarController for letting the user search.
You would want to use Parse if you wanted to save your data to a server. If your doing everything locally I wouldn't worry about Parse. CoreData is what you want.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I would like to create an application that stores 3 informations:
the patient's name (string)
the test result (int) and
the date of testing.
In the first UIView, a TableView will show up with a list of patients. By clicking on any cell in the UIView, the list of tests with dates that the patient performed is shown. I'm just starting on Objective-C and have not found the best way to do this. Using Core Data and SQLite? Using a .Plist file? And for arrays? I will create 3 arrays?
My first idea was to create an NSMutableArray of patients and each associate a test, but in this case for a patient to carry out various tests, his name will shown repeated in the list of patients. I couldt find thought how could filter theNSMutableArray` (with predicate?) To display the test data for a single patient in the next screen. Any ideas?
Your question is a bit too generic to answer it properly.
But if you save patient information you should definitely consider encrypting the data.
CoreData sounds a bit overkill if you save a very limited amount of data and you don't want to worry about data management, schemas and migrations.
A PLIST storage sounds like a perfectly reasonable solution.
Regarding your data structure.
You have an array of patients in your first view. When you select a cell to get to the next view, you'll pass the selected patient to the next view.
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 9 years ago.
Improve this question
I'm currently in the process of learning iOS Programming by creating a small game. This game is going to be a sports management style game which will mean there's a hefty amount of initial information that needs to be included in the app. For instance, Players, Clubs, Countries; all of which will be pretty large and will be relational.
From there I'll need to store the state of that data when a user saves, for instance a player may have changed club in the save and so the data in that particular save will be different from the initial data.
I've been looking into pLists, CoreData and SQLite but I'm unsure of which to use or how to combine them? Potentially have initial data loaded into the app from an SQLite database and then archive the objects from there?
Any help would be appreciated.
I'll suggest you CoreDate for keeping Players, Clubs, Countries. Your model will be then relational, and it's quite easy to retrieve the infos you need later. For the game settings, user's score, you can use NSUSERDEFAULTS which allow you to store small data individually.