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

Crash with 2.2.6/Core #104

Closed
keith opened this issue Mar 10, 2017 · 7 comments
Closed

Crash with 2.2.6/Core #104

keith opened this issue Mar 10, 2017 · 7 comments

Comments

@keith
Copy link

keith commented Mar 10, 2017

We've just upgraded to the Core subspec with 2.2.6 and started seeing this crash:

image

The Core SDK doesn't require SDWebImage at all, so it probably shouldn't be calling any APIs from it.

@Wenzhi
Copy link

Wenzhi commented Mar 10, 2017

@keith,

Thanks for letting us know about the crash! In our code, we try to detectSDWebImageManager class's existence before continuing the image download process. Do you integrate a different version of SDWebImage framework, or you don't use SDWebImage in your app at all?

Thanks,
Wenzhi

@keith
Copy link
Author

keith commented Mar 10, 2017

We do have it right now yes. But this seems extremely risky since when you're doing that there's no way you can verify that we have a version you're compatible with. Meaning the possibility of this crash will always exist.

@Wenzhi
Copy link

Wenzhi commented Mar 10, 2017

Hi @keith,

I'm adding handling to all SDWebImage related code which will fix the crash. We are also going to work on more robust modularization so that we can ensure to handle this scenario more gracefully. The new version should be released on Monday. We will let you know as soon as we release it. Thanks very much for reporting and please let us know if you have any further questions/comments.

Thanks,
Wenzhi

@keith
Copy link
Author

keith commented Mar 10, 2017

Can you just remove the calls to SDWebImage all together, or add SDWebImage to your required dependencies? It feels extremely fragile to just add more respondsToSelector checks. That could even fail if the method signature changed between versions.

@briancaw
Copy link
Contributor

Hi @keith

Thanks again for reporting this. We plan to release on Monday with code that ensures things won't crash in the Core flavor if any required SDWebImage method signature is missing.

We plan to release again later in the week with an update that separates out SDWebImage access into the UI subspec. Please let us know if that timeline doesn't work for you.

Thanks,
Brian

@Wenzhi
Copy link

Wenzhi commented Mar 28, 2017

Hey @keith,

SDK Version 2.28.0 moved all the calls to SDWebImage into an ABKSDWebImageProxy class that exists only in the UI subspec. Please let us know if you have any questions/comments and if this resolves the issue.

Thanks very much for helping improve our SDK!
Wenzhi

@keith
Copy link
Author

keith commented Apr 10, 2017

This is probably solved now, so closing.

@keith keith closed this as completed Apr 10, 2017
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

No branches or pull requests

3 participants