Skip to content

Media Library #3: Deletion#6858

Merged
frosty merged 16 commits intodevelopfrom
feature/media-library-deletion
Mar 14, 2017
Merged

Media Library #3: Deletion#6858
frosty merged 16 commits intodevelopfrom
feature/media-library-deletion

Conversation

@frosty
Copy link
Contributor

@frosty frosty commented Mar 10, 2017

This PR adds the ability to delete media items from the Media Library. There are two ways to do it:

  1. View the detail screen for any media item and tap the trashcan in the navigation bar. Tap the Delete button, and the item will be deleted.
  2. On the media library grid screen, tap the Edit button in the navigation bar, and then select a number of media items. Tap the trashcan to delete them.

Note: This PR currently references a MediaPicker-iOS branch which contains a couple of necessary tweaks. Once that's approved, I'll push out a new pod version and update this branch accordingly.

To test:

  • Perform the steps above. Check on both dotcom and self-hosted.
  • Check the collection view and navigation bar update their state correctly as you enter and exit from Edit mode.
  • Check nothing crashes if you delete an item whilst its full size image is still loading in the detail view.

Needs review: @kurzee

@frosty frosty added the Media label Mar 10, 2017
@frosty frosty added this to the 7.2 ❄️ milestone Mar 10, 2017
@frosty frosty requested a review from kurzee March 10, 2017 15:07

[mediaObjects enumerateObjectsUsingBlock:^(Media *media, NSUInteger idx, BOOL *stop) {
dispatch_group_enter(group);
[self deleteMedia:media success:^{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like case to reconsider implementing back support for batch calls in the REST API . :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did we have it previously?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes we did, it was removed when the API code was updated to swift and URLSession.
Maybe add a issue for us to have a look in the future.

@kurzee
Copy link
Contributor

kurzee commented Mar 10, 2017

One scenario:

  1. Open Media, select an item for the detail.
  2. Open Editor, Media Picker, select Media Library.
  3. Go to the web, delete the same Media item selected in the detail on step 1.
  4. In the app, refresh Editor's Media picker while it's open. The item is deleted from both the picker and the Media Library behind the views.
  5. Close the editor modals. Notice the detail is still visible.

It didn't crash! But, it would be cool if we could reliably pop the detail view. I also imagine it would crash if proceeding on to editing details.

@kurzee
Copy link
Contributor

kurzee commented Mar 10, 2017

Very similar to the case in #6858 (comment)

  1. Open Media, select Edit and select an item.
  2. Open Editor, Media Picker, select Media Library.
  3. Go to the web, delete the same Media item selected in step 1.
  4. In the app, refresh Editor's Media picker while it's open. The item is deleted from both the picker and the Media Library behind the views.
  5. Close the editor modals. Notice the nav bar still show the enable Trash bar button item and cancel.

@kurzee
Copy link
Contributor

kurzee commented Mar 10, 2017

Looks like the Cancel bar button item stays enabled during the deletion of items, as does the trash button.

Copy link
Contributor

@kurzee kurzee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@frosty on first pass this works really well! Just a few code comments and edge cases to take a look at handling.


[self.wordPressComRestApi POST:requestUrl
parameters:nil
success:^(id responseObject, NSHTTPURLResponse *response) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we check the API response for "status": "deleted" as seen on https://developer.wordpress.com/docs/api/1.1/post/sites/%24site/media/%24media_ID/delete/?

Copy link
Contributor Author

@frosty frosty Mar 13, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Our delete post code doesn't seem to check the response, but I guess it couldn't hurt to do so. I've updated the remotes code to do this. I wasn't really sure what sort of error to pass if the response wasn't what we expected. Any suggestions? Is what I've done okay?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While a bit painful, probably best go ahead and knock it out now with something like https://github.com/wordpress-mobile/WordPress-iOS/blob/develop/WordPress/Classes/Services/MediaService.m#L339 and a message of "Something went wrong, please try again" or the like.

NSParameterAssert([media.mediaID longLongValue] > 0);

NSArray *parameters = [self XMLRPCArgumentsWithExtra:media.mediaID];
[self.api callMethod:@"wp.deleteFile"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, couldn't find any documentation for this endpoint, was wondering if it also had some sort of success result to parse for the response.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's actually just an alias for wp.deletePost, which returns true if successful. I guess we should check that value.

success:(nullable void (^)())success
failure:(nullable void (^)(NSError * _Nonnull error))failure;

/**
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

multiple Media object

@param progress a block that will be invoked after each media item is deleted successfully
@param success a block that will be invoked when the media deletion finished with success
@param failure a block that will be invoked when there is an error.
*/
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could be a bit more Swifty in Obj-C and also name this method deleteMedia with the different argument types from (void)deleteMedia:(nonnull Media *)media 😃

Also a : alignment issue with the declaration.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I went with deleteMultiple... to match the existing updateMultiple... method. Perhaps we could revisit this in the future (convert the whole lot to Swift? 😁)

// Check the media hasn't been deleted whilst we were loading.
if (!media || media.isDeleted) {
if (success) {
success(nil);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like this would go ahead against the _Nonnull in success:(nullable void (^)(UIImage * _Nonnull image))success.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've adjusted this to return a new, empty UIImage. Alternative would be to change the method signature, but I think it's probably best to leave that as-is?


@objc private func trashTapped() {
let alertController = UIAlertController(title: nil,
message: NSLocalizedString("Are you sure you want to permanently delete these items?", comment: "Message prompting the user to confirm that they want to permanently delete a group of media items."), preferredStyle: .alert)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at Calypso, we should also provide a singular form of this text when only selecting one item and pressing delete. Are you sure you want to permanently delete this item?

@frosty
Copy link
Contributor Author

frosty commented Mar 13, 2017

Thanks for the review, @kurzee, and for catching those edge cases! I think I've covered them all now, except for:

Looks like the Cancel bar button item stays enabled during the deletion of items, as does the trash button.

I'm not quite sure I understand. You mean in the media library view, when the HUD is visible? I just tested it here and I wasn't able to tap those items.

Care to take another look?

@astralbodies astralbodies modified the milestones: 7.3 ❄️, 7.2 ❄️ Mar 13, 2017
@kurzee
Copy link
Contributor

kurzee commented Mar 13, 2017

For this one #6858 (comment)

I was able to reproduce, however only the "Cancel" left bar button item remained enabled, while the trash button disable, both were visible so the editing state is still enabled.

Note: I guess this is expected though since we had entered the editing state.

@kurzee
Copy link
Contributor

kurzee commented Mar 13, 2017

I'm not quite sure I understand. You mean in the media library view, when the HUD is visible? I just tested it here and I wasn't able to tap those items.

Care to take another look?

All good on this one.

@kurzee
Copy link
Contributor

kurzee commented Mar 13, 2017

Everything checks out, just the errors comment, which could be separate if you want or tackled with refactoring later.

Also, conflict on Podfile.lock.

:shipit: when ready!

@frosty
Copy link
Contributor Author

frosty commented Mar 14, 2017

Thanks @kurzee! As discussed, staying in Edit mode is intentional and we can improve the errors later if we need to :)

@frosty frosty merged commit 0297842 into develop Mar 14, 2017
@frosty frosty deleted the feature/media-library-deletion branch March 14, 2017 19:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants