Disable confirmation on delete request in PHPhotoLibrary
Asked Answered
I

1

9

What I am trying to do is to save videos to PHPhotoLibrary, and then remove them when upload to clients remote server in the application completes (basically, photo library serves as temporary storage to add additional layer of security in case anything at all fails (I already save my vides it in the applications directory).

Problem:

The problem is for that to work, everything has to work without input from the user. You can write video to photos library like this:

func storeVideoToLibraryForUpload(upload : SMUpload) {

    if PHPhotoLibrary.authorizationStatus() != PHAuthorizationStatus.Authorized {

        // Don't write to library since this is disallowed by user
        return
    }

    PHPhotoLibrary.sharedPhotoLibrary().performChanges({ () -> Void in

        // Write asset
        let assetRequest = PHAssetChangeRequest.creationRequestForAssetFromVideoAtFileURL(NSURL(fileURLWithPath: upload.nonsecureFilePath!)!)
        let assetPlaceholder = assetRequest.placeholderForCreatedAsset
        let localIdentifier = assetPlaceholder.localIdentifier

        // Store local identifier for later use
        upload.localAssetIdentifier = localIdentifier

    }, completionHandler: { (success, error) -> Void in
        ....
    })
}

And that works flawlessly, I get local identifier, I store it for later use.. Unicorns and rainbows.

Now when I want to remove that video immediately after upload finishes, I call following:

func removeVideoFromLibraryForUpload(upload : SMUpload) {

    // Only proceed if there is asset identifier (video previously stored)
    if let assetIdentifier = upload.localAssetIdentifier {

        // Find asset that we previously stored
        let assets = PHAsset.fetchAssetsWithLocalIdentifiers([assetIdentifier], options: PHFetchOptions())

        // Fetch asset, if found, delete it
        if let fetchedAssets = assets.firstObject as? PHAsset {

            PHPhotoLibrary.sharedPhotoLibrary().performChanges({ () -> Void in

                // Delete asset
                PHAssetChangeRequest.deleteAssets([fetchedAssets])

            }, completionHandler: { (success, error) -> Void in
                ...
            })
        } 
    }
}

Which successfully deletes the video, BUT user have to confirm deletion first. That is a problem as that backing up won't work.

I obviously know why there is confirmation (so you don't clear entire user library for example, but the thing is, My app made the video - and so I thought there will be way around it, since as an "owner" I should not be doing that, or at least have option to disable confirmation.

Thanks in advance!

TLDR: How can I disable confirmation on delete request, if my application created that content? (I don't want to delete anything else).

Note: Somebody can probably say this is rather strange thing to do but the application is distributed internally and there is good reason to do it like this (the video content is too valuable to be lost, even if user deletes the application for some reason, or there is anything at all that goes wrong, we need to be able to preserve the videos), so please don't question that and just focus your attention on the question :)

Imprisonment answered 10/8, 2015 at 14:54 Comment(5)
I don't definitively know the answer to this question, but I doubt it's possible. Once you save an asset to the device photo library you are no longer the owner, and it is right for it to ask for a delete confirmation for the reason you already mentioned. So, ignoring your "Note" for a minute: what makes saving your assets via the Photos framework safer than saving it yourself?Amritsar
I am saving the video content myself to application directory (encrypted), but videos will be deleted if user fe. removes the application ; It already happened because users are strange creatures so we are trying to prevent even that - the videos would be safely stored in the photos. Problem is that due to some content ownership problems, we have to delete immediately as we upload it to our server (basically there is system that continues upload after device is on the internet again, since the device is used in the field without connection).Imprisonment
So what happens when the user erases their device, or loses it, or just deletes the asset directly from Photos? Content loss is generally avoided by backing up / syncing / telling users not to delete the damn app (!), not by hijacking another app's storage mechanism - you're only avoiding one of many "user stupidities"! Sorry to pick you up on the point when you asked people not to, but I think it's worth considering. Unless someone with more knowledge of the Photos framework can prove me wrong, I think you might have to put up with the alert, or consider rethinking your approach.Amritsar
I definetely agree. There is a lot of problems that I cannot cover and I have the same opinion. I was just wondering if it is possible and I needed another opinion, but I will probably just scrap the feature and improve guide about what to do / not do. If you post the answer saying it is not possible, I will accept it for you efford. Thanks :)Imprisonment
I appreciate it - I'm sorry I couldn't be of more help regarding the delete confirmation.Amritsar
A
5

I cannot see a way to avoid the delete confirmation. It is an implementation detail of the Photos framework, similar to the way you cannot prevent the device from asking the user's permission to use the microphone when your app tries to use it, and is a matter of security & trust. Once you have saved an asset to the device photo library your app is no longer the owner of that asset, so as you noted in your question the device must of course ensure the app has the user's permission before it goes about deleting such data.

You can never entirely safeguard your users' data against their own unpredictable behaviour - if they decide to remove your app, or delete a particular asset from within Photos, it is up to them. I think your best option is to either put up with the built-in delete confirmation, or to provide a guide to your users that makes it clear that they should be careful to protect this important data by backing up their device, and not deleting the app!

If you did decide to stick to this approach, perhaps the best thing you could do is to prepare the user for the fact that their device may ask them for confirmation to delete a file that is being uploaded to your own servers. For example, put up your own modal alert just before trying to delete the asset. I wouldn't normally suggest that kind of approach for a public shipping app, but since you're only distributing internally it may be acceptable for your team.

Amritsar answered 10/8, 2015 at 19:37 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.