Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Made UIExpandingTableViewCell an optional protocol #35

Closed
wants to merge 1 commit into from
Closed

Made UIExpandingTableViewCell an optional protocol #35

wants to merge 1 commit into from

Conversation

afanslau
Copy link

as per issue #34. Documentation would still be nice
Thanks for creating this!

@OliverLetterer
Copy link
Owner

Thank you very much for this pull request. Always great to have people contributing back :) My time is very limited at the moment so I'm sorry for this and maybe future late responses. What I would like to discuss before merging this in is, if we should make all methods and properties of the UIExpandingTableViewCell protocol optional or if the protocol itself should be optional. The current approach allows a UITableViewCell to implement @property (nonatomic, readonly) UIExpansionStyle expansionStyle; while not implementing - (void)setExpansionStyle:(UIExpansionStyle)style animated:(BOOL)animated;. I'm not very comfortable with this inconsistent state.

What if instead we make the whole protocol optional. That is we make - (UITableViewCell<UIExpandingTableViewCell> *)tableView:(SLExpandableTableView *)tableView expandingCellForSection:(NSInteger)section return a plain UITableViewCell and document that it can optionally implement the whole UIExpandingTableViewCell protocol?

@afanslau
Copy link
Author

afanslau commented Jul 5, 2015

Hey Oliver, I think that would definitely be averted plan. I already added the responds to selector check for all the methods so it should only be a change of return type right? Or would we have to cast the cell every time?

Thanks for the response!

Adam

On Jul 5, 2015, at 6:13 AM, Oliver Letterer [email protected] wrote:

Thank you very much for this pull request. Always great to have people contributing back :) My time is very limited at the moment so I'm sorry for this and maybe future late responses. What I would like to discuss before merging this in is, if we should make all methods and properties of the UIExpandingTableViewCell protocol optional or if the protocol itself should be optional. The current approach allows a UITableViewCell to implement @Property (nonatomic, readonly) UIExpansionStyle expansionStyle; while not implementing - (void)setExpansionStyle:(UIExpansionStyle)style animated:(BOOL)animated;. I'm not very comfortable with this inconsistent state.

What if instead we make the whole protocol optional. That is we make - (UITableViewCell *)tableView:(SLExpandableTableView *)tableView expandingCellForSection:(NSInteger)section return a plain UITableViewCell and document that it can optionally implement the whole UIExpandingTableViewCell protocol?


Reply to this email directly or view it on GitHub.

@OliverLetterer
Copy link
Owner

If think is it more futureproofed if if we don't check each selector but rather if the -[cell conformsToProtocol:].

@afanslau
Copy link
Author

afanslau commented Jul 6, 2015

Agreed, so I'll switch to using conformsToProtocol, change the return type
to plain UITableViewCell objects and remove the optional status of the
protocol methods. I'll do it when I get off work :). Then I'll submit
another pull request. Thanks again for a great library

Best,
Adam

On Mon, Jul 6, 2015 at 11:19 AM, Oliver Letterer [email protected]
wrote:

If think is it more futureproofed if if we don't check each selector but
rather if the -[cell conformsToProtocol:].


Reply to this email directly or view it on GitHub
#35 (comment)
.

@OliverLetterer
Copy link
Owner

Sound awesome. Thank you very much. Really, always great to have people contributing back 👍🎉😃

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants