# # # # introduction

I worked overtime yesterday, and it was smooth, but then I took a 6P to test and installed 8.4.1 system. My heart said that it was really cattle, so old system is still left, and the test said that I was afraid that some users do not update and like this version. It was not a big deal, but I did not expect to find out the BUG let me jump, hereby record.

  • 1. The delete button does not appear when you swipe on version 8.4.1
  • 2. In version 8.4.1, the program blinks when returning to the previous interface pop after sideslip (note: after entering the interface to be deleted, if there is no click operation on the table, there is no right swipe operation to delete, returning to the previous interface will not crash,😔, in fact, it should be seen here) ##### first, there is no such situation in the latest version iOS11, and there should be no such situation in other versions, otherwise the test will find me. I first checked to see if the API I called was in iOS8,
 -(BOOL)tableView:(UITableView *)tableView canEditRowAtIndexPath:(NSIndexPath *)indexPath
{
    if (indexPath.section == 1)//new
    {
        return YES;
    }

    return NO;
}
Copy the code

-(nullable NSArray

*)tableView:(UITableView *)tableView editActionsForRowAtIndexPath:(NSIndexPath *)indexPath{} ######NS_AVAILABLE_IOS(8_0) __TVOS_PROHIBITED This API says you can use it after iOS8, disable it in watchOS. Logically, that should be true, but there is no reason to say that there is no response to sideslip on the eight. So I looked it up, and the big boys said it was because of what balabala plus

-(void)tableView:(UITableView *)tableView commitEditingStyle:(UITableViewCellEditingStyle)editingStyle forRowAtIndexPath:(NSIndexPath *)indexPath{}

Add this code, you don’t have to write anything, and then you’re done. (should be iOS8 in the lower version will call this method first, and then go to the new method, do not understand) ##### two, this Bug is more chicken thief, flash back when there is no crash prompt, directly to the main In the function, when searching, see the big guy said, generally jump directly into the main function and do not print any log should be related to memory. Thank you by the way, because I think the API will affect, so I’m going to

-(nullable NSArray

*)tableView:(UITableView *)tableView EditActionsForRowAtIndexPath: (NSIndexPath *) indexPath {} annotation, has been realized

-(void)tableView:(UITableView *)tableView commitEditingStyle:(UITableViewCellEditingStyle)editingStyle forRowAtIndexPath:(NSIndexPath *)indexPath
{
  if(editingStyle ==UITableViewCellEditingStyleDelete) { [self removeAction:indexPath.row]; // This method deletes an array element and refreshes the list}}Copy the code

The next thing to do is to check the zombie method in Xcode. How to open it? ###### Please press Command + Shift +< to see the screenshot

The 2017-12-25 10:13:05. 194 xx treasure [1621, 124805] * * * – [STrustDeviceManagerViewController tableView: canEditRowAtIndexPath:] : message sent to deallocated instance 0x158aedfc0

A search revealed that someone had encountered this problem several years ago. The following is mostly from the original text

Startong blog

That is to say, the tableView: canEditRowAtIndexPath this method has a problem, that I wondered how this method might have a problem, it is no wonder that I commented out before this approach was no problem, here have a question, did know that solve the problem for it would not be what is difficult, I initially suspect that there is a problem with return YES.

So, I added these lines of code to the function

  • -(void)viewWillDisappear:(BOOL)animated {

    [super viewWillDisappear:animated];

    [self.bgTableView setEditing:NO]; }

Then run again, repeat the previous operation, problem solved, perfect，，，，

Although the problem was solved, I still felt that there should be no problem with canEditRowAtIndex, so I ran the program under the simulator of ios 6 and repeated operation was no problem (of course, viewWillDisappear method was commented out). Later, I found a lot of information on the Internet. There’s a lot of talk that maybe it’s apple, it’s ios7, it’s not ios6 or anything like that,

At this point, the problem is solved, and there are two solutions listed above: 1. Delete the canEditRowAtIndexPath method. (PS: This is not good, the second area in my table can only be deleted, and there is a row in it can not be deleted, this method can be used, but it depends on your actual needs.)

2. Add the viewWillDisappear method mentioned above to solve the problem. But I personally recommend the second method, although the first method can also solve the problem, but I still think it is better to use the two methods together.

The error may be caused by setting YES in the canEditRowAtIndexPath method and returning it without setting it to NO. Ios6 will set it to NO automatically, iOS7 will also set it to NO manually. So in any future version, we’re going to add viewWillDisappear and manually set editing to NO to make sure there’s nothing wrong.

By the way, iOS9 does not have this problem, I guess Apple has also dealt with this problem, in the interface release, automatically set to NO, so can upgrade as soon as possible, do not make the app ape pain. If it works for you, please give me a thumbs up and a note. Thank you for the