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?
Related
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.
My app have too much dynamic app resources like images, html+css and xml or json files..that can be updated, So I cannot put these resources in app bundle it will not get updated once on app store i need to have it updated there...secondly i also cannot put these resources on server where I can request the content from server every time i need it...
So my question is that is good to store data locally in document directory??? how does apple app review team will react to it? I have heard that there is an iCloud problem while putting data in document directory is it right?
So where to store data of iOS application locally on device?
Thanks in Advance.... Looking for some good solid answer!
This kind of data should be copied to ~/Library/Application Support. See the File System Programming Guide for full details on where everything goes and how it will be treated.
You may want to consider having the initial assets you are referring to be resident in your application bundle. And then when you have updated versions, save them in your Documents directory (or any legal path you want).
The reason for this is for failover, in case there is a problem, it allows you to revert back. When you are dynamically loading content, you have to factor in you can encounter various problems during a download such as corrupt data or even a dependency not being downloaded yet.
FWIW, I implemented this for a game that supported dynamic loading of content. The bundle had the original assets. There was a temp download directory. When data was validated, it was moved to a locale where it was consumable. On app start, the first step was to just copy the data from the bundle to the consumable directory. While it seems perhaps wasteful and several steps, it worked surprising well and most would not even know this sort of thing was happening.
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.
I have a simple app that downloads some data from a webservice and displays it in tableviews. In order to allow offline access, the app caches this data in the cache directory on the device itself. I keep a list of all of the cached files for reference, and save that to the cache directory as well. So after all of the downloads are complete I have the following files:
XMLFileList
XML1
XML2
...
I launched this app a couple weeks ago, and have since had to release a few minor updates as necessary to fix some minor bugs. It seems, however, that when a user updates the app on their device, they no longer see the downloaded resources. I have managed to get this to happen on a development device, by updating through the app store, then loading a debug build, and determined the following problem
It would seem that it is not displaying the data in the downloaded files because they no longer exist. It is also not re-downloading the files because they show up in the saved list. This provides a rather interesting question: why did the cached XML files get deleted, but not the master list?
What exactly is going on behind the scenes during an app update that I could account for, or reproduce to ensure this does not continue happening?
If you're putting files into /Library/Caches (or whatever it is), then there is no guarantee that those files will be there the next time you run your app. Anything you put into /Documents, however, will be there. And in fact, anything in /Documents will also be backed up to iCloud (unless you set the bit newly available in iOS 5.0.1 that lets you opt-out files in /Documents from being backed up.)
Anyway, the point is that you should read Apple's docs on what files you should put where. (I searched around for the correct reference unsuccessfully; I've seen it before though.) It boils down to this: Anything that is user generated should go in /Documents, anything that can be re-fetched from a server should go in /Library/Caches and may be purged by the OS.
Cache directory contents are not guaranteed to be preserved. But I don't see any documented guarantee that the entire directory will be cleared all at once. (Maybe only the biggest and/or oldest contents or some such?)
I need to store some data files for my blackberry app. These are usually small png files that I download and store locally for performance reasons. Also I need to store an xml file locally.
My question is where are these files supposed to be saved on a blackberry? Is there such a thing as an application's home folder or settings folder in the blackberry filesystem?
What would be the path to such a folder?
This is for blackberry os 4.7 or later.
Thanks!
If it's not a huge amount of data (and by the sounds of it, it's not), take a look at the PersistentStore mechanism. You can store many types of data including native types (String, Integer, etc.) and even byte[] data (for images) using PersistentContent. The nice thing about PersistentStore is that it doesn't require any sort of filesystem access -- it doesn't leave files hanging around -- and if you include a custom class in the persistent store for your app (even a simple subclass of an existing persistible class such as Hashtable), it will automatically delete your persisted data if the app is deleted.
There's no official home folder for your application. In blackberry you can basically read/write just about anything/anywhere (well, you might get a SecurityException/IOException if you'll try do change some files).
You can write to the SDCard/Internal memory using the paths described here.
If you're worried about someone seeing and altering your data there's not much you can do except setting your files and directories as hidden using FileConnection.setHidden(true) but this is very lame since they can still be seen even from the native BlackBerry file browser if the user chooses to show hidden files from the menu.
Edit: You could of course encrypt/decrypt your data but this won't prevent someone from deleting it.