Data entered by user & app update - iphone

My app sends postcards via email. I have to do sent and drafts functionality. When users send postracd it's saved to "sent". All data will be stored via plist files.
How can I make my data (saved plist file) don't be deleted when app will be updated?

Have you considered using Core Data instead of simply storing it as a plist file? If so, there's something called Core Data Model Versioning and Data Migration, maybe you can read up on that? Here's the URL to that:
http://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/CoreDataVersioning/Articles/vmLightweight.html%23//apple_ref/doc/uid/TP40008426-SW1

Correct answer is here:
http://developer.apple.com/library/ios/#documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/RuntimeEnvironment/RuntimeEnvironment.html#//apple_ref/doc/uid/TP40007072-CH2-SW7
Content of Documents and Library directories will be copied to the updated app place.

Related

Restkit seed core-data with objects from a local file on launch

I'm working on an app, in which I need to seed core-data with some local data stored in a file and I'm using Restkit.
Right now, I have stored the data in JSON format in a text file, and on launch I use the "RKManagedObjectImporter" to map the JSON to objects. Since the data is huge, it takes a lot of time (at least 30 seconds) just to map the data from JSON to Core-data objects.
I obviously cannot make the user wait 30 seconds on the first launch, and the data is required as soon as the app launches. So what alternative do I have here ? Is there a way to create mapped objects and store them in a file ?
Any help will be appreciated!
You can create a Core Data .sqlite file and distribute it with the app instead of a JSON file. Then, when the app launches you can check if the user has an existing store file and, if not, copy the default file from the bundle into the desired location.
RestKit also offers importing support using a .sqlite source file, see here.

Import/Export data in CSV format, stored in Core data via email

I am working on an app which is extensively based on Core data. I got several entities and relationships. The format is kinda like this -
There is an entity "CARDS" which has one to many relationship with "RECIPIENTS" (another entity) and "CUSTOMERS" (another entity). The recipients and customers can be added/modified/deleted by the user. The list is stored in a table view.
I want to do an export of that data (recipient, customers etc.) via email. But all that is stored in Core data right? So Do I have to store that in documents directory somewhere or get the path to where it is stored in core data?
I followed these links but they don't use core data as such to store the data, will the logic be the same as shown in the link below: -
http://www.raywenderlich.com/1948/itunes-tutorial-for-ios-how-to-integrate-itunes-file-sharing-with-your-ios-app
http://www.raywenderlich.com/1980/email-tutorial-for-ios-how-to-import-and-export-app-data-via-email-in-your-ios-app
Any help will be really appreciated.
Thank you
You specify the path to the .sqlite file when you create the store. You can copy that file (using NSFileManager) to another location and rename it (to change the extension to some custom value that is specific to your app). Once you have moved it, if you moved it to the correct folder it will automatically be available to iTunes sharing. Or, you can get the data for the file (using dataWithContentsOfFile:) and then add that as an attachment to an e-mail (again, specify a file extension for the attachment that is specific to your app).
You then want to look at teaching your app to handle that file extension to allow importing (see this).

how can I save the whole plist data coming from server (without formatting) to another plist

[NSPropertyListSerialization propertyListFromData:self.responseData
mutabilityOption:NSPropertyListMutableContainersAndLeaves
format:&format
errorDescription:&errorDesc];
When the server is online, it sends the responseData. Now I want to save this data(obtained through the responseData in the code) directly to another plist in my app, so that I can retrieve the data later(when the server is offline) in the same format(without changing) and use it/pass it in the same way as it is being passed when my server is online. I am doing this so that the user of the app does not come to know whether the server is online/offline and still is able to give updates/feedback to the responseData (as he/she would give when the server is online). I don't want to break the responseData and save it, rather directly save it the way it is coming from the server.
Please let me know if more explanation is required.And thanks for all the answers that you would be giving :)
If you don't want to change anything I believe you should just download the plist as a file and not as data.
To save the file on the phone you should use NSFileManager, you can read about it here:NSFileManager reference + File System Programming Guide
You must pay attention to the place you save the plist according to apple "new" rules of data storage, you can read about it here:
Were you should save your files
Good luck

