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

Add the old way to dequeue cell without path #35

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

PoissonBallon
Copy link

No description provided.

@AliSoftware
Copy link
Owner

🤔 Isn't this method deprecated since iOS6-7?

If you want to add cells, even at the end of a tableView, the docs suggests to use the new method now iirc. You always have the indexPath anyway, as you're only supposed to call theses dequeue… method in the implementation of cellForRowAtIndexPath: which provides you the indexPath you need, so I don't even seen which cases you'd need that old and deprecated method?

Besides, if you use this old method, there's no guarantee that it won't return nil if there is no cell in the reuse pool to reuse — as opposed to the new method which instantiate that cell if there is none available to reuse. And if that old method returns nil you're then supposed to alloc/init the cell with the reuseIdentifier yourself, right?… for which Reusable don't propose a method either. and not supposed to crash…

@PoissonBallon
Copy link
Author

PoissonBallon commented Nov 21, 2016

Hey @AliSoftware and thx for your quick answer

For information, dequeueReusableCell(withIdentifier:) isn't deprecated (yet), and I agree with you it's better to use dequeueReusableCell(withIdentifier:for:)
https://developer.apple.com/reference/uikit/uitableview/1614891-dequeuereusablecell

And FYI my error it's same of this : newly visible row issue (Apple) && newly visible row issue (sf)

And the only one fix I found was the use of dequeueReusableCell(withIdentifier:)

I am totally open if you have any another option and keep Reusable usage 😄

@AliSoftware
Copy link
Owner

Problem is, that seems to be a bug to me and the aim of Reusable being to have more modern API it seems strange to me to introduce an old one especially if it's too use as a workaround and not a documented use… but I see your problem.

The fact that an empty recycle pool would make it crash that's not there right option anyway.

@PoissonBallon
Copy link
Author

PoissonBallon commented Nov 21, 2016

Ok, I see your pov but there is almost no difference between there iirc (one returns nil and the other crash if we have no register cell)
Anyway if you think we don't need this in Reusable you can close the PR 😄

Thanks for your return 👍

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