Callback / Event when Widget is rendered

[michel...@gmail.com]

Hello

I try to create a "in progress" dialog. Now in my use case i generate a RSA which will result in a "short" but high CPU usage. As result, the key get generated before the dialog is rendered. I tried with the SchedulerBinding, but there is no information about the underlaying widget. My current solution is a timer, but it's a little bit ugly ;-) Is there a better way to solve this async problem?

Thanks in advance

Regards

Michel

[Adam Barth]

A timer seems like a reasonable solution.  You can also use scheduleMicrotask if you want the task to run immediately after we're done flushing the rendering pipeline.

Adam

--
You received this message because you are subscribed to the Google Groups "Flutter Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flutter-dev...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ian Hickson]

The right answer is to do the key generation in another isolate so that it doesn't block the UI.

[Michel Werren]

Thanks for your hints! To generate the keys in another isolate brings a solution, but only with multi CPU. With single CPU the behavior still exists.

But in my opinion an optionally callback for example on the State / Statelesswidget when the Widget rendering is done would be nice anyway.

In my case i differentiate between the first start and all they come afterwards. My plan is to navigate to the root Widget (home) on startup and evaluate if its the first start within "home". In both cases a further navigation should be done then to the login or another workflow. The reason for this is, that in this way the home is anytime the root in the tree, so i can call Navigator.pop / popUntil until i'm back on home.

I hope i dont misunderstanding the "flutter way" :-) , because i like really like Flutter and Dart anyway.

Regards

[Ian Hickson]

Regarding login screens, yeah, we need to improve the APIs around that. I expect us to do something in Q1 next year to address that.

In general if you want make sure you've painted the current state to the screen before doing something that takes a long time, trigger the work in a post frame callback (see the SchedulerBinding API for the method to register a post frame callback). Then when you're done, call setState. However, this will cause all animations (e.g. Material ink splashes) to stall while the work is happening. Isolates are in multiple threads so even if there's only one core, you will still allow the animations to continue as the threads are going to be preemptively multitasked.

[Michel Werren]

Thanks a lot, that was i looking for. I think missed to try this callback before.

Regards

To unsubscribe from this group and stop receiving emails from it, send an email to flutter-dev+unsubscribe@googlegroups.com.