Prefilling Core Data for a read-only application

i am working on an application that displays read-only data i am shipping.
it is more of a book.
It is easy with SQLite but i am not satisfied with the performance and trying to use Core Data.
The issue is with pre-filling Core Data is that it is a hard process.
My question is:
Is it possible to build an assistant iphone application (for me to use) which uses the same data model for pre-filling.
and then take the populated .xcdatamodel file and use it in my original application?
I hope this makes sense :)
Adham
I believe what you're asking is whether you can create a CoreData database upfront and copy it to the iPhone. Is that correct?
This article will help. Here's a quote:
I thus suggest the following five-step process:
Create your data in a comma-separated file, typically placing each row of data (an entity) in a row of the file and separating different columns (its attributes) by commas.
Write a standalone program and copy in your .xcdatamodel file from your main project.
Write code in your new program that parses your comma-separated file and inserts the information into a Core Data persistent store that should be identical to the persistent store in your main project.
Run the program in the Simulator
Copy your data from the Simulator's documents directory into your actual project's bundle.
It's possible, I've done it. I made a desktop application to read from a CSV file using the code here:
http://www.mac-developer-network.com/columns/coredata/may2009/
I just had to alter the way the CSV part worked, and change the model.
I copied and pasted my model from the model builder into the iPhone model. (Clicked on the "grid" area, selected all, copied)
Then I took the sqlite database the desktop app produced (found it in Application Support, in the folder for this application) and put it into the resources folder
I made some code to copy the sqlite into the documents folder on the iPhone (if it wasn't already there) at startup, in the applicationDidLaunch method. It's possible that having it in the resources folder is no good. Even though you're using the database as read only, Core Data may want to write something to it. Not sure about this though..
I used the sqlite file in the documents folder in my Core Data set up.
The desktop and iPhone Core Data sqlite file seem to be exactly the same format. You can transfer one sqlite file to another application (iPhone to iPhone too) as long as they have the same data model. In another application, I used NSXMLParser to create the Core Data sqlite file, then transferred it to another app, both on iPhone using the Simulator.
Yeah, your data source can be whatever you want it to be. The other suggestions are good ones. Create a managed object model (.xcdatamodel) identical to what you want to use in your app. Read in the data from your file, create a new instance of your managed object and populate it from the file. Then save, and dive into the bundle in the iPhone Simulator and copy it over. This has the added bonus of being in exactly the format you need, with all the helpful metadata. Copy your object model and your managed object classes and you're good to go.
Note, though, if you really intend for it to be read-only, and you're using it at install, it will be installed in your finished app's bundle (under Applications/{SIGNATURE}/Myapp.app). If you intend to edit this database or allow a user to save to it, it's a better idea to copy it to the Applications/{SIGNATURE}/Documents directory where your user database lives.

Provide Base Data for Core Data Application?

I'm working on a Core Data app (for iPhone 3.0, though I don't think that really makes a difference here) and it will need to ship with a "starter" database filled with data. With SQLite, I would just have the App copy the populated database from the bundle into the App's documents directory on first launch and then load that database - all the information would come along with it and we'd be ready to go. But with Core Data, I'm not really sure if I can just save the Persistent store to the App bundle and copy it before having Core Data start doing its thing. Will this cause any problems? There is quite a bit of initial data, so I don't want to package it in another format and have to parse through it.
Yes, you can copy over a pre-populated persistent store.
I created a Mac app that populates a store. It is copied into my bundle and at start, copied to the Docs directory. This works fine. I am told the Core Data Books example was developed the same way.
Please note this doesn't mean you can just copy over any old SQLite file. It has to be a Core Data persistent store, though I think you understand that based on your question.
Actually there is a trick: you must name the file you are going to copy over with an extension other than ".sqlite", ".bin" will do. Otherwise Xcode will change the contents of the file when it copies it into the app during the build phase and it won't load.