Open rph8 opened 2 years ago
mats-claassen
commented
2 years ago Hi, a quick try could be to remove row.baseCell.isUserInteractionEnabled = false from the row initializer and moving it to either cellSetup or cellUpdate. The cell should not be accessed in the row initializer because it will lead to the cell being instantiated at the wrong time.
rph8
commented
2 years ago Hey @mats-claassen, thanks for the idea. Unfortunately, that did not help. Simply moving that line into the update and not accessing row.baseCell from the row initializer did not solve issue. The exception-triggered crash persists as before.
Any other ideas?
rph8
commented
2 years ago @mats-claassen It seems that patching Row.swift regarding the updateCell either solves or at least masks the problem.
So if we change
override open func updateCell() {
super.updateCell()
cell.update()
customUpdateCell()
RowDefaults.cellUpdate["\(type(of: self))"]?(cell, self)
callbackCellUpdate?()
}into
override open func updateCell() {
super.updateCell()
DispatchQueue.main.async { [weak self] in
guard let self = self else { return }
self.cell.update()
self.customUpdateCell()
RowDefaults.cellUpdate["\(type(of: self))"]?(self.cell, self)
self.callbackCellUpdate?()
}
}So mainly moving the cellUpdate from a that function directly into a subsequent main loop run seems to do the trick. Do you know why? Should this be patched in Eureka?
rph8
commented
2 years ago Opened a pull request for the proposed fix: #2195
mats-claassen
commented
2 years ago I don't think this is a good way to fix an issue unless there is really no way to fix it from the user side. It seems weird that this is not something happening normally when using cellUpdate and I haven't seen any similar issue reported by someone else.
I also couldn't reproduce that crash. Some new comments regarding your code: Try setting textAreaMode to readOnly instead of setting userInteractionEnabled. You can also experiment with textAreaHeight instead of setting the height directly.
If that doesn't change anything then please make sure there is no other part of your code modifying the form while these updates happen.
tonklon
commented
4 months ago We saw the same issue with creating attributes strings inside the cellUpdate block.
We fixed it by creating a new row class for html strings and create the attributed string inside the update method.
Hope this helps someone:
open class HTMLTextCell: _TextAreaCell<String>, CellType {
public required init(style: UITableViewCell.CellStyle, reuseIdentifier: String?) {
super.init(style: style, reuseIdentifier: reuseIdentifier)
}
public required init?(coder aDecoder: NSCoder) {
super.init(coder: aDecoder)
}
override open func update() {
super.update()
if let htmlString = row.value {
let options: [NSAttributedString.DocumentReadingOptionKey: Any] = [
.documentType: NSAttributedString.DocumentType.html,
.characterEncoding: String.Encoding.utf8.rawValue,
]
let data = htmlString.data(using: .utf8)!
let attributedString = try? NSAttributedString(
data: data,
options: options,
documentAttributes: nil
)
textView.text = nil
textView.attributedText = attributedString
} else {
textView.text = nil
textView.attributedText = nil
}
}
}
open class _HTMLTextRow: AreaRow<HTMLTextCell> {
public required init(tag: String?) {
super.init(tag: tag)
}
}
public final class HTMLTextRow: _HTMLTextRow, RowType {
public required init(tag: String?) {
super.init(tag: tag)
}
}
Hi everyone,
I am using the latest Eureka and seem to run into internal inconsistency exceptions caused by a
.cellUpdate. It seems to be related to an issue described on Apple's forums: https://developer.apple.com/forums/thread/92132 (there is no solution documented there). Whenever I scroll the view, the internal inconsistency exception (see stack trace below) is raised, causing a crash. Without scrolling I can also sometimes see the exception in the log, but it somehow does not lead to a crash.Environment: Eureka 5.3.4, Xcode 13.1 and iOS 15.0.2
So my code looks roughly like this:
And here is the exception + stack trace that I get:
Any ideas why this leads to a crash?