Can I advantage of Swift availability features in a UITableVIewDelegate?


Rick Aurbach
 

I am working on an app which I would like to support 10.x for the next release. The problem I have is in a UITableViewDelegate:
I have two actions which I'd like to implement for cells. In 10.x, I have to implement tableView(_:editActionsForRowAt:) and both action buttons show up on the same side of the cell. But in 11+, I can use tableView(_:leadingSwipeActionsConfigurationForRowAt:) and tableView(_:trailingSwipeActionsConfigurationForRowAt:) and the two action buttons on opposite sides of the cell.

I don't understand how to use @availabiltiy and/or #availability to implement the above requirement when I am implementing optional protocol functions. (I think I understand what to do when the conditional code is mine, but I'm not sure how this applies to implementation of optional protocol functions in system-defined protocols.)

Can you help?? Thanks,

Rick


Bernie Maier
 

Rick Aurbach:

I don't understand how to use @availabiltiy and/or #availability to
implement the above requirement when I am implementing optional protocol
functions. (I think I understand what to do when the conditional code is
mine, but I'm not sure how this applies to implementation of optional
protocol functions in system-defined protocols.)
If I understand you correctly, you are asking whether you can wrap entire function implementations inside availability guards, vs just a section of code within a function.

I suspect you don't need to do that in the case you describe. Just implement both sets of delegate functions. When you compile against the iOS 11 SDK, everything will compile fine. The new delegate methods won't be called in iOS 10.x. You may need to "availability wrap" the code inside the implementation of tableView(_:editActionsForRowAt:) so that when the app is running under iOS 11+, both sets of delegate methods don't compete with each other.

Bernie


Rick Aurbach
 

I suspect you don't need to do that in the case you describe. Just implement both sets of delegate functions. When you compile against the iOS 11 SDK, everything will compile fine. The new delegate methods won't be called in iOS 10.x. You may need to "availability wrap" the code inside the implementation of tableView(_:editActionsForRowAt:) so that when the app is running under iOS 11+, both sets of delegate methods don't compete with each other.
Thank you, Bernie; you're absolutely right.

All that is actually needed is to implement tableView(_:editActionsForRowAt:) and tableView(_:trailingSwipeActionsConfigurationForRowAt:) [and the corresponding leading-edge function if needed]. The swipe-action functions need to annotated with @available(iOS 11, *) to prevent compiler issues.

Then, when running 10.3, the Swipe-action functions are ignored (as we expect). What I am pleased to report (and didn't expect -- hence the original question--) was that in iOS 11.x, if the Swipe-action functions are present, the editActions API is not called, so there no conflicts to worry about.

As usual, I am guilty of too much worrying and not enough trying.

Thanks again,

Rick Aurbach