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.
Related
I am planning to develop a quiz app in iOS and doing it offline. I need to store 100s of questions and options in that app. How to store? How does core data comes in handy here? Is there any other good methods for this problem?
The app is meant to be offline.
You can also use SQLite database for saving Questions and Answers offline for your Quiz app. You can create tables in SQLite and save and fetch data from that using SQLite queries.
I would recommend you to use realm.io. It measures better than core data, its fast and simple to use. On https://realm.io there is lots of documentation.
I find realm much easier to set up and in generally to comprehend. It works nicely with SwiftJSON and hence in my view much easier to connect to backend.
Preloading core data can be quite cumbersome and to me it seems that core data still relies heavily on objective c.
On the other Core Data is made by Apple so it could be more stable solution on longer run (parse.com)
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?
Im using a strategy where I'm saving images and pdfs as NSData in the respective managed objects where they belong. I'm having a problem syncing with Ensembles that the pdf doesn't always carry over from one device to another. Now I'm not sure if this is due to some flaws in my code or if it's not a good way of syncing chunks of data like this. Does anyone have experience of this?
I'm using Ensembles 2.2 syncing through CloudKit.
Ensembles should handle this fine. I use it for exactly this purpose, syncing image data including PDF.
I would look closer at the handling of the data. Is the value transformer working (if you are using one)? Is the device capable of unpacking and displaying the PDF data?
An alternative to syncing the PDF directly is transforming to a format like PNG before putting it in your store.
Transformable data type is really just binary under the covers with some additional metadata. Have you tested a simple lightweight migration on an existing store? I suspect the migration would work and would leave the existing data in the store.
If you are looking to get the existing binary data actually moved out of the SQLite file then you are looking at something a bit more involved.
A heavy migration will accomplish what you are looking for but if the stores are large it may take took long and potentially not provide enough feedback for a good user experience. I personally do not use heavy migrations, ever, on IOS but it will accomplish your goal.
An export/import will also work. I generally recommend export/import when a lightweight migration won't work. It involves a medium amount of code but in the end you own the code, understand the entire process and can tweak it to your exact needs.
I'm trying to build a flashcard app that requires words and definitions to be stored somewhere on the device. What is the correct/best way to store this information? I have read about ways to prepopulate Core Data but the solutions I've read seem like hacks. This seems like a basic feature needed by many apps so am I missing something here?
Core Data is the way to go here. There is nothing hacky about pre-populating a persistent store and including it in your app bundle.
Core Data seems like overkill for a flashcard app. I'd probably just save the contents to a plist. Is this content read-only, or do you need to update it at runtime?
If you need to updated it you could copy check for a plist in the documents directory at launch, and if it doesn't exist, copy it from the bundle into the documents directory. You can also use the same approach with a Core Data database, but unless you're familiar with Core Data the learning curve to learning it probably isn't worth it for something as simple as a flashcard app.
I'm developing an app that stores data in the iPhone, but I need to know if it's possible to export the data (as an entities, tables, .txt or xls) to a desktop because I need the data to be readable on my Computer OR do I need to create a web site to do it?
By the way.. I'm still not sure what method is more effective for this kind of app, Core Data or SQLite.
Core Data on the desktop and iOS are identical. You can stand up a SQLite file created on either on the other with no issues. In these situations it is highly recommended (I would say necessary) to use the same data model in both applications.