I want to know is there are any way to doing this (talking about iOS): Choose video from Video gallery, store its 'URI'. And then access this video using this URI directly?
For example, on Android I can pick video, remember its filename, and with file system load it using this filename.
I don't want to store it is in my application cache folder or something else, that will duplicate data on device.
Is there is a way to do such thing on iOS?
Take a look at all of the "Bookmark" methods of NSURL
They give you the ability to find the underlying file, even if it's moved around when your app is closed.
From the docs:
A bookmark provides a persistent reference to a file-system resource. When you resolve a bookmark, you obtain a URL to the resource’s current location. A bookmark’s association with a file-system resource (typically a file or folder) usually continues to work if the user moves or renames the resource, or if the user relaunches your app or restarts the system.
Related
Our iOS application allows users to select an email attachment document and upload it, through our application, to a remote database on a cloud server. We have been doing this successfully using "open in..", which allows us to identify the current fileURL of the document. Using the fileURL, we can both display the document in our application for immediate use, as well as upload it in the background to the remote data base. All good and very fast from a user perspective.
However, on iPad in split-screen mode, we would now also like to allow drag-and-drop, where the user drags the attachment from their email program and drops it on our application. Item Providers are used for this purpose, along with the UIDropInteractionDelegate methods. Unfortunately, these methods seem to want to either copy or move the document, rather than provide us with the existing fileURL. Moving or copying and then uploading the document into our application are both slow and expensive in CPU processing and thus degrade the user experience. We don't want to do anything with the file on the device. All we want is to get the existing fileURL. We will take it from there!
Question: How can we find the existing fileURL of a "dropped" document, using the Item Provider and the UIDropInteractionDelegate methods?
TL, DR:
I want to create a new asset in the photo library and apply adjustment data (edits) to it, without the user being prompted twice.
The Background
I am developing an iOS photo editing extension, and providing similar functionality in the container app.
For better code reuse and modularity, I am adopting a PHContentEditingController-based flow on both the extension (required) and the container app, bundling all the shared components in an embedded framework that both the app and the extension link against (as recommended by Apple).
Unlike the app extension, which is "passed" an image to edit by the Photos app and executes under its supervision, the container app needs to request changes to the asset library, each resulting in the user being prompted for authorization.
On launch, the app offers the user two options for sourcing the image to edit:
Opening an existing photo from the library, or
Taking a new photo using the camera.
(both options rely on UIImagePickerController, of course)
Right now, the images read from the library undergo the same editing flow as they would within the app extension, with the only difference that my own UI code manually calls finishContentEditing(completionHandler:) on the (shared) object that adopts the PHContentEditingController protocol, and, on completion, it further calls the PHAssetLibrary method performChanges(_:completionHandler) (which triggers the authorization prompt).
This means that edits made within the container app can be reverted when re-editing the same image with the extension in the Photos app (and potentially vice-versa, too, once I get around supporting adjustment data).
For new images taken with the camera, however, I am taking a different approach. After applying the filters, I just save the result to the photo library using the legacy function:
UIImageWriteToSavedPhotosAlbum(_:_:_:_:)
(back from the time when argument labels weren't a thing yet :-)
The Problem
The problem with this approach is that edits are always 'baked in' for images taken with the camera and edited within the app (the can't be reverted). This feels arbitrary and perhaps even confusing to the user, so I'm looking for a more unified approach.
I could save the photo to the library right after the user takes it, and from there use the same flow as with existing assets, but this means that I need to modiufy the library twice:
Create a new asset
Save edits to the new asset
...which will result in the user being asked for permission twice: Once before editing the image, and once again on committing the edits.
So, my question is:
Is There a Way to Create a Library Asset "In One Go", Original Image and Adjustment Data?
Although I haven't tried this on my code yet (I have more urgent issues now), I seem to have found what seems to be the exact answer to my question in Apple's documentation for one of the initializers of the PHContentEditingOutput class:
init(placeholderForCreatedAsset: PHObjectPlaceholder)
From the docs:
Discussion
Use this method if you want to add a new asset to the Photos library
with edited content, as opposed to editing the content of an asset
after adding it to the library. For example, you might use this option
if your app applies filters to photos it captures with the device
camera—instead of saving only the filtered image to the Photos
library, your app can save both the filtered and the original image,
allowing the user to revert to the original image or apply different
filters later.
Also:
Note
If your app edits the contents of assets already in the Photos
library—including assets your app has itself recently added—Photos
prompts the user for permission to change the asset’s content. If
instead your app uses the init(placeholderForCreatedAsset:) method to
create an asset with edited content, Photos recognizes your app’s
ownership of the content and therefore does not need to prompt the
user for permission to edit it.
I guess we all need a healthy dose of RTFM once in a while! :-)
Is there any way to save a file (to be exact, a .csv) somewhere outside the application sandbox? From what I've read it seems like it is only possible to save files inside the sandbox.
Maybe I'm thinking about it the wrong way, maybe I don't really need to save it outside the sandbox. What I actually need to do is:
Allow the user to save the file, so that he can use it in other applications (for example email client), and it would be best if the file would stay on his device after he deleted the app. The location of the saved file doesn't really matter, it could be chosen by user with some file picker or hard-coded. Is there any way to achieve this?
I'm using xamarin.forms so solution easy to implement in xamarin.forms would be much appreciated.
From what I've read it seems like it is only possible to save files inside the sandbox.
That is the general idea. You don't just have access to the filesystem on iOS. You could work around this by maybe saving it to iCloud or Dropbox, etc. depending on your use-case but basically you can't just save it somewhere common. Normally, you would then implement the 'share' functionality. What happens then is that iOS copies the file into the other apps' sandbox so it can work with it.
Whenever we upload a media file to our Umbraco CMS, it generates a unique media id in the filename. So a file like example.jpg will be given a url like:
http://content.example.com/media/947/example.jpg
And if we update the file, it gets a new media id.
This is incredibly annoying, because there's no way to make a permalink to the image! We want to be able to create links to image files that non-technical people upload, but having a random and possibly changing id in the url means that any such link is in danger of breaking without warning.
So, is there any way to upload media files to Umbraco and have them placed in a static location?
First of all, we need to think: for what we want to use it? If it will be used inside the currently developed website and needs to be managable, I don't see any reasons why current url convention or anything else with media may be considered as a blocker / barrier. It just requires to enable editors to select media in document types properties (in proper way e.g. using MediaPicker, MultiNodeTreePicker etc.) and while it's processed and rendered we can easily grab the URL of the file having media id and put this anywhere in the HTML markup. Ba! It's even better in my opinion, cause when we delete or re-upload the file, we don't need to change anything else inside the code or markup or logic, cause ID of the media file is not changing and we're still able to use it.
I don't know if any CMS enables users to be responsible of media files URLs creation... But if this is a case, basically, there is a way (or even more than one) to achieve this:
"Hacky way" - "File" document type and template returning data
You can create new document type with MediaPicker property inside of it. Then create and assign template with C# / Razor logic (depending if you want to e.g. hijack the route with custom controller or just render or return file inside the template) and just return file data in your desired way. If you want to display image - you can render it, if you want to play the audio or video - you can return proper objects / html5 tags or anything else. It may be a long switch statement covering all of the allowed file types and methods of returning them to user. You can also process the file and return it in HttpResponse to force browser to send file and user to download the file to his disk. Tricky one.
"Umbraco advanced dev way" - Custom FileSystemProvider
We can create custom FileSystemProvider and assign it to be used in MediaFileSystem. It can swap whole media workflow of retrieving and adressing the media. To be honest, I wasn't playing with this too much, but there is open-source project of media provider which stores media on Azure Blobs (https://our.umbraco.org/projects/collaboration/umbracofilesystemprovidersazure/) so we can preview how it's done there and adopt to our own scenario.
More info about custom FileSystemProvider: https://our.umbraco.org/documentation/extending/custom-file-systems.
"Not recommended way" - Duplicating files in custom directory during MediaService save event
It's the worst solution from the above in my opinion, as it removes all the great features which Umbraco gives us "out of box" for managing and processing media files (e.g. ImageCropper), but... we're able to hook up into MediaService events (https://our.umbraco.org/documentation/reference/events/mediaservice-events) and do whatever we want with file(s) uploaded to our site. It means that we're also able to duplicate files and place them to our custom directory which needs to be adopted and adjusted to be visible and used "from the outside".
So, as you can see - everything is possible :) But, getting back to the beggining of this long post - we need to think for what we want to use it and if we really need it. I still can't find any use case where I needed cool, awesome, custom media file IDs. If I would need them, I will use any url shorteners e.g. bit.ly, for campaing or anything else what will also give me a great analyze tool providing me data about number of downloads for example.
How can I protect files in my application "Documents" directory? Using iFunBox, or another application like it, anyone can to see, what application store in it's documents directory. So if I want to store some private data, or information about in-apps status, gold, achievments or something else just in .plist-files it will be not safelly.
Maybe there is a best-practices for iOS application how to secure and protect their data?
It is not possible to truly secure data from the user. It is naturally secured from other applications, but the user is always able to get access to everything on-disk or in memory.
That said, if you have data that the user is not supposed to access, then you should not store it in Documents, since this is backed up via iTunes. You should store it in Library. See "The Library Directory Stores App-Specific Files" in the File System Programming Guide for details on each possible location and how it is treated by the system.
Applications you make for iOS are sandboxed, i.e., the apps feel like they are the only thing on the system. As a result, they cannot access any place outside the app. You are restricted to using the Documents, Library folders which are visible to applications like iFunBox.
Your best bet is to hash out the data and then store them to files, so that if anyone tries to edit your files it results in a hash mismatch, that you can read in your application, and make your data secure.