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

Implement flutter version of withLeakTracking that calls MemoryAllocations.instance.addListener #52

Closed
JulianBissekkou opened this issue Apr 24, 2023 · 3 comments · Fixed by #119

Comments

@JulianBissekkou
Copy link

To be able to catch flutter framework memory leaks we have to call MemoryAllocations.instance.addListener which does not happen in withLeakTracking.
I understand if withLeakTracking should be framework independent but then we should update the documentation 👍🏽

@polina-c
Copy link
Contributor

polina-c commented May 5, 2023

leak_tracker is a pure Dart library, while MemoryAllocations is a Flutter class.
withLeakTracking states in documentation that, if you use Flutter, the invocation should happen.

There should be separate method for Flutter to track Flutter leaks. While it is not implemented yet, you can create your own in your project.

@polina-c polina-c changed the title withLeakTracking does not call MemoryAllocations.instance.addListener Implement flutter version of withLeakTracking that calls MemoryAllocations.instance.addListener May 5, 2023
@polina-c
Copy link
Contributor

polina-c commented Aug 6, 2023

Discussion: flutter/devtools#3951 (comment)

The plan is to create leak_tracker_flutter in the same mono-repo, but publishing it out of the flutter.dev publisher. @devoncarew , are you still ok with this option? If yes, I will prepare PR to create this package and also address #78.

@devoncarew
Copy link
Member

For these three options:

package:leak_tracker_flutter published in tools.dart.dev, and banking on 'flutter' in the name being clarifying enough

I think we want to avoid having dart.dev published packages depending on the flutter sdk.

keeping leak_tracker_flutter in the same mono-repo, but publishing it out of the flutter.dev publisher

This one would be ok (publishing from flutter.dev but hosting the code in a dart-lang mono-repo). We just want to make sure that we don't take a dependency on this package from the dart-lang/sdk repo - this is a possibility as the leak_tracker repo is dep'd into the sdk.

putting the code in the flutter/packages mono-repo and using the flutter.dev publisher

I don't see any real downsides to this from a hygiene POV. It would mean that the leak tracker related code was spread across a few repos, which may not be desired.

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 a pull request may close this issue.

3 participants