can somebody please help! I'm creating audio files using Xcode and placing those files in the 'documents' directory of my app, the point being that I can retreive them using iTunes and File Sharing.
I save the audio files as type .caf, I've created a directory list to make sure that all my files are actually there, they are. I NSLog the directory that the files are being stored to, it's the application documents folder. I have 'UIFileSharingEnabled/Application Supports iTunes Sharing' as TRUE in the info.plist. Everything seems to be working fine, EXCEPT... I just can't see the files in iTunes File Sharing. I KNOW they're there... I can even email them successfully from the same directory, but they don't show in iTunes.
Please can somebody help!
Thanks a lot!!!!
What you're saying doesn't really makes sense.
If you've done all the things you've mentioned properly, you should have had access to the application directory through iTunes.
Nevertheless, considering some problem still happens, you can do the following:
If you have SSH access to your phone (for jailbreak iPhone), you can use SSH to list the files on the documents directory.
If you don't have SSH, you have to solve the problem internally - through your application.
I recommend: List iPhone application document files
Related
In my Mac app I have an NSMetadataQuery to watch the app's iCloud directory. When the user decides to enable iCloud from within the app I do the following in this order:
Call [[NSFileManager defaultManager] URLForUbiquityContainerIdentifier:nil] to establish access to the iCloud container
Start a NSMetadataQuery to find all files (pattern: "*") in the iCloud container
Now I iterate over all files in the local container and move them to iCloud by using [fileManager setUbiquitous:YES itemAtURL:fileURL destinationURL:targetURL error:&error]
I have two types of documents that I move to iCloud:
The actual documents stored as file packages
For each document I have a .preview file as simple binary file
My problem is that the meta data query only returns my binary preview files, but not my actual documents until I relaunch my app (or open a Finder window of the app's iCloud folder from the Terminal - in this case my app gets another query result with all files).
So is this some weird caching issue? Is this because the documents are file packages and not simple binary files?
I don't see why that should be a problem. If I restart my app the query does return all files correctly.
Could this be a problem with the way my custom document type is exported in Info.plist?
Could this be a problem with the way my custom document type is
exported in Info.plist?
I suppose so: the issue you are describing is most likely because your document format is a file package (I assume written with NSFileWrapper). Remember that the package bit is set when writing the file, so if you have other apps writing to iCloud, that could make the issue much more confusing as it's not about interpreting a file bundle but writing it in a correct manner.
NSMetadataQuery unfortunately ignores folders, so your files will never be reported back unless you have correctly registered your filetype as bundle in the application that writes the file to the iCloud container.
There are a lot of similar and potentially confusing settings in the info.plist, so many things that can go wrong. I experienced an issue when I registered my document filetype correctly on OS X, but failed to do so on iOS: https://stackoverflow.com/a/14993694/388412
The first thing you should do is to go to https://developer.icloud.com/#documents and see if you're looking at files (correct) or folders (problem).
Work on your info.plist document types until you see the documents as files, then it should work.
I came across this information in the posting of a question I found on here:
"Apple has added an extra rule for apps being submitted to the app store.
We can no longer store arbitrary data files in the Documents folder. Only content generated by the user like a text file they manually typed and saved or a photo they took with the camera can be saved in the Documents folder.
We are now expected to store our app generated files in the Library/Cache folder instead of the Documents folder. In addition, we should mark the files we don't want to be sync to iCloud with the skip backup attribute.
Failure to comply with this will result in an app being rejected by Apple.
Reason: The Documents folder is now used for syncing to iCloud. iCloud does a sync every few minutes and if we were to have megabytes of our app generated files stored in the Documents folder, it would get mixed up with the user's own iCloud synced files."
This makes me wonder if the way I have used NSUserDefaults in my app is "legal" in the eyes of apple.
I'm making a simple app that takes user input in about five different places. I'm saving these simple strings in NSUserDefault variables.
My question to anyone that fully understands the statements made within the quotes above is:
Am I saving data in a way that is no longer allowed by apple?
I'm new to the development game, and the information within quotes doesn't make it clear to me (in the context of my app's situation) whether I'm in the wrong or not.
Thanks for the help!
NSUserDefault is the official, supported way of storing user preferences. If that's what you're storing, then it's the correct way to do it.
I am wondering how an application like appzapper can detect the files related to an application?
All ideas are welcome.
Thanks for your help,
Regards,
By looking into the standard locations that usually are used by applications to store preferences (like Library/Preferences/ , Library/Caches, etc., both in your home directory ~/ and under / ) I couldn´t find any file or folder that isn´t using either the applications name (eg. ~/Library/Application Support/Firefox) or it´s bundle identifier (eg. ~/Library/Preferences/org.mozilla.firefox.plist) in its name; so I guess they´re just using that.
In the case of AppZapper you can go ahead and try for any (not currently running) Application to rename the ~/Library/Application Support/AppName folder for example to ~/Library/Application Support/111AppName - AppZapper doesn´t find it anymore. If you change it to ~/Library/Application Support/AppName111 it shows up as a related file.
Out of this you can conclude that there isn´t any magical linkage between a folder full of preferences and it´s associated application that AppZapper is reading out, it´s merely checking for folders starting with the Application´s Name.
I install an app .app file to /Applications folder.
Can you please tell me where does the user specified data being stored? How can I do to clean uninstall my application and its user specific data?
Thank you.
This depends on the application, unfortunately. Sometimes it is in ~/Library/ folder, though.
AppTrap should do the trick.
It runs in the background and simply has a preference pane in the System Preferences. Drop the application onto the trash folder and it will ask you whether you want the associated application files to be deleted too.
Just let the user do that. For instance with AppCleaner.
Otherwise, just give a way in your preferences to reset them. No need to delete the plist file.
AppDelete is a free program for uninstalling and cleaning up.
FSEventer is a free program for seeing where programs install themselves.
Most information is stored within /Library/, however from time to time you may find applications which store their data within the contents of the .app package itself, or within a subfolder in /Applications/.
This should give you an idea of where to look.
Where to Put Application Files
I have a Firefox extension need to write to one files inside the extension's chrome folder, it works fine on windows and linux, but it give me 0x800520015 NS_ERROR_FILE_ACCESS_DENIED error. it is very strange, I manually set the file to have write permission, it works fine then.
My question is where should I set something to tell MAC OS to give write permission to that file.
Thanks.
Which "chrome" folder (post the path)? If you're talking about application's chrome folder, it's a bad idea to write there; newer Windows will not let you do that either.
[edit] so if it's in the extension, you may have the wrong permissions set in your XPI file accidentally. You can change the permissions from your extension (see nsIFile.permissions) or create a proper ZIP while packaging. (Can you post the ZIP file to verify?)
Anyway, why do you want to write to extension's folder? It's usually a bad idea.