Usually I populate my core data with data from internet.
But say I want to prepopulate it with data without downloading it from internet.
Say I want to store all cities, or all tags first.
What would be the standard way to do so?
Should I store the cities on plist?
Should I hardcode inserting all data?
Should I set a variable in coredata to tell whether it has been initialized or not?
What do you guys do?
If it's a lot of data, the fastest way is to provide a populated store. Assuming you're using a sqlite database, you can simply use the Simulator to generate it once, and then put that in your app.
If it's a small amount of data, I'd insert the data at first start, while reading it from some form of xml, csv, or even hardcoded (script-generated) insert statements. It all depends on the situation.
When using Core Data not read-only, you should copy the database to a place where you're allowed to write, when the app starts for the first time. In a read only situation, you can just use the database from the bundle.
Related
I'm working on an app where it needs to communicate to a Web Api when it needs to save data. Where would be the best place to save it if wifi/data is not available to send the request? Was thinking NSUSerDefaults, but wasn't sure if this would be the most efficient and secure way?
Let me know your thoughts!
Thanks!
It really depends on type and amount of data you want to save. NSUserDefaults may suffice for small property lists. In case of large amount of data you can use NSFileManager to organise and save your data into files and folders. You may also consider using Core Data if your data can be organised into a database. Choose whichever suits your needs.
I want to create a large database. I am thinking of using core data for this purpose.But i want to insert the data to it manually and only once. This data is never deleted or edited but only read. How can i use core data to add such large number of objects to database? How to create database in core data and write only once.
Your question is quite general but I'll try to give you some hints on it.
Based on my experience, the simplest way to achieve it, it's to follow these two steps:
1) You could create an external file, in XML, JSON or plist format, that you can parse and use to create a prepulated a Core Data store. You can find some info in core-data-tutorial-how-to-preloadimport-existing-data-updated. In particular, you could set up a dummy project (or just use the AppDelegate methods) and use it to create the store, e.g. MyDataStore.sqlite.
2) Once you created, forget about the routines you have previously used and you ship the store in the application's bundle of your app. There the store is read-only. Otherwise, if you need to modify it, you are not allowed to do it and so you need to move it, for example, to the document directory.
You cand find additional info in the following SO topics:
Is Core Data useful for readonly data too?
How can I ship my app with a pre-populated Core Data database?
Core Data Store included in App Bundle
P.S. If you are in production and you need to make same change to your store, you need to republish the app (since the store is within the main bundle). To avoid this you need to move the store to a different directory and set up, for example, a sort of sync mechanism.
Hope that helps.
This is my first time that I am working on a big project for a client. So I was not sure how to solve this problem. However I have come up with two different ideas but I need professionals opinion about which one is better :)
Situation :
There is an application which runs on different client's iPad. Application data is stored by using giant XML file. This XML file is shared among all client by a server. So a server has a centralised copy and each client has their own copy. Once client made changes to their XML copy they updates server copy in and other client updates their copy by updated server copy.
Now only one client can make changes at one time, To fix this I have logic by which before client starts editing XML they need to get ownership from server and server will only allow one client to edit at one time.
Visual Representation :
Now on client side I have to think of a logic by which I will update my client copy and upload it to server. There are two options,
Option 1 :
In option 1, I can directly manipulate XML file by using GDataXML parser and upload that copy to server. For persistence I can save client copy on my iPad in document directory.
Option 2 :
In option 2, I can read XML file create a CoreData representation for local storage. When ever I update data inside core data it will I will change XML file too and than upload that file on server. Double work but I guess better persistence.
Now which one more robust and advisable? Personally I was planning to do option 2 because it seems more robust as I am persisting application data in core data. But option 1 seems more easy work but I don't know how good persistency will remain.
Sorry for lengthy question,
Thanks for any input given.
There are a number of factors which would influence selecting the second option over the first.
How big is the XML file? If you need to work with very large documents, you may need to incrementally parse the XML (SAX) into core data. This will allow you to access the document's contents without loading it all into memory at once.
Do you need to run complex queries in the data? If so, you may be better off using core data fetch predicates, rather than xpath or XSL.
Are you already using core data? Depending on how the XML data is structured, it might be simpler overall to import the data into your existing persistent store.
Otherwise, you can probably make due with parsing the entire document and either traversing the resulting tree or querying with xpath.
If you need to create an object graph based on what you get from server and show it to user (which you most probably need to do), you should stick up to second option, since it allows easy and robust data persistence.
If you do not need to present user with any data from the XML file you can, of course, store it in the Documents directory.
So, if this is a client application and it has at least some visual representation of the data from an XML file you should use CoreData.
If you want a regular update of data , then use CoreData
I'm pretty new to Core Data, and I'm trying to wrap my head around it.
You might have cases where you want different types of data stored in different places or with different behaviors. For example you might have one read only sqlite store shipped as part of your app containing some default data, an additional store for updates to that data set you have downloaded from a server, and a third for user data. Alternately you might have a case where you want some objects to be persisted while others can live in an in-memory store and do not need to be saved between uses of the app.
The templates for these HTML emails are all the same, but there are just different variables for say, first name, last name and such.
Would it just make sense to store the most minimal of data that I need, and load the template in and replace the variables everytime?
Another option would be to actually create the HTML file and store a reference to it, which probably would be the easiest to do except it might be a pain managing the files, and it adds complexity in regards to migrating, file permissions, et cetera.
Looking for opinions from people who've done this before...
GOAL/PURPOSE/USE:
I have a booking engine. When users make a booking, they are sent a confirmation email, generated from the sessionized booking data.
This email provides a "Cannot view this email? See it here" link which provides a web view of the email, in addition to a plaintext view.
I need to display the same email that was sent out, in addition to the plaintext view.
The template is subject to change, but I think because of that very fact I should have a table of templates and map the data to a template.
That's what I would do, because the template layout may change over the time, but the person information should remain the same. So, it makes sense to just store the person information in the database and leave the template out from the database.
In fact, it would be even better if you use template engine such as Velocity (in Java) to construct your HTML emails... very easy, by the way.
On the one hand cpu is more expensive then memory, so mostly it is better to save more data to reduce cpu power used by computation.
But in your case, I would save the minimal data, the emails or what you are tying to save, because it allows you to easily remodel your templates, and to reuse the data at multiple places of your application.
You persist redundant data (especially because of the template) which is in no way normalized. I would not suggest to do that. But mentioned in the comment it is important what you want to do with that data.
If you only save the data you need you could for example exchange that template easy and use another one.
Yea, your right on track. I did a similar thing. All dynamic/runtime variables were starting from ##symbol.
So in database you would have one Template table. One table would be for dynamic/runtime variables. One table for Mapping between Template and dynamic/runtime variables.
tblTemplate - TemplateID, TemplateValue
tblRuntimeVariables - RuntimeVariableID, VariableString, VariableSQL
tblMapping - TemplateID, RuntimeVariableID, RuntimeVariableValue
Advantage of using an extra mapping table is that on adding new dynamic variables to existing change would mean making no change to existing database. Only more rows would be added to tblMapping.
In my case I was also having one extra column for storing SQL Statements in tblRuntimeVariables in case the value for a runtime variable is fetched from database.