本文翻译自 http://www.raywenderlich.com/62435/make-swipeable-table-view-cell-actions-without-going-nuts-scroll-views
原作者：Ellen Shapiro
Apple 通过 iOS 7 的邮件（Mail）应用介绍了一种新的用户界面方案——向左滑动以显示一个有着多个操作的菜单。本教程将会向你展示如何制作一个这样的 Table View Cell，而不用因嵌套的 Scroll View 陷入困境。如果你还不知道一个可滑动的 Table View Cell 意味着什么，那么看看 Apple 的邮件应用：
可能你会想，既然 Apple 展示了这种方案，那它应该已将其开放给开发者使用了。毕竟，这能有多难呢？但不幸的是，他们只让开发者使用 Delete 按钮——至少暂时是这样。如果你要添加其他的按钮，或者改变 Delete 按钮上的文字或颜色，那你就必须自己去实现。
译者注：其实文字是可以修改的，但是颜色真的不行！
在本教程中，你将先学习如何实现简单的滑动以删除操作（swipe-to-delete action），之后我们再实现滑动以执行操作（swipe-to-perform-actions）。这会要求你深入研究 iOS 7UITableViewCell
的结构，以便复制出我们需要的行为。你将使用到一些我个人非常喜欢的技术用于检查视图层次结构：为视图上色以及使用recursiveDescription
方法来打印出视图层次结构。
开始
打开 Xcode，去往File\New\Project…
并选择Master-Detail Application
，如下所示：
将项目命名为SwipeableCell
并填好你自己的 Organization Name 和 Company Identifier 。选择iPhone
为目标设备并确保Use Core Data
没有被选中，如所示：
对于这样的概念项目的证明，你最好保证数据模型尽量简单。
打开MasterViewController.m
并找到viewDidLoad
。将默认设置 Navigation Bar Items 的方法替换为如下实现：
- (void)viewDidLoad { [super viewDidLoad]; //1 _objects = [NSMutableArray array]; //2 NSInteger numberOfItems = 30; for (NSInteger i = 1; i <= numberOfItems; i++) { NSString *item = [NSString stringWithFormat:@"Item #%d", i]; [_objects addObject:item]; }}
这个方法做了两件事：
这一行创建并初始化一个NSMutableArray
实例，以后你就可以添加对象到它里面了。如果你的数组没有被初始化，那不论你调用addObject:
多少次，你的那些对象都不会被存储起来。译者注：读者还是尽量用 Lazy Load 来实现吧！
这个循环添加了一些字符串到_objects
数组，应用运行时，这些字符串将用于显示在 Table View 里。你可以修改 numberOfItems 的值，以存储适合你的更多或更少的字符串。
下一步。找到tableView:cellForRowAtIndexPath:
并替换其实现为：
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath { UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:@"Cell" forIndexPath:indexPath]; NSString *item = _objects[indexPath.row]; cell.textLabel.text = item; return cell;}
原本tableView:cellForRowAtIndexPath:
的样板使用日期字符串作为简单数据；而你的实现使用你的数组里的NSString
对象去填充UITableViewCell
的textLabel
。
往下滚动到tableView:canEditRowAtIndexPath:
；你会看到这个方法已经设置为返回YES
，也就是说， Table View 的每一行都支持编辑。
就在这个方法下边，tableView:commitEditingStyle:forRowAtIndexPath:
处理对象的删除。然而，因为你还不能添加任何东西到这个应用里，那就先稍微修改它一下以适应你的需求。
用下面的代码替换tableView:commitEditingStyle:forRowAtIndexPath:
：
- (void)tableView:(UITableView *)tableView commitEditingStyle:(UITableViewCellEditingStyle)editingStyle forRowAtIndexPath:(NSIndexPath *)indexPath { if (editingStyle == UITableViewCellEditingStyleDelete) { [_objects removeObjectAtIndex:indexPath.row]; [tableView deleteRowsAtIndexPaths:@[indexPath] withRowAnimation:UITableViewRowAnimationFade]; } else { NSLog(@"Unhandled editing style! %d", editingStyle); }}
当用户删除某行时，你就用传入的 Index 将那一行的对象从后面的数组中移除，并告知 Table View 它需要移除同一个indexPath
所表示的那一行 Cell，一确保模型和视图的匹配。
你的应用只允许“delete”这一种编辑方式，但在 else 分支里用 log 记录你没有在处理什么也不错。如果有某个诡异的事情发生，你将会在控制台得到一个提示消息，这比方法静悄悄地返回要好。
最后，还有一些清理要做。依然在MasterViewController.m
里，删除insertNewObject
。这个方法现在不正确，因为插入已经不再被支持了。
编译并运行应用；你会看到一个简单列表，如下所示：
滑动某一行到左边，你就会看到一个 “Delete” 按钮，如下所示：
喔～——这很简单。但现在是时候弄脏双手，深挖进视图层次结构，看看里面到底发了什么。
深入视图层次结构（View Hierarchy）
首先：你要找到 Delete 按钮在视图层次结构里的位置，然后你才能决定是否可以将其用于你自定义的 Cell 。
最容易做到这一点的方式是将 View 的各个部分分别染色，以便清楚地看到它们地位置和范围。
继续在MasterViewController.m
里工作，添加如下两行到tableView:cellForRowAtIndexPath:
里，就在最后的return
语句之上：
cell.backgroundColor = [UIColor purpleColor];cell.contentView.backgroundColor = [UIColor blueColor];
这些颜色足够让我们看清这些视图在 Cell 中的位置。
再次编译并运行，你会看到着色后的元素，如下面的截图所示：
你会清楚地看到蓝色的contentView
停止在 Accessory Indicator 之前，但整个 Cell 自身以紫色高亮，填满了到UITableView
的边缘。
往左边拖动 Cell ，你会看到类似下面的的界面：
看起来 Delete 按钮实际上隐藏在 Cell 的下面。唯一能 100% 确保的方式是在视图层次结构中再挖深一点。
为了辅助你的视图考古，你可以用一个只能用于调试的方法，叫做recursiveDescription
，它能打印出任意视图的视图层次结构。注意这是一个私有方法， ｀不应该被包含在任何会被放到 App Store 的代码里｀，但它对与视图层次结构实在非常有用。
Note：目前有两个付费应用能让你用可视化的方式检查视图层次结构：Reveal 和 Spark Inspector。另外，还有一个开源项目也可以很好地做到这件事：iOS-Hierarchy-Viewer 。这些应用的价格和质量各有不同，但它们全都要求在你的项目中添加一个库以便支持它们的产品。但如果你不想在项目里安装任何库的话，那recursiveDescription
绝对是得到这些信息的最好的方式。
添加如下打印语句到tableView:cellForRowAtIndexPath:
中，放在 return 语句之前：
ifdef DEBUG NSLog(@"Cell recursive description:\n\n%@\n\n", [cell performSelector:@selector(recursiveDescription)]);#endif
一旦添加了这一行代码，你就会得到一个警告，也就是recursiveDescription
未被申明；因为它是一个私有方法，编译器并不知道它的存在，ifdef / endif
包装器将会额外确保这行代码不会被编译进最终的 release 版里。
编译并运行；你会看到控制台全都是 log 语句，类似下面这样：
2014-02-01 09:56:15.587 SwipeableCell[46989:70b] Cell recursive description:<UITableViewCell: 0x8e25350; frame = (0 396; 320 44); text = 'Item #10'; autoresize = W; layer = <CALayer: 0x8e254e0>> | <UITableViewCellScrollView: 0x8e636e0; frame = (0 0; 320 44); clipsToBounds = YES; autoresize = W+H; gestureRecognizers = <NSArray: 0x8e1d7d0>; layer = <CALayer: 0x8e1d960>; contentOffset: {0, 0}> | | <UIButton: 0x8e22a70; frame = (302 16; 8 12.5); opaque = NO; userInteractionEnabled = NO; layer = <CALayer: 0x8e22d10>> | | | <UIImageView: 0x8e20ac0; frame = (0 0; 8 12.5); clipsToBounds = YES; opaque = NO; userInteractionEnabled = NO; layer = <CALayer: 0x8e5efc0>> | | <UITableViewCellContentView: 0x8e23aa0; frame = (0 0; 287 44); opaque = NO; gestureRecognizers = <NSArray: 0x8e29c20>; layer = <CALayer: 0x8e62220>> | | | <UILabel: 0x8e23d70; frame = (15 0; 270 43); text = 'Item #10'; clipsToBounds = YES; opaque = NO; layer = <CALayer: 0x8e617d0>>
又要哇～——信息真不少。你所看到的是递归的描述log语句，在每次 Cell 被创建或回收时都会打印。所以你会看到好几个这种消息，因为初始的屏幕上有好几个 Cell 。recursiveDescription
会走遍特定视图的每个子视图，输出子视图的描述，并按照视图层次结构排列。它会递归地做这件事，所以对于每个子视图，它也会再去寻找它们的子视图。
虽然信息很多，但它是根据视图层次结构在每个视图上都调用了recursiveDescription
。因此如果你单独打印每个子视图的描述，你会看到同样的信息，但这个方法在子视图的输出前加了一个|
符号和一些空格，以便反映出视图的结构。
为了更加易读，下面光拿出类名和 Frame 来看：
<UITableViewCell; frame = (0 396; 320 44);> //1 | <UITableViewCellScrollView; frame = (0 0; 320 44); > //2 | | <UIButton; frame = (302 16; 8 12.5)> //3 | | | <UIImageView; frame = (0 0; 8 12.5);> //4 | | <UITableViewCellContentView; frame = (0 0; 287 44);> //5 | | | <UILabel; frame = (15 0; 270 43);> //6
目前 Cell 里有六个视图：
UITableViewCell
这是最高层的视图。 Frame 显示它有 320 点宽和 44 点高——宽度和高度都喝预期的一致，因为它和屏幕一样宽，而高度就是 44 点。
UITableViewCellScrollView
虽然你不能直接使用这个私有类，但它的名字很好地暗示了它的功能。它的 Size 和 Cell 的一样。据此我们推断它的作用是在 Delete 按钮之上装载滑动出来的内容。
UIButton
它在 Cell 的最右边，就是 Disclosure Indicator 按钮。注意这不是 Delete 按钮。
UIImageView
是上面UIButton
的子视图，装载着 Disclosure Indicator 的图像。
UITableViewCellContentView
另外一个私有类，它包含 Cell 的内容。这个类对于开发者来说就是UITableViewCell
的contentView
属性。但它只作为一个UIView
来暴露在外，这就意味着你只在其上调用使用公开的UIView
方法；而不能使用任何与这个类关联的任何私有方法。
UILabel
显示 “Item #” 文本。
你会注意到 Delete 按钮并没有显示在上面的视图层次结构排列里。嗯～。可能它只在滑动开始时才被添加到层次结构里。对于优化来说这样做很合理。在不需要 Delete 按钮的时候实在没有必要将其放在那里。要验证这个猜想，就添加如下代码到tableView:commitEditingStyle:forRowAtIndexPath:
，就在处理 delete editing style 的 if 语句中：
#ifdef DEBUG NSLog(@"Cell recursive description:\n\n%@\n\n", [[tableView cellForRowAtIndexPath:indexPath] performSelector:@selector(recursiveDescription)]);#endif
这和之前添加的一样，除了这次我们需要滑动 Cell 以便调用
tableView:commitEditingStyle:forRowAtIndexPath:
：
译者注：上面这一段的原文是“This is the same as before, except this time we need to grab the cell from the table view using cellForRowAtIndexPath:.”，按照我的理解，滑动应该调用tableView:commitEditingStyle:forRowAtIndexPath:
，这样才能执行我们新添加的语句。
编译并运行；滑动第一个 Cell，并点击 Delete。然后看看控制台的输出，找到最后一个递归描述，即第一个 Cell 的视图层次结构。你知道它是第一个 Cell ，因为它的text
属性被设置为Item #1
。你应该看到类型下面的打印：
喔～ 看到 Delete 按钮了！在 Content View 下面， 有一个视图的类名为UITableViewCellDeleteConfirmationView
。所那里就是 Delete 按钮被放置的位置。注意到它的 Frame 的 x 值是 320。这就意味着它被放置在 Scroll View 的最远端。但这个 Delete 按钮在你滑动时并没有移动。所以 Apple 必须在每次 Scroll View 滚动的同时移动这个 Delete 按钮。虽然这不是特别重要，但它很有趣！
现在回到 Cell。
网友评论