Flutter - Will BLoC stream instances cause memory leak when a widget is closed?
up vote
2
down vote
favorite
There are some scenarios where screens with their respective BLoCs are frequently created and closed. So I'm somewhat concerned about memory safety of the Streams instances created in this process, because it doesn't seem they are disposed somewhere or whether they are GC-ed. This clearly depends on the specific implementation of DART libraries and flutter. So if you know about their behavior, please let me know.
These are some scenarios I have encountered.
- Multi-tab browser-like application.
- Navigation through screens. (But it's not that harmful.)
- showDialog() senarios when there are BLoCs inside the dialog. This is a far more common senario. There could be a lot of dialog popping up frequently in an app.
I wonder if it is necessary to override dispose() function and explicitly close all streams in BLoCProvider. It seems existing tutorials didn't mention it.
dart 
flutter rxdart asked Nov 20 at 10:54
First_Strike
958
add a comment |
up vote
2
down vote
favorite
There are some scenarios where screens with their respective BLoCs are frequently created and closed. So I'm somewhat concerned about memory safety of the Streams instances created in this process, because it doesn't seem they are disposed somewhere or whether they are GC-ed. This clearly depends on the specific implementation of DART libraries and flutter. So if you know about their behavior, please let me know.
These are some scenarios I have encountered.
- Multi-tab browser-like application.
- Navigation through screens. (But it's not that harmful.)
- showDialog() senarios when there are BLoCs inside the dialog. This is a far more common senario. There could be a lot of dialog popping up frequently in an app.
I wonder if it is necessary to override dispose() function and explicitly close all streams in BLoCProvider. It seems existing tutorials didn't mention it.
dart flutter rxdart asked Nov 20 at 10:54
First_Strike
958
add a comment |
up vote
2
down vote
favorite
up vote
2
down vote
favorite
There are some scenarios where screens with their respective BLoCs are frequently created and closed. So I'm somewhat concerned about memory safety of the Streams instances created in this process, because it doesn't seem they are disposed somewhere or whether they are GC-ed. This clearly depends on the specific implementation of DART libraries and flutter. So if you know about their behavior, please let me know.
These are some scenarios I have encountered.
- Multi-tab browser-like application.
- Navigation through screens. (But it's not that harmful.)
- showDialog() senarios when there are BLoCs inside the dialog. This is a far more common senario. There could be a lot of dialog popping up frequently in an app.
I wonder if it is necessary to override dispose() function and explicitly close all streams in BLoCProvider. It seems existing tutorials didn't mention it.
dart flutter rxdart asked Nov 20 at 10:54
First_Strike
958
There are some scenarios where screens with their respective BLoCs are frequently created and closed. So I'm somewhat concerned about memory safety of the Streams instances created in this process, because it doesn't seem they are disposed somewhere or whether they are GC-ed. This clearly depends on the specific implementation of DART libraries and flutter. So if you know about their behavior, please let me know.
These are some scenarios I have encountered.
- Multi-tab browser-like application.
- Navigation through screens. (But it's not that harmful.)
- showDialog() senarios when there are BLoCs inside the dialog. This is a far more common senario. There could be a lot of dialog popping up frequently in an app.
I wonder if it is necessary to override dispose() function and explicitly close all streams in BLoCProvider. It seems existing tutorials didn't mention it.
dart flutter rxdart dart flutter rxdart asked Nov 20 at 10:54
First_Strike
958
asked Nov 20 at 10:54
First_Strike
958
asked Nov 20 at 10:54
First_Strike
958
asked Nov 20 at 10:54
First_Strike
958
asked Nov 20 at 10:54
First_Strike
958
958
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
2
down vote
accepted
Streams will properly be cleaned as long as they aren't used anymore.
The thing is, to simply removing the variable isn't enough to unsure it's unused. It could still run in background.
You need to call Sink.close() so that it stops the associated StreamController, to ensure resources can later be freed by the GC.
To do that, you have to use StatefulWidget.dispose method:
abstract class MyBloc {
Sink foo;
Sink bar;
}
class MyWiget extends StatefulWidget {
@override
_MyWigetState createState() => _MyWigetState();
}
class _MyWigetState extends State<MyWiget> {
MyBloc bloc;
@override
void dispose() {
bloc.bar.close();
bloc.foo.close();
super.dispose();
}
@override
Widget build(BuildContext context) {
// ...
}
}
answered Nov 20 at 11:03
Rémi Rousselet
22.9k24078
Do you think it's always better to use access a bloc via an interface than using a provider which effectively uses an inherited widget?
– stt106
Nov 20 at 11:10
@stt106 What do you mean? An interface doesn't replace the provider, nor does the provider replace the interface
– Rémi Rousselet
Nov 20 at 11:13
will chat to you on slack.
– stt106
Nov 20 at 11:14
Oh, thanks. So it seems we need to close the Streams in the dispose() function. But there are some other problems with this solution. InheritedWidget has their own lifecycle. I'm not so sure about this, but is it likely that either user or flutter engine triggers an unintended disposal of InheritedWidget? Because I've seen in some tutorials that BLoCs becomes shared and InheritedWidget are created and re-assigned everywhere.
– First_Strike
Nov 20 at 11:57
You need both an Inheritedwidget and a StatefulWidget
– Rémi Rousselet
Nov 20 at 12:05
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53391431%2fflutter-will-bloc-stream-instances-cause-memory-leak-when-a-widget-is-closed%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
Streams will properly be cleaned as long as they aren't used anymore.
The thing is, to simply removing the variable isn't enough to unsure it's unused. It could still run in background.
You need to call Sink.close() so that it stops the associated StreamController, to ensure resources can later be freed by the GC.
To do that, you have to use StatefulWidget.dispose method:
abstract class MyBloc {
Sink foo;
Sink bar;
}
class MyWiget extends StatefulWidget {
@override
_MyWigetState createState() => _MyWigetState();
}
class _MyWigetState extends State<MyWiget> {
MyBloc bloc;
@override
void dispose() {
bloc.bar.close();
bloc.foo.close();
super.dispose();
}
@override
Widget build(BuildContext context) {
// ...
}
}
answered Nov 20 at 11:03
Rémi Rousselet
22.9k24078
Do you think it's always better to use access a bloc via an interface than using a provider which effectively uses an inherited widget?
– stt106
Nov 20 at 11:10
@stt106 What do you mean? An interface doesn't replace the provider, nor does the provider replace the interface
– Rémi Rousselet
Nov 20 at 11:13
will chat to you on slack.
– stt106
Nov 20 at 11:14
Oh, thanks. So it seems we need to close the Streams in the dispose() function. But there are some other problems with this solution. InheritedWidget has their own lifecycle. I'm not so sure about this, but is it likely that either user or flutter engine triggers an unintended disposal of InheritedWidget? Because I've seen in some tutorials that BLoCs becomes shared and InheritedWidget are created and re-assigned everywhere.
– First_Strike
Nov 20 at 11:57
You need both an Inheritedwidget and a StatefulWidget
– Rémi Rousselet
Nov 20 at 12:05
add a comment |
up vote
2
down vote
accepted
Streams will properly be cleaned as long as they aren't used anymore.
The thing is, to simply removing the variable isn't enough to unsure it's unused. It could still run in background.
You need to call Sink.close() so that it stops the associated StreamController, to ensure resources can later be freed by the GC.
To do that, you have to use StatefulWidget.dispose method:
abstract class MyBloc {
Sink foo;
Sink bar;
}
class MyWiget extends StatefulWidget {
@override
_MyWigetState createState() => _MyWigetState();
}
class _MyWigetState extends State<MyWiget> {
MyBloc bloc;
@override
void dispose() {
bloc.bar.close();
bloc.foo.close();
super.dispose();
}
@override
Widget build(BuildContext context) {
// ...
}
}
answered Nov 20 at 11:03
Rémi Rousselet
22.9k24078
Do you think it's always better to use access a bloc via an interface than using a provider which effectively uses an inherited widget?
– stt106
Nov 20 at 11:10
@stt106 What do you mean? An interface doesn't replace the provider, nor does the provider replace the interface
– Rémi Rousselet
Nov 20 at 11:13
will chat to you on slack.
– stt106
Nov 20 at 11:14
Oh, thanks. So it seems we need to close the Streams in the dispose() function. But there are some other problems with this solution. InheritedWidget has their own lifecycle. I'm not so sure about this, but is it likely that either user or flutter engine triggers an unintended disposal of InheritedWidget? Because I've seen in some tutorials that BLoCs becomes shared and InheritedWidget are created and re-assigned everywhere.
– First_Strike
Nov 20 at 11:57
You need both an Inheritedwidget and a StatefulWidget
– Rémi Rousselet
Nov 20 at 12:05
add a comment |
up vote
2
down vote
accepted
up vote
2
down vote
accepted
Streams will properly be cleaned as long as they aren't used anymore.
The thing is, to simply removing the variable isn't enough to unsure it's unused. It could still run in background.
You need to call Sink.close() so that it stops the associated StreamController, to ensure resources can later be freed by the GC.
To do that, you have to use StatefulWidget.dispose method:
abstract class MyBloc {
Sink foo;
Sink bar;
}
class MyWiget extends StatefulWidget {
@override
_MyWigetState createState() => _MyWigetState();
}
class _MyWigetState extends State<MyWiget> {
MyBloc bloc;
@override
void dispose() {
bloc.bar.close();
bloc.foo.close();
super.dispose();
}
@override
Widget build(BuildContext context) {
// ...
}
}
answered Nov 20 at 11:03
Rémi Rousselet
22.9k24078
Streams will properly be cleaned as long as they aren't used anymore.
The thing is, to simply removing the variable isn't enough to unsure it's unused. It could still run in background.
You need to call Sink.close() so that it stops the associated StreamController, to ensure resources can later be freed by the GC.
To do that, you have to use StatefulWidget.dispose method:
abstract class MyBloc {
Sink foo;
Sink bar;
}
class MyWiget extends StatefulWidget {
@override
_MyWigetState createState() => _MyWigetState();
}
class _MyWigetState extends State<MyWiget> {
MyBloc bloc;
@override
void dispose() {
bloc.bar.close();
bloc.foo.close();
super.dispose();
}
@override
Widget build(BuildContext context) {
// ...
}
}
answered Nov 20 at 11:03
Rémi Rousselet
22.9k24078
answered Nov 20 at 11:03
Rémi Rousselet
22.9k24078
answered Nov 20 at 11:03
Rémi Rousselet
22.9k24078
answered Nov 20 at 11:03
Rémi Rousselet
22.9k24078
22.9k24078
Do you think it's always better to use access a bloc via an interface than using a provider which effectively uses an inherited widget?
– stt106
Nov 20 at 11:10
@stt106 What do you mean? An interface doesn't replace the provider, nor does the provider replace the interface
– Rémi Rousselet
Nov 20 at 11:13
will chat to you on slack.
– stt106
Nov 20 at 11:14
Oh, thanks. So it seems we need to close the Streams in the dispose() function. But there are some other problems with this solution. InheritedWidget has their own lifecycle. I'm not so sure about this, but is it likely that either user or flutter engine triggers an unintended disposal of InheritedWidget? Because I've seen in some tutorials that BLoCs becomes shared and InheritedWidget are created and re-assigned everywhere.
– First_Strike
Nov 20 at 11:57
You need both an Inheritedwidget and a StatefulWidget
– Rémi Rousselet
Nov 20 at 12:05
add a comment |
Do you think it's always better to use access a bloc via an interface than using a provider which effectively uses an inherited widget?
– stt106
Nov 20 at 11:10
@stt106 What do you mean? An interface doesn't replace the provider, nor does the provider replace the interface
– Rémi Rousselet
Nov 20 at 11:13
will chat to you on slack.
– stt106
Nov 20 at 11:14
Oh, thanks. So it seems we need to close the Streams in the dispose() function. But there are some other problems with this solution. InheritedWidget has their own lifecycle. I'm not so sure about this, but is it likely that either user or flutter engine triggers an unintended disposal of InheritedWidget? Because I've seen in some tutorials that BLoCs becomes shared and InheritedWidget are created and re-assigned everywhere.
– First_Strike
Nov 20 at 11:57
You need both an Inheritedwidget and a StatefulWidget
– Rémi Rousselet
Nov 20 at 12:05
Do you think it's always better to use access a bloc via an interface than using a provider which effectively uses an inherited widget?
– stt106
Nov 20 at 11:10
Do you think it's always better to use access a bloc via an interface than using a provider which effectively uses an inherited widget?
– stt106
Nov 20 at 11:10
@stt106 What do you mean? An interface doesn't replace the provider, nor does the provider replace the interface
– Rémi Rousselet
Nov 20 at 11:13
@stt106 What do you mean? An interface doesn't replace the provider, nor does the provider replace the interface
– Rémi Rousselet
Nov 20 at 11:13
will chat to you on slack.
– stt106
Nov 20 at 11:14
will chat to you on slack.
– stt106
Nov 20 at 11:14
Oh, thanks. So it seems we need to close the Streams in the dispose() function. But there are some other problems with this solution. InheritedWidget has their own lifecycle. I'm not so sure about this, but is it likely that either user or flutter engine triggers an unintended disposal of InheritedWidget? Because I've seen in some tutorials that BLoCs becomes shared and InheritedWidget are created and re-assigned everywhere.
– First_Strike
Nov 20 at 11:57
Oh, thanks. So it seems we need to close the Streams in the dispose() function. But there are some other problems with this solution. InheritedWidget has their own lifecycle. I'm not so sure about this, but is it likely that either user or flutter engine triggers an unintended disposal of InheritedWidget? Because I've seen in some tutorials that BLoCs becomes shared and InheritedWidget are created and re-assigned everywhere.
– First_Strike
Nov 20 at 11:57
You need both an Inheritedwidget and a StatefulWidget
– Rémi Rousselet
Nov 20 at 12:05
You need both an Inheritedwidget and a StatefulWidget
– Rémi Rousselet
Nov 20 at 12:05
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53391431%2fflutter-will-bloc-stream-instances-cause-memory-leak-when-a-widget-is-closed%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
