Is it possible to hide the Inbox from the list displayed of the directories?
For example, in this screenshot from a tutorial, the inbox folder features. In my app I would prefer it not to.
Other apps (eg. Molecules) seem to manage this, so I assume it is possible.
(In case anyone is wondering I am a novice developer)
I very much appreciate any help.
So it turns out that although the Inbox directory is not writeable, it is deletable. Files opened through other apps will be automatically placed in this file, and if the inbox does not exist then it is created. So to get rid of it, simply delete it every time you handle an external file opening.
Very simple, just got thrown when I tried to edit a file in the inbox, which raised an exception, making me think the inbox was write-protected.
Related
Using IMAP, how can I figure out if a mailbox has been moved or deleted by another client?
The LIST command simply does not list a deleted mailbox any more.
Exactly. You have to remember what folders you know about. Next time you do a LIST, any that are missing have been deleted.
Additionally, you should be tracking every folder's UIDVALIDITY value. If it changes, that folder is not the same one you know about. It may have been renumbered, deleted and recreated, or deleted and replaced by a renamed folder.
In either case, you should dump any cached information you know about that folder.
There is not, in general, any way to track folders that have been renamed by another client. You can only detect that a folder is missing and there is a folder with a new name. IMAP simply does not provide enough information to correlate them. Tracking messages and folders across moves does not appear to have been a design goal of IMAP.
In order to be able to access iCloud Drive from the application,
I think that we want to use UIDocumentPickerViewController from the application.
but i found following problems when i use UIDocumentPickerViewController.
Cannot upload multiple files at once.
Cannot Download multiple files at once.
When pushViewController from navigationController then display
become strange.
I want to avoid above problems, So is there any another way to get files information from iCloudDrive without using UIDocumentPickerViewController?
like Send some request or query.
I have searched lot and didn't find any query or request to get Files ,Upload files and download files from iCloudDrive.
if you have any idea about this please tell me.
Thanks,
I don't think there's any straightforward alternative, but you could think of...
...using iCloud directly (not iCloud Drive), but then users will only have access to their files from your application
...using Google Drive's sharing extension which supports uploading multiple files at once (the Dropbox SDK probably supports that, too, but their sharing extension doesn't)
...zipping all files before uploading them
...changing the file format so that it's a bundle of multiple files, if you are in control of the file format
...file a radar/feature request, and possibly wait forever ;)
Not sure if that helps, but I don't think you have much of a choice here.
I'm developing a MVC5 web app, hosted through azure, that lets you manage your movies (it's just for myself at the moment). I'm trying to find a way to scan a local folder on the users pc for a list of file names. I do realise the security/permissions issues I might run into. I do not need the file uploaded, only the full file name.
It would work by the user being able to select a folder where they store their movies and it will take in all the file names, including the ones in any sub directories.
I tried a multiple file upload form but quickly ran into issues with the max request limit which I tried messing around with but it proved redundant in the end. I can settle for the user selecting multiple files but would rather it done the directory way.
I know this might prove impossible in the end but any help would be greatly appreciated.
I hope someone enlightens me with this:
After saving a trace file (example: filename.trace) and send it via email, how come the recipient couldn't open the file?
So, I decided to compress the trace file (example: filename.trace.zip) and send it again via email, the recipient was finally able to open the file, but he can only see the Trace template I used, NO DATA FOUND (no spiky stuff). (Same thing happens with putting the trace file in dropbox and send the link.)
Btw, I'm using Core Animation Trace Template (that might have something to do with it).
Some suggestions (I have no experience with this particular file):
did you properly close the file? its possible what you are sending is a file that is not itself complete
in the past, I set some flag in the app plist that let me share files with iTunes. You could try to copy the file to the shared location (Documents folder? not sure now) at the same time you email the file (and maybe email the new file not the original), and see if the one you grab from iTunes opens, and is different from the one that gets emailed
In the end, you need to determine if what you have on the file system is byte for byte what ends up getting received in email, and if the copied file from iTunes opens. Once you find this out, if the problem is not obvious, then update your question. Good luck.
In my app I want users to be able to associate a file(s) they have on their desktop/DropBox with a specific item, but I don't want/need them to be able to actually attach the file...I just want to get the file name and location and save that in my database. Then when I display the item I'll hyperlink to the location captured. Can someone point me to an example(s) of how to accomplish this? I looked at the JQuery File Upload (http://blueimp.github.com/jQuery-File-Upload/) but as I mentioned don't actually need to upload the file...so this should be something super easy.
Thanks for your time and assistance.
You can try and get value of file input, but you'll fail.
See this jsfiddle.
All I'm getting is the fake path
C:\fakepath\134.png
And there's certainly no C:\ drive on Mac OSX. :)
I guess, this is because of security restrictions. You shouldn't know (or care) about user's filesystem in a web app.