I need to figure out how to store the data for my application.
Its a language app so it will store thousands of different words in different languages.
The data will be read only but I may need to update the data if I add new words at a later date.
So whats the best way -- in a file or a database -- and where should it be stored? Within the application or sent down to the SD Card.
Any advice in the simplest terms would be greatly appreciated.
Related
when I develop an iPhone App (Time Tracker, ToDoList etc) I never know whats the best way to deal with the data. Once I used a plist, next time sqlite or CoreData.
How do you decide whats the best for your project?
(Only talking about data management)
For Example if you want to develop:
Time Tracker App > Is PList your choice?
RSS Reader App > CoreData?
Photo App > sqlite?
EMail Client > ?
For a beginner can you point me roughly to proper directions?
(I know it depends a lot on the App and what you like to do with
it but any thought will help)
I'm far away from developing complicated apps, they are still pretty simple.
Thanks for help,
Marc
You can use these rules of thumb to decide what storage model will work for your app.
If the data fits in memory entirely and is relatively unstructured, use plist
If the data fits in memory entirely and has tree-like structure, use XML
If the data does not fit in memory and has a structure of a graph, and the app does not need extraordinary query capabilities, use Core Data
If the data does not fit in memory, has a complex structure, or the app benefits from powerful query capabilities provided by relational databases, use sqlite
If the data must be secret (e.g. a password), use keychain.
Note that these choices often overlap, because multiple storage models will fit the same app. Your final decision depends on your personal preferences - you pick a technology that you understand better.
There was a very good question about sqlite vs. Core Data on Stack Overflow, you may want to read through the answers to that question.
My rule of thumb for each of those would be:
Time Tracker App > Core Data
RSS Reader App > Core Data
Photo App > Core Data
EMail Client > Core Data
Though in each case there would be things you would store on the file system. For instance, the photo app would obviously put the actual photos on the file system. The text of the emails would be on the file system etc. The actual RSS messages might be text files too, but with meta data in Core Data objects.
At some point, you might find that the data you are storing is outgrowing the scalability of Core Data. At that point you would consider moving to SQLite.
The point is that Core Data is so easy to use and so superior to the alleged lighter weight alternatives, why wouldn't you use it?
What is a good way to store many key/value pair entries in a mobile (iOS) application, such that they can be easily exported/imported?
I have considered a single large JSON file - would this be too slow/large with 200,000+ entries?
I have also considered CoreData - but could the data be moved easily via, for example, email?
Think of an address book. Contacts can be easily imported/exported, what data storage model would be comparable?
Thank you.
EDIT: Examples
Notes - be able to select and view short notes in a table. Each note is < 100 characters.
Saved bookmarks - each bookmark is stored in a table.
I have considered a single large JSON file - would this be too
slow/large with 200,000+ entries?
I don't know. I can make a guess. The guess would be yes, it's both too large and too slow. However, you can always test it to find out.
I have also considered CoreData - but could the data be moved easily
via, for example, email?
That depends on how you want to share the data. You call email easy?
Core Data is a framework. You can use any type of backend you want (you can even write your own). The most common is probably SQLite.
If you use Core Data, you can keep the data files in a separate subdirectory and copy them just like any other file.
However, if you want to share data via an online service, you may want the ability to import/export JSON files.
If you are talking about synchronization, then that's a different beast entirely.
Basically, there is no single right answer. You have to assess your requirements, and then determine which solution meets your needs.
On the surface, it seems like using Core Data would be a good fit, but it depends on how you want to use the data in your application. Only you know that answer.
Newbie question - I would like some advice on the best persistant data type to use.
Requirements:
Data to be stored : Simple text and pictures
App Type: Information app featuring drill down tables and detailed view screens with several images on screen.
Data Updates: Yes, the app will be updated on a regular basis with new text and images, (updates preferable downloaded in the background, whilst the app is running and this data will be stored)
Can anybody offer me some advise as to the best persistant data type to use to.
Thanks in advance.
Choose SQlite database. You can store text and pictures there.
I'm a new developer. Recently, I'm developing a note app on iPhone with Evernote API. I have read many pdf, such as Document-based application.pdf, evernote-api.pdf and so on. But all these do is teach me how to sync with Evernote and how to design the document class. No one talks about local store mechanism.
I have designed a local store mechanism by myself; here it is:
Store all notebook/tag info in a plist file, such as which note in which notebook, which note has which tag, all of notebook/tag/note is represented by unique guid in plist.
Store each note content in their own file, with the note guid as their file name. That means however many notes the user creates, there will be the same number file on disk.
How about this local store mechanism? Is it good or bad? Any suggestion is welcome.
What's more, should I use Core Data (database) in my project?
And how can I sync with Evernote?
The most popular way to do it is to use CoreData framework. It makes easy way to store different values of your Data Model in sqlite file in local storage of device. Look at this tutorial from apple.
You have a valid approach. I think it's especially good, if you expect big document lengths. If you only expect short notes, you can use any of these: coredata, nsuserdefaults, basic nscoded arrays, textfiles, etc.
Hey guys,
what would you say is the best way to ship initial data with an Core Data iOS App?
Is it maybe to once run the app, store the data and then insert the datafile in the build?
There must be a better way..
I have had good experiences with loading the data into a sqlite backing in the simulator, and then bundling the resulting sqlite file with the app.
Especially for bigger datasets, first-run filling of the database is not really an option.
I've been toying around with the same problem myself, recently; and what I opted for was to store the data in the app in some easily parsable (for me) format, and parse and incorporate it on first run.