为什么reloadRowsAtIndexPaths不能用于iOS 5.0? [英] Why does reloadRowsAtIndexPaths not work for iOS 5.0?

查看:95
本文介绍了为什么reloadRowsAtIndexPaths不能用于iOS 5.0?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

已解决:请参阅下面的答案(以及可能的解释)。

SOLVED: See my answer (and possible explanation) below.

我正在制作适用于iOS 5.1设备的应用程序,但不适用于iOS 5.0设备。以下是适用于5.1但不适用于5.0的故障代码:

I'm making an app that works on iOS 5.1 devices, but not on iOS 5.0 devices. Here is the trouble code that works on 5.1 but NOT on 5.0:

- (void) expandIndexPath: (NSIndexPath *) indexPath afterDelay: (BOOL) delay
{
    NSIndexPath *oldSelectedIndexPath = [NSIndexPath indexPathForRow:self.mySelectedIndex inSection:0];
    self.mySelectedIndex= indexPath.row; 
//  [self.myTableView beginUpdates];
    [self.myTableView reloadRowsAtIndexPaths:[NSArray arrayWithObjects:[NSIndexPath indexPathForRow:self.mySelectedIndex inSection:0], oldSelectedIndexPath,nil] withRowAnimation:UITableViewRowAnimationNone]; 
//  [self.myTableView endUpdates];
}

更奇怪的是,如果我更换<$ c,它可以在iOS 5.0中运行$ c> reloadRowsAtIndexPaths 行 [self.myTableView reloadData]; 。为什么是这样? 5.0有关于reloadRowsAtIndexPaths行的错误吗?我已经在5.0上尝试了它,无论是否使用 begin / endUpdates 行都没有效果。

Even more curiously, it works in iOS 5.0 if I replace the reloadRowsAtIndexPaths line with [self.myTableView reloadData];. Why is this? Did 5.0 have a bug regarding the reloadRowsAtIndexPaths line? I've tried it on 5.0 with and without begin/endUpdates lines and neither works.

编辑:更具体地说,当我在iOS 5上运行应用程序时,它崩溃并出现以下错误:

To be more specific, when I run the app on iOS 5 it crashes with the following error:

* 中的断言失败 - [_ UITableViewUpdateSupport _computeRowUpdates] / SourceCache / UIKit / UIKit-1912.3 / UITableViewSupport.m:386
[切换到处理7171线程0x1c03]

* Assertion failure in -[_UITableViewUpdateSupport _computeRowUpdates], /SourceCache/UIKit/UIKit-1912.3/UITableViewSupport.m:386 [Switching to process 7171 thread 0x1c03]

由于未捕获的异常而终止应用程序' NSInternalInconsistencyException ',原因:'无效的表视图
更新。应用程序已请求更新表视图
,这与数据源提供的状态不一致。'

Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Invalid table view update. The application has requested an update to the table view that is inconsistent with the state provided by the data source.'

编辑:这是我的UITableViewDataSource方法。

Here are my UITableViewDataSource methods.

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section
{
    //I am positive that this will ALWAYS return the number (it never changes)
    return self.myCellControllers.count;
}

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
    //I cache my table view cells, thus each time this method gets called it will 
    // return the exact same cell. Yes, I know that most of the time I should be dequeing
    // and reusing cells; just trust me that this time, it's best for me to cache them
    // (There are very few cells so it doesn't really matter)
    CellController *controller = [self.myCellControllers objectAtIndex:indexPath.row];
    return controller.myCell;
}

- numberOfSectionsInTableView: always returns 1;

唯一有趣的方法是

- (CGFloat)tableView:(UITableView *)aTableView heightForRowAtIndexPath:(NSIndexPath *)indexPath
{
    if(indexPath.row == self.mySelectedIndex)
    {
        return DEFAULT_CELL_HEIGHT + self.expandSize;
    }
    else
    {
        return DEFAULT_CELL_HEIGHT;
    }
}

正如快速概述这一部分的程序工作,当用户点击一个单元格时,单元格滚动到屏幕的顶部。在它位于屏幕顶部之后,它的索引被设置为 self.mySelectedIndex 并且它会扩展(变得更高)。

Just as a quick overview of how this part of the program works, when a user taps a cell, the cell scrolls to the top of the screen. After it is at the top of the screen it's index gets set as self.mySelectedIndex and it expands (gets taller).

推荐答案

我找到了一个有效的解决方案。如果我将 expandIndexPath 方法改为此方法,则可以:

I found a solution that works. If I change the expandIndexPath method to this it works:

- (void) expandIndexPath: (NSIndexPath *) indexPath afterDelay: (BOOL) delay {
    [self.myTableView beginUpdates];
    NSIndexPath *oldSelectedIndexPath = [NSIndexPath indexPathForRow:self.mySelectedIndex inSection:0];
    self.mySelectedIndex= indexPath.row;
    if(oldSelectedIndexPath.row >= 0)
    {
        [self.myTableView reloadRowsAtIndexPaths:[NSArray arrayWithObjects:[NSIndexPath indexPathForRow:self.mySelectedIndex inSection:0],oldSelectedIndexPath, nil] withRowAnimation:UITableViewRowAnimationNone]; 
    }
    else 
    {
        [self.myTableView reloadRowsAtIndexPaths:[NSArray arrayWithObjects:[NSIndexPath indexPathForRow:self.mySelectedIndex inSection:0],nil] withRowAnimation:UITableViewRowAnimationNone]; 
    }
    [self.myTableView endUpdates]; 
}

据我所知,问题在于 oldSelectedIndexPath 有时被设置为负行值。因此,当我尝试重新加载带有负行的indexPath时,它在iOS 5.0中崩溃了。似乎iOS 5.1修复此问题并进行更多错误检查。

As far as I can tell, the problem was that oldSelectedIndexPath was sometimes being set with a negative row value. Thus when I tried to reload an indexPath with a negative row, it crashed in iOS 5.0. It appears that iOS 5.1 fixes this and does more error checking.

这篇关于为什么reloadRowsAtIndexPaths不能用于iOS 5.0?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