We have an app that allows users to create their own content, it includes "groups" of text and images which are then used in a game. They are written to the db, but also "restored" back to documents when they are "synced" or "backed up" to an existing or "clean" device.
A user is able to backup (.fgz) to a dropbox, which is meant to make it easy to share the game data between a number of devices. This works without any problems. The game content (db driven) and images can be shared to any number of devices without any problems.
Every time we update the App, we have a problem where the text entries are retrieved and are completely viewable (both from the local file system / sqlite) but for some reason the images in the same location will not display as they have previously (the path to the image seems to be deprecated during the update). This includes doing a "backup" to a newer version of the app, to a device which has not previously had the application installed, which is also really strange.
During testing, using Xcode and local copies (replicating "install in place", we can not replicate this problem using the exact same code, and databases. There are no errors or warnings. Is this a core data problem? Any other suggestions about what we might be doing wrong?
What is going on here? We are at our ends trying to find a solution. Is there a better way to do this? We have thought about keeping our files as part of the local file system only, but if we do this, they won't be as "shareable" via the dropbox.
Any thoughts about managing image data in iOS would be very much appreciated.
Related
Various users of our application started to complain it uses lots of memory on the phone. We added data collector based on files (that locates within application folder) and it's sizes, the following been found for small amount of users:
Preferences:{
files:{
"{bundle_identifier}.plist":"23.97479057312012",
"{bundle_identifier}.plist.0BTeiJo":"22.25380897521973",
"{bundle_identifier}.plist.1lT9kMO":0,
"{bundle_identifier}.plist.2HHwLSb":0,
"{bundle_identifier}.plist.2L9bkJR":0,
"{bundle_identifier}.plist.2xAnoy5":0,
"{bundle_identifier}.plist.3Qgyplk":0,
"{bundle_identifier}.plist.4SBpAox":"23.95059013366699",
"{bundle_identifier}.plist.4Xm8NvI":0,
"{bundle_identifier}.plist.5sPZPIi":0,
"{bundle_identifier}.plist.6GOkP57":0,
"{bundle_identifier}.plist.6SYZ1VF":"21.67253875732422",
"{bundle_identifier}.plist.6TJMV5r":"21.67211151123047",
"{bundle_identifier}.plist.6oNMJ0b":0,
"{bundle_identifier}.plist.7C1Kuvm":0,
"{bundle_identifier}.plist.7E3pmr4":0,
"{bundle_identifier}.plist.7ExLAx0":"21.70229721069336",
"{bundle_identifier}.plist.7GOPE3W":"18.70771026611328",
...
},
size:"960.2354183197021"
Can someone assist and explain, why this files (plist.*) appeared and how it's possible to safely remove them and ensure they wont appear again?
P.S. I found the logic in the project where we store dictionaries to the NSUserDefaults (I know this is a bad practice), but there is not much data.
UPDATE:
I have discovered that files (*.plist.*) are generated after Back Up. And sometimes size is 0 sometimes size same as origin *.plist size (on back up time).
Now i need to know, is it safe to remove them?
my app has been rejected due to iCloud Storage Restrictions. (2.23).
There are lots of questions for this situation, but i am still not sure why my app has been rejected.. Here are my suspects:
1- My app downloads pdf files and images for letting users see on "offline" mode when a user selects a row from a tableview. I've set my download folder as "Documents/privateDownloads" and set the folder (and files inside) url flags as "do not backup"
2- My app also has a 2Mb. "preload.json" file, which my app reads the file at first launch and preloads into the database only at first launch (with a progress hud showing the progress of importing data). I haven't set the "preload.json" file as "do not backup".I just drag dropped the file into "Supporting Files" group in Xcode.
My guess is the problem lies in the 2nd suspect, but i've also read that i should move the "privateDownloads" folder into "Application Support" Folder instead of Documents folder.
i always stored my offline files on nsurl cache for a very long time (technically forever), but this time i've decided to do like this.
thanks for reading and helping.
Edit: there is a note from app store for rejection reason:
"In particular, we found that on launch and/or content download, your
app stores 3.6MB"
When i control this issue, this is happening after my application "preloads" the data. But what i really don't get it is, i am storing this preloaded data in core data. So yes, i want this data to be backed up in iCloud?!
To solve the issue of your seed data being too large, you might split your Core Data stack in two separate stores - one which stores the user data and is backed up to iCloud. And a second one which stores the seeded data imported from your JSON. This store could then be excluded from iCloud backup via the "do not backup"-flags.
Another recommended way would be to ship a pre-populated store like described in this article on objc.io. Since you mentioned your preload.json is several MB, this would be even more desirable to pre-generate the store once than on every device on initial app startup. And you could apply the required file attributes for not backing it up more easily.
The issue won't have anything to do with your preload.json file. If that's included in your app distribution, it is part of the app and you don't need to do anything different with it.
I would suspect that the reviewer didn't notice you were setting the 'do not backup' flag on files you've added to the Documents/privateDownloads folder, or that you have a bug and the flag isn't being set at all. It is safer, if you're able, to store those kinds of files in a /Library/Caches sub directory. Then you don't need to worry about the flag.
I need a solution for a feature in an app my company is building. It is an IOS app for iPhone and iPad and we support ios5 and above only.
The end result we need is for the user to tap a button inside the settings area that dumps the apps internal database cleanly, attaches it to an email for the user to then address to whoever they wish.
Attaching to an email is not an issue. What I am concerned about is if it is reasonable to think that exporting a copy of an sqlite database to an email as an attachment would leave the user with a usable copy of the database. My customer base is not good about doing backups but the data is nevertheless very important to them.
Will a hot export of an sqlite database be usable, i.e. is this supported, or will the database be corrupt sometimes/always?
Keep in mind that all this function has to do is make it so that a usable copy of the database gets off the device and stored safely offline so that I can then walk them through restoring the database by copying it back into the device using iExplorer or PhoneView.
In the future we plan to add a robust export and import feature, but for now we are looking for a solution that we can implement in a day or less.
Thanks in advance for anybodys input and gasp some objective-c code that would dump a clean copy of an sqlite database in such a way that the database will be usable and not corrupted.
You don't need to make a hot copy of the database. When the user chooses the backup feature of your app, close the database, copy the file, and then reopen the database. You can now attach the copied file to the email.
I have a feature in my app for doing just this. I've never had an issue with a corrupt database file. As long as there are no active transactions running, the sqlite file should be OK to copy, especially if there are no open handles.
Another option would be to use the sqlite3_backup_init and related functions to copy the database.
I know there are similar questions on this subject but nothing that quite answers my query. I am aware that it is a bit of a newbie question!
I have an app on the AppStore which I will soon be looking to update. My binary contains a pre-loaded sqlite file with a list of data which the user starts off with. However, the user will extensively edit this information and it is crucial that that data is maintained through the update.
I am not changing the CoreData structure at all so won't be performing any migration but my concern is that when I upload the new binary the packaged sqlite file will overwrite the users existing data. I suspect that won't be the case but can anyone shed any light on it?
When updating an application the documents directory is untouched. Presumably your startup code checks to see if you have already copied the initial database from the bundle to the documents directory - this will work the same way after an upgrade.
You are testing this every time you run a new build on your device during development anyway - you've put a whole new version of the app bundle on there, and it doesn't kill all your data, does it? (does it???)
I have an app that downloads several pdfs and images. It all work perfectly fine, I store information of those files in core data. My problem comes when I send out updates of the app, all the information in core data is transferred to the new version correctly but the files are nowhere to be found.
I guess I can write a routine to run when users update the app and download the files all over again. I just believe there is a better way to go by preserving the files.
Has anybody experience on this?
You could store the files in the Documents dir, there they will be not deleted unless you remove the app from the device.