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

[FEATURE] Improve error handling of built-in image provider #1703

Closed
JaffaKetchup opened this issue Oct 23, 2023 · 4 comments · Fixed by #1742
Closed

[FEATURE] Improve error handling of built-in image provider #1703

JaffaKetchup opened this issue Oct 23, 2023 · 4 comments · Fixed by #1742
Labels
feature This issue requests a new feature P: 3 (low) (Default priority for feature requests)

Comments

@JaffaKetchup
Copy link
Member

JaffaKetchup commented Oct 23, 2023

What do you want implemented?

As discussed in #1698.

  • Reduce the number of errors that trigger breakpoints when debugging
  • Achieve an effect similar to what is seen in Flutter's NetworkImage

What other alternatives are available?

No response

Can you provide any other information?

The behaviour has changed in v6 from v5 due to changed error handling. In combination with using loadBytes instead of lower-level IO, this triggers more errors, but allows us to keep our code simple and platform independent.

It is also worth saying that the current implementation may not be performant in comparison to a standard NetworkImage, but more testing is need to validate this. See #1698 for an issue designated for reporting/tracking the performance of the tile provider.

Severity

Annoying: Currently have to use workarounds

@JaffaKetchup JaffaKetchup added feature This issue requests a new feature P: 3 (low) (Default priority for feature requests) labels Oct 23, 2023
@manlyman29
Copy link

I did tried the solution @robiness mentioned on the other issue. While it seems the breakpoint happens less, it still happens sometimes.

The users comment:

We also ran into this when migrating to V6.
Previously we had a static TileLayer, so only a single instant was used, leading into those Client already closed errors.
Making it a getter, or caching the HttpClient did solve the problem for us.

Another user mentioned this might be because of animated_map_controller. I can't test but worth mentioning maybe useful for someone else encoutering this.

@manlyman29
Copy link

This comment reduced encountering this:
#1698 (comment)

I have seen this being an issue in two cases:
1-Map moving immediately to another place while still loading.
2-In a responsive environment, we have a different instance of map for desktop and mobile. While resizing the screen, as soon as the breakpoint is reached, it goes into this error loop state.
This is from CancellableTileLayer, Same on NetworkTileLayer.
Screenshot 2023-11-17 at 10 55 47

@JaffaKetchup
Copy link
Member Author

Also see #1698 (comment).

@JaffaKetchup
Copy link
Member Author

Merging back into #1698, as the issues are closely related and the discussions are intertwined anyway.

@JaffaKetchup JaffaKetchup closed this as not planned Won't fix, can't repro, duplicate, stale Dec 1, 2023
Priority-ish Todo List automation moved this from To Do to Done Dec 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature This issue requests a new feature P: 3 (low) (Default priority for feature requests)
2 participants