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

KFImage does not being displayed in some cases after 6.2.1 #1660

Closed
ramluro1 opened this issue Mar 13, 2021 · 13 comments
Closed

KFImage does not being displayed in some cases after 6.2.1 #1660

ramluro1 opened this issue Mar 13, 2021 · 13 comments

Comments

@ramluro1
Copy link

Issue Description

Images not being displayed after pod update to 6.2.1. in SwiftUI app

What

Works fine after I reverted back to 6.1.1

Reproduce

[The steps to reproduce this issue. What is the url you were trying to load, where did you put your code, etc.]

Other Comment

[Add anything else here]

@onevcat
Copy link
Owner

onevcat commented Mar 14, 2021

Hi,

Maybe you can try to call loadImmediately() after you set up the KFImage to see if it works. Like this:

KFImage.url(url)
    .resizable()
    .onSuccess { r in print("done") }
    .loadImmediately() // Add this after the last chained call for `KFImage`
    .frame(height: 100) // Other `SwiftUI.View` modifiers

In 6.1, we tried a new implementation which "keeps" the image state between KFImage creation, but it caused other problems. So we are now back to the implementation of 6.0. The root cause is that @ObservedObject does not keep itself between views lifetime. @StateObject in iOS 14 is the tool to solve it. However, since we still need to support iOS 13, we cannot use that yet.

loadImmediately() will trigger a load as soon as you configured the KFImage, instead of lazily load it until onAppear is called (which will never happen sometimes when you change something and trigger a re-evaluating of body).

@ivasic
Copy link

ivasic commented Mar 15, 2021

Not the OP but I have the exact same problem and indeed, adding loadImmediately() fixes it.

@onevcat is this the recommended usage or just a temporary workaround?

@onevcat
Copy link
Owner

onevcat commented Mar 15, 2021

It is the recommended usage until we can drop iOS 13 support (Maybe later this year when iOS 15 comes out!)

@netbe
Copy link

netbe commented Apr 6, 2021

@onevcat Do you plan to do an availability check to use StateObject ? or at least add a warning on Readme ?

@onevcat
Copy link
Owner

onevcat commented Apr 7, 2021

@netbe It is hard to choose it with an availability check, which does not support a type member. The plan is switching to @StateObject when the new version of iOS 15 announced (WWDC). So we can try to adapt to some new features and drop iOS 13.

@onevcat onevcat changed the title Images not being displayed after pod update to 6.2.1. KFImage does not being displayed in some cases after pod update to 6.2.1 Apr 20, 2021
@onevcat onevcat pinned this issue Apr 20, 2021
@wilg
Copy link

wilg commented May 11, 2021

We are encountering this as well, it feels pretty broken. Maybe .loadImmediately() should be the default?

@onevcat
Copy link
Owner

onevcat commented May 12, 2021

@wilg It once was, but in a recent syntax improvement for a chain-able configuration, there is no way to call it unexplicitly. Furthermore, an image loading every time when the layout changed is also not a desired behavior.

A patch for switching to @StateObject is already in #1707 and the feature/StateObject branch. If you only use SwiftUI for iOS 14, it worths to try and keep using that until the next major release of Kingfisher.

@onevcat onevcat changed the title KFImage does not being displayed in some cases after pod update to 6.2.1 KFImage does not being displayed in some cases after 6.2.1 May 12, 2021
@wilg
Copy link

wilg commented May 12, 2021

OK, I'll try that. I guess my thinking is that this is such a serious bug that Kingfisher is essentially unusable in SwiftUI without it, so it might be worth doing something drastic.

It took us a long time to figure out that this was a Kingfisher issue, and we shipped some bad releases until we figured it out today.

@onevcat
Copy link
Owner

onevcat commented May 14, 2021

@wilg Oh! I am very sorry to hear that.

I really hope we can solve it by dropping the broken @ObservedObject soon!

@onevcat
Copy link
Owner

onevcat commented Jun 12, 2021

The @StateObject based image binder is now in master. It requires the deploy target upgrade to iOS 14. I am going to prepare a release for it soon.

@onevcat
Copy link
Owner

onevcat commented Aug 6, 2021

This is already fixed in version 7 (currently in beta). The loadImmediately() is not necessary anymore in the new release (but the method itself will be left there for a while without doing anything, for backward compatibility). The new major upgrade version Kingfisher 7 requires iOS 14 for using KFImage. Please remember to check the migration guide before you decide an upgrade.

There are still some other features in plan & waiting fixes from Apple's Xcode 13 betas. Kingfisher v7 won't be officially released before there is a GM version of new iOS 15 and Xcode 13.

@onevcat onevcat unpinned this issue Dec 8, 2021
@onevcat onevcat closed this as completed Dec 8, 2021
@Anton-Trubianov
Copy link

Anton-Trubianov commented Apr 13, 2023

I still facing the same issue KF v7, i roll back to v6.3.1 and added loadImmediately only this setup fixing issue in 99%, in my app is list with paging that loads data async way 20 item per page, and even this setup some but occurs but not often 1-5% if scrolling is fast, wifi or LTE it doesn't matter.
IOS 16.2
Xcode Version 14.2 (14C18)
SwiftUI
Using KF with SPM

@onevcat
Copy link
Owner

onevcat commented Apr 14, 2023

For issues with iOS 16 (before iOS 16.4), I believe it was another issue mentioned in #1988

Please check there for the detail and some possible workaround. This issue should not happen when building with Xcode 14.3 and for deploy targets later than iOS 16.4.

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

6 participants