I wrote a game that I plan on updating soon. The game generates a scoreboard when the application starts, if there is no scoreboard file present.
If people update to my latest version, will the scoreboard file (that's generated by the code itself, not a file that comes preloaded in the app) be deleted?
If so, is there any way to avoid this without any coding previously required?
The updated version of your app will simply replace the existing version's bundle - any files you've written to your app's document area will remain intact.
As such, you simply need to check for the presence of the file within your app's document area as per usual and write a "new" version if none exists.
If the file is within your applications bundle, it will be deleted. Files saved with Core Data and NSUserDefaults will not. I've never personally written a file to the disk, so I don't know where the default write point is. You'll have to find this out yourself.
Happy coding,
Zane
Related
I have an app in appstore now im going to push out an update of app, Im having a custom Plist file with set of values in my application bundle, and these values are been modified from the version which is in production and in addition even more key value pairs are added in to this file.
Now my doubt is on updating this app to appStore will the update process automatically overrides(updates) my new plist file on top of existing one or do we need to do some work around like how we do for database changes like coredata migration and all?
As explained here: iOS App Programming Guide, this is what happens when you update an app:
Files Saved During App Updates
When a user downloads an app update,
iTunes installs the update in a new app directory. It then moves the
user’s data files from the old installation over to the new app
directory before deleting the old installation. Files in the following
directories are guaranteed to be preserved during the update process:
Application_Home/Documents
Application_Home/Library
Although files
in other user directories may also be moved over, you should not rely
on them being present after an update.
This means that all the resources that were in your bundle will be "lost" and you will have the new ones from your new bundle. If you were using this plist file for read only purposes this won't be a problem, if you were saving some user preference on this file, i'm afraid that these user information will be lost. You should save this kind of data in the documents directory, always!
When the update is deployed it will overwrite existing plist files.
When you update your app on App store it replaces new binary with old binary. So with binary it also replaces your plist too. So don't worry about that, just be aware that your info in app store details and details in plist should be same otherwise it will not take your binary file for app version update.
The Xcode templates for the creation of core data apps start a new blank sqlite file when the app is started the first time. But suppose I have a database already created that I need to include in the bundle, so, when the app starts the first time it already starts with a populated database.
How should I proceed. Ok, I know that I cannot write the database in the bundle, so I have to copy it to the document's directory. I see this is where the sqlite database created by the app itself is already on. So, that's it? I just overwrite the original file with the one in the bundle at the end of my RootViewController's viewDidLoad method?
If this is the way to go, then I need to build a control method that does that just the first time, right?
It must be a simpler way...
Any ideas?
thanks
You're on the right track with copying the .sqlite file from the application bundle to the documents directory. I used the approach outlined very thoroughly in this blog post by Jeff LaMarche. It deals specifically with providing staring data to an iPhone application, and it worked like a charm in my app.
I have an .xml file that is going to be shipped within my app.
This file contains values that are read from it and saved as an array when the app launches.
Each time the app is run, I want to check with the server if there is an internet connection. If so, I want to get the newest version of the .xml file from the server and replace the one that I currently have saved in my app (this way, the next time the user logs in and doesn't have internet access, he/she will be able to use the old (yet most up to date) data).
What is the best way to do this?
Thanks,
The best way to probably do this is to copy the XML file from the app bundle to a location in the app's sandbox, e.g. the Documents folder. Thereafter you can update the XML content as necessary with newer data from the server. The copy is necessary to allow you to write to the file, since you cannot change the content of your app's bundle because it is signed.
Alternatively, if the data is simple enough, you can just save it to user defaults on first launch and change the defaults on subsequent updates
I might skip the XML altogether, unless it contains a baseline of default settings, and just sync user defaults over the Internet. You can't modify files in the bundle, so your only option would be to copy over a "default-settings" XML file to the application's Documents folder to make it editable.
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.
I'm trying create 2 apps, one that builds a persistent store, and another one that consumes it.
So far I have built one app that uses CoreData to successfully build a database from an XML file. So this project contains the data model, the .h/.m files for the entities, etc.
I'm now trying to enable the second app to read that .sqlite file by copying the data model file, the .h/.m files related to the entities and the sqlite file to that project (via add existing).
The code executes but always fails to find any objects in the database.
Are there any restrictions or correct steps to take when trying to copy over these files?
The solution here is deceptively simple.
Just copy your .xcdatamodel file from one project to another and then when you run your app in the simulator for the first time it'll create a Documents folder for the app. Just drop your saved .sqlite or .binary files into the yourApp/Documents directory on the device.
You can find the simulator directory in "~user/Library/Application Support/iPhone Simulator".
You can also download, edit, and upload the myApp directory on a provisioned iPhone by dragging and dropping into and out of the Organizer. Look at the Applications list.
The iPhone doesn't support xml stores with core data, only sqlite or atomic (binary). The sqlite store is by far the better option for most applications since it doesn't all have to be loaded into memory at runtime.
Is this what you meant?
I think (not 100 percent sure) in your app plist, if you set your application bundle name to the same thing, they will share resources because the device will think they are the same application...
I don't think this is going to work the way that you want it to. On the iPhone, each application runs in its own "sandbox", and it's not really possible for one application to write files that another can read.
Is it really two different projects, or is it two targets in the same project? That would seem to make a lot more sense, and then you can share entity objects as they change.
For copying core data files from one project to another, I first created a new project with core data support and then I opened the contents of the previous coredata file and except the root tag, pasted all child tags in the new core data file in new project.
Previousy I tried to delete the coredata file in new project, copy pasted the previous one and changed its name and it was not working.