iOS之UITableView带滑动操作菜单的Cell(上)

本文翻译自 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 的邮件应用:

Multiple Options

可能你会想,既然 Apple 展示了这种方案,那它应该已将其开放给开发者使用了。毕竟,这能有多难呢?但不幸的是,他们只让开发者使用 Delete 按钮——至少暂时是这样。如果你要添加其他的按钮,或者改变 Delete 按钮上的文字或颜色,那你就必须自己去实现。
译者注:其实文字是可以修改的,但是颜色真的不行!
在本教程中,你将先学习如何实现简单的滑动以删除操作(swipe-to-delete action),之后我们再实现滑动以执行操作(swipe-to-perform-actions)。这会要求你深入研究 iOS 7UITableViewCell
的结构,以便复制出我们需要的行为。你将使用到一些我个人非常喜欢的技术用于检查视图层次结构:为视图上色以及使用recursiveDescription
方法来打印出视图层次结构。
开始
打开 Xcode,去往File\New\Project…
并选择Master-Detail Application
,如下所示:
Master-Detail Application

将项目命名为SwipeableCell
并填好你自己的 Organization Name 和 Company Identifier 。选择iPhone
为目标设备并确保Use Core Data
没有被选中,如所示:
Set Up Project

对于这样的概念项目的证明,你最好保证数据模型尽量简单。
打开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
。这个方法现在不正确,因为插入已经不再被支持了。
编译并运行应用;你会看到一个简单列表,如下所示:

Closed Easy

滑动某一行到左边,你就会看到一个 “Delete” 按钮,如下所示:
Easy delete button

喔~——这很简单。但现在是时候弄脏双手,深挖进视图层次结构,看看里面到底发了什么。
深入视图层次结构(View Hierarchy)
首先:你要找到 Delete 按钮在视图层次结构里的位置,然后你才能决定是否可以将其用于你自定义的 Cell 。
最容易做到这一点的方式是将 View 的各个部分分别染色,以便清楚地看到它们地位置和范围。
继续在MasterViewController.m
里工作,添加如下两行到tableView:cellForRowAtIndexPath:
里,就在最后的return
语句之上:
cell.backgroundColor = [UIColor purpleColor];cell.contentView.backgroundColor = [UIColor blueColor];

这些颜色足够让我们看清这些视图在 Cell 中的位置。
再次编译并运行,你会看到着色后的元素,如下面的截图所示:

Colored Cells

你会清楚地看到蓝色的contentView
停止在 Accessory Indicator 之前,但整个 Cell 自身以紫色高亮,填满了到UITableView
的边缘。
往左边拖动 Cell ,你会看到类似下面的的界面:
Start to drag 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:> | ; layer = ; contentOffset: {0, 0}> | | > | | | > | | ; layer = > | | | >

又要哇~——信息真不少。你所看到的是递归的描述log语句,在每次 Cell 被创建或回收时都会打印。所以你会看到好几个这种消息,因为初始的屏幕上有好几个 Cell 。recursiveDescription
会走遍特定视图的每个子视图,输出子视图的描述,并按照视图层次结构排列。它会递归地做这件事,所以对于每个子视图,它也会再去寻找它们的子视图。
虽然信息很多,但它是根据视图层次结构在每个视图上都调用了recursiveDescription
。因此如果你单独打印每个子视图的描述,你会看到同样的信息,但这个方法在子视图的输出前加了一个|
符号和一些空格,以便反映出视图的结构。
为了更加易读,下面光拿出类名和 Frame 来看:

 //1 |  //2 | |  //3 | | |  //4 | |  //5 | | |  //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。

你可能感兴趣的:(iOS之UITableView带滑动操作菜单的Cell(上))