I had a problem in my simulator - when I want to edit the table in core data or create a new table the program which was using the database fails every time I start it. So I google the problem and I found the solution - every time I want to change something in my tables I have to manually delete my database. So it works fine but nowadays I get the license for testing it on real device, but I do not know how will it works on real device. I work for company and maybe the database will be expanding with some new tables, and I really do not know how to prevent it in real device. I admit it is a strange problem, but can you help me?
If your change your Core Data model during testing, you can easily delete your app from the simulator/device. In this case Xcode will install a new database on your simulator/device when you re-install the app and your app won't crash.
If the app has already been released in iTunes and you want to change the database, you have to implement data migration in your app.
Hope I understood your question right. Please ask if you have any more questions.
Related
i am experiencing a weird problem. last week i submitted updated app into App store and when it comes live i updated already installed app on my iPhone. i saw lots of issues on my home controller table view. after that i deleted and reinstall the app and it worked fine.
i found same behavior on some other test devices too.
i find it as a big issue because end user will never do reinstallation, he will always update the all and find these issues.
Any help will be highly appreciated.
This problem could be caused by incompatible models between those two versions. For example if you are caching your model objects it would be good practice to clear cache upon upgrade to avoid that problem.
Your application crashed due to update in core data model. Solution for this is you need to learn data migration of coredata. you can learn form here.
Hope you will get what i mean.
I have an xcode project that has 4 targets (2 apps, 1 iPhone and 1 iPad version for each). I have recently implemented Core Data Lightweight Migration.
I am currently only testing two of the apps, the iPhone versions, call them App A and App B. I am able to run the current app store version of App A on my iPhone, then install my new version of App A to test the Lightweight Migration. It works fine, no problem.
Then, I try the same thing with App B. I am able to install the current app store version of App B on my iPhone no problem. BUT, when I try in install the new version of app B on my iPhone, I get the following error (or a variant of it) EVERY time: "putpkt: write failed, broken pipe"
I am confused since the two current versions are in the same project and have the exact same settings for every configuration (debug, release, distribution). The is not ad-hoc distribution.
Every post I have read for this error on this forum, and anywhere, suggests things like removing the app, restarting the device, restarting xcode, etc. And sure, I can get it to work that way. BUT I cannot test my migration that way.. If I remove the old version of the app from the device nothing is getting migrated!
I am pulling my hair out over this. The two apps were originally in two different projects, and I added App B to the App A project as a new target - that is the only thing I can think of, as I feel like I have looked at everything. I would really appreciate some help to figure out this problem. I feel sick about sending out a database update that I cannot test - I can't take the chance of corrupting people's data, especially when I have not offered a backup option until this current version. Ugh.
EDIT: when I try to run App B on the device without updating, I often get the following error:
Error Starting Executable... Don't know how to run. Try "help target".
EDIT: I think I am having this trouble because I renamed the product name for app B. I think this changed the bundle and will not allow me to migrate data. I will try to change it back and post an update. It seems like merge bundles IS working well for app A in the meantime.
Making sure the new project and the original project had the same product name and the same data model name fixed this problem for me.
First i would apologize for the question as there are answers out there but as this is my first project i do not really understand the explanations how to do this.
I have an application that uses Core Data, which works on the simulator but not when i generate it on my device. The app starts but it seems like the Core Data is empty. I guess i need to move the DB into the device.
Would someone nice be able to, in a simple way, explain how I fix this?
PROBLEM SOLVED
I downloaded "iPhone Explorer" (http://www.macroplant.com/iphoneexplorer/) and manually removed the two instances of the DB on the actual device and re-run the app and all finally worked.
If you populate the sqlite generated by Core Data (found in the simulator folder) and want to add to the main bundle of your project to load on application startup, then please see the instructions on the following website:
http://iphonedevelopment.blogspot.com/2010/08/core-data-starting-data.html
This basically checks for the pre-populated DB. If not found, it creates one as normally done when on first launch of a application which uses Core Data.
I created an app for iOS 3.2 for the first version 1.0.
Recently I created an updated app for iOS 4.2 with print feature etc. for the second version.
My problem is that, the users are not able to update the app from appstore.
They are facing issues like data loss of version 1.0 app, crashing etc.
Can someone explain me what can be the reason for this?
And, how can I test this thing on my device, as I am not having the version 1.0 app from appstore, but the code for both versions.
Delete your new one on your test device and install the old one. Then build and debug the new one line by line. I had lots of trouble my first time through due to confusion over the update/migration process of core data. If you use core data, chances are your existing customers have an out of date store DB that your new code is crashing on. The store doesn't get wiped in an update if it's in your user's document directory... Only the one in the app bundle. You'll need to handle that reset or tell core data to migrate it to the new model. Of course, all this is speculation since you've given almost no details about the problem, frameworks used, log files, etc.
During a normal install process, data should not be overwritten. NSUserDefaults and files should remain during an upgrade, as long as the user doesn't delete the app first. I assume the crashing occurs after the new version is installed?
Basically when I have an application in XCode and I change the sqlite/coredata database and try to run it on a device that already has the application on it then the app crashes. I have to remove the app and reinstall it.
I have updated the database on an app that has already been submitted to the app store. There has been about 100 downloads, and now I want to submit the update. Will people who have already downloaded it have problems with it? How would I make sure that they don't? There won't be any data in the old database that I will need to be honest, but I'm worried that the app just won't start at all.
Thanks
Tom
From your description I can tell that you've changed the Managed Object Model withtout changing the store version.
Check out this tutorial (may be Mac version, but it should be valid) here.
However, if you with to omit the migration (since you said users won't exactly have any data in the store) you can always change the store path so that it loads another store. However, if you plan any updates and further developement of the app then i strongly recomend to read about core data migration.
Yes the app will probably crash when running with old db.
Apple released an interesting documentation about Core Data versioning and migration called: Core Data Model Versioning and Data Migration Programming Guide
If you read this document, you will learn how to avoid the crashes with updated coredata databases.