0

I have a navbar, change between 2 screens nested with Provider create blocs. Whenever bloc constructor called. It's call api to get data and add to the stream. So the problem here, user can spam switch between 2 screens and make the bloc dispose and init => api was called multiple times.

Class Bloc1 {
  const Bloc1(){
    data = await fetch() //Call api
    stream1.add(data) //Then add to stream
 }
}

I have tried the lock. But it does not work because when recreate, the lock is recreate too -> useless.

Class Bloc1{
 var lock = false;
 const Bloc1(){
   if(lock == false) {
     data = await fetch() //Call api
     stream1.add(data) //Then add to stream
   }
 }
}
blackmouse572
  • 19
  • 5
  • Your question is a bit vague but your function declarations inside the classes need to be `async` if you use `await`. Then you could await `Block()` in your application and only proceed once the API call is finished. Could that be a solution? – Flo Ragossnig Nov 01 '22 at 14:04
  • The sample above is not quite accurate. It can have an async init function to await all fetch then add to stream sequency. Besides that, if user move to another screen, the bloc will be disposed and shut down the init func. – blackmouse572 Nov 01 '22 at 16:47

1 Answers1

0

In my opinion, the issue you are mentioning is a kind of a border case where the user will have an aggressive behavior with the switch.

That being said, I think you should clarify a few points:

  • Do you really want to change the switch behavior to avoid this scenario?
  • Does it make sense to fetch new data every time the user switches tabs? I mean, does the data change that often? Because if the data does not change, maybe it does not makes sense to make a new request to the API at that point, and you should consider fetching this data at some other point.

I think there is no way to avoid this scenario if you instantiate/dispose your bloc every time the user switches screens (unless you save the lock or previously retrieved data outside the bloc, so next time you instantiate this bloc you can provide this value via the constructor, and this way you can avoid making the API request).

Depending on your Bloc logic, a solution could be that you instantiate the Bloc above these two screens, by doing this the Bloc will not be disposed once you switch screens and therefore it won't be instantiated again. Take into account that this approach will make the Bloc to be alive no matter how many times the user switches screens, and it is possible that this is something that you want to avoid.

Fabián Bardecio
  • 265
  • 1
  • 7
  • With normal user, this problem is not a big concern. However, if there is a hacker who want to fluid the request by spamming switch, this will be a big problem. With each screen, it have its own bloc to manage state. Move it up could be a solution but it might break down the architecture ~~ – blackmouse572 Nov 01 '22 at 16:42
  • In most cases, moving both blocs up in the widget tree should not be a problem (of course whenever possible we want to avoid having blocs up in the widget tree), since you are only instantiating them before accessing every screen. But if the screen's behavior does not change, every screen will be communicating with its own bloc. The only main and important change is the lifecycle of the blocs, which will be alive and won't be disposed every time you change your screen. – Fabián Bardecio Nov 01 '22 at 17:54