拖动时UIRefreshControl下面的白线. [英] White line below UIRefreshControl when pulled.. tableView

问题描述

我正在实现一个非常基本的刷新控件...

    var refreshControl = UIRefreshControl()
    refreshControl.addTarget(self, action: Selector(("refresh:")), for: UIControlEvents.valueChanged)
    refreshControl.backgroundColor = UIColor.red
    self.tableView.addSubview(refreshControl)

出于某种原因，尽管每当我按下刷新按钮时，就好像刷新控件无法跟上表格视图，并且两者之间存在空白.

这是模拟器上的问题...我认为在iPhone上更糟

http://gph.is/2ijyH26

解决方案

尽管我还建议您按照Artem的说明进行操作，但这并不能直接消除我的这种差距.原来我遇到了两个与UIRefreshControl相关的不同问题，并且发现了一些解决这些问题的技巧".简单的解决方法是将tableView的背景颜色设置为与刷新控件相同的颜色，但是这样做的副作用是在表格视图的底部看到相同的颜色.

我的设置是UINavigationController托管UIViewController并带有UITableView子视图，并且将UISearchBar设置为tableView的tableHeaderView.我的目标是使导航栏，刷新控件和搜索栏的颜色匹配.

问题1

我认为这与您遇到的问题相同.似乎只要拖动开始拉动刷新动作，手势的前几个点就会出现间隙.在某个阈值之后，刷新控件将变为正确的颜色.在返回到表格视图的静止滚动状态的途中，我们在到达内容偏移量0之前再次看到了相同的间隙.这是这样的:

解决方案1 ​​

如果您将UIRefreshControl子类化并覆盖frame和isHidden属性，并且仅在设置它们时打印它们的值，您会注意到，刷新控件实际上不会被隐藏，直到与表格视图的顶部是4pt.同样，当您向下滚动时，您还将看到它被设置为隐藏在同一位置，这是在您再也看不到刷新控件以及为什么我们看到表视图背景出现缝隙之前的那个地方了.

在我们的子类中，我们可以通过覆盖isHidden的setter和getter和frame的didSet以仅在刷新控件的偏移量实际上为0时隐藏，来防止这种早期"隐藏和后期"隐藏

class RefreshControl: UIRefreshControl {

    override var isHidden: Bool {
        get {
            return super.isHidden
        }
        set(hiding) {
            if hiding {
                guard frame.origin.y >= 0 else { return }
                super.isHidden = hiding
            } else {
                guard frame.origin.y < 0 else { return }
                super.isHidden = hiding
            }
        }
    }

    override var frame: CGRect {
        didSet {
            if frame.origin.y < 0 {
                isHidden = false
            } else {
                isHidden = true
            }
        }
    }
}

我之所以称其为hack，是因为我不是修改UIRefreshControl的现有行为的忠实拥护者，但是我还没有找到更好的方法来解决此问题.

问题2

当拉动刷新到问题1中的间隙阈值时，似乎UIRefreshControl的框架无法跟上搜索栏的速度.这为我们提供了另一种差距，紧随搜索栏.看起来是这样的:

解决方案2

这个滞后的差距看起来好像帧的更新速度没有我们滚动甚至动画时的速度快.事实证明，如果我们在layoutSubviews之类的地方将框架设置为自身，则会得到以下行为:

override func layoutSubviews() {
    super.layoutSubviews()
    var originalFrame = frame
    frame = originalFrame
}

再次，这确实很棘手，但是我也没有找到其他解决方法.

结果

I am implementing a very basic Refresh control...

    var refreshControl = UIRefreshControl()
    refreshControl.addTarget(self, action: Selector(("refresh:")), for: UIControlEvents.valueChanged)
    refreshControl.backgroundColor = UIColor.red
    self.tableView.addSubview(refreshControl)

for some reason though whenever I pull down to refresh it's like the refresh control cannot keep up with the table view and there is a white gap between the two.

here is the problem on the simulator... it is worse on the iPhone I believe

http://gph.is/2ijyH26

解决方案

While I also suggest you should do what Artem posted, it didn't directly remove that gap for me. Turns out I was running into 2 different issues related to UIRefreshControl and found a few 'hacks' to get around them. The easy fix is to set the tableView's background colour to the same colour as your refresh control, but that has the side effect of seeing the same colour at the bottom of your table view.

My set up is a UINavigationController hosting a UIViewController with a UITableView subview and a UISearchBar set as the tableView's tableHeaderView. My goal is to match the colour of the navigation bar, refresh control, and the search bar.

Issue 1

I think this the same issue that you're seeing. It seems like as soon as you drag to start the pull to refresh action, there's a gap that appears during the first few pts of the gesture. After some threshold, the refresh control becomes the correct colour. On the way back to the table view's resting scroll state though, we see that same gap again just before it reaches a content offset of 0. Here's what that looks like:

Solution 1

If you subclass UIRefreshControl and override the frame and isHidden properties and just print out their values when they are set, you'll notice that the refresh control doesn't actually get unhidden until the distance from the top of the table view is 4pt. Similarly, when you scroll back down you'll also see that it is set to hidden around the same spot, which is before you can't visibly see the refresh control anymore and why we see the gap peeking to the tableView background.

In our subclass, we can prevent this 'early' hiding and 'late' unhiding by overriding the setter and getter of isHidden and the didSet of frame to only hide when the refresh control's offset is actually 0.

class RefreshControl: UIRefreshControl {

    override var isHidden: Bool {
        get {
            return super.isHidden
        }
        set(hiding) {
            if hiding {
                guard frame.origin.y >= 0 else { return }
                super.isHidden = hiding
            } else {
                guard frame.origin.y < 0 else { return }
                super.isHidden = hiding
            }
        }
    }

    override var frame: CGRect {
        didSet {
            if frame.origin.y < 0 {
                isHidden = false
            } else {
                isHidden = true
            }
        }
    }
}

I call this a hack because I'm not a huge fan of modifying the existing behaviour of UIRefreshControl, but I haven't found a better way to get around this yet.

Issue 2

When pulling to refresh past that gap threshold in issue 1, it seems like the frame of the UIRefreshControl can't keep up with the search bar. This gives us another kind of gap that follows the search bar around. This is what it looks like:

Solution 2

This lagging gap looks like the frames aren't being updated as fast as our scrolling maybe even animated. Turns out that if we set the frame to itself in somewhere like layoutSubviews, we get the following behaviour:

override func layoutSubviews() {
    super.layoutSubviews()
    var originalFrame = frame
    frame = originalFrame
}

Again, this is pretty hacky, but I haven't found a different way to go about this either.

Result

这篇关于拖动时UIRefreshControl下面的白线.的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！