Background tasks freeze up the whole UI

[teolemon]

What

• My phone has been freezing for 2 days for no clear reason
• I finally discovered this
• Background tasks freeze up the whole UI
• They behave in truly crazy ways

Proposed solution

• They should never freeze the UI
• They should be true background tasks (eg run when the app is closed)
• The wording on language refresh should be clarified (one product or the whole db)
• If I do several consecutive language switches, the previous should be cancelled (and similar behavior for more common use cases)

Screenshot/Mockup/Before-After

screen-20241125-164738.mp4

[monsieurtanuki]

Background tasks freeze up the whole UI

I think you're referring more specifically to massive downloads like language refresh.

They behave in truly crazy ways

No they don't. It's just that obviously we don't download the whole database in one shot: the servers wouldn't allow that many records (currently we download products with a standard "get products by barcode" query) and it's safer to split in case it crashes. Therefore, when a split background task ends, it calls the next split background task. Btw we're downloading from 4 servers now. The background task labels may not be explicit enough, I'll give you that.

They should never freeze the UI

They definitely shouldn't. They're not supposed to either. Worst case is when you have a very good connection: many background tasks being called rapidly in sequence.

They should be true background tasks (eg run when the app is closed)

Not that easy in flutter, probably using https://pub.dev/packages/workmanager, but that would demand many careful tests on android and on iOS. And different implementations on other platforms, if relevant.

The wording on language refresh should be clarified (one product or the whole db)

Fair enough.

If I do several consecutive language switches, the previous should be cancelled (and similar behavior for more common use cases)

Fair enough.

[teolemon]

The app keeps freezing whenever I change languages

[monsieurtanuki]

The app keeps freezing whenever I change languages

A solution would be to say: after all, changing languages shouldn't be treated lightly, and instead of expecting background tasks to deal with that "in the background", we'd rather create a specific page that does the whole work, with a progression indicator. That would take 10 minutes (to process, not to code) and that would be done.

[teolemon]

it's not about the speed, it is about the UI freezing. It seems to me that preventing this is one of the main purposes of isolates: https://docs.flutter.dev/perf/isolates

[monsieurtanuki]

it's not about the speed, it is about the UI freezing.

It's about something hidden in the background that prevents the foreground to work well.
Source: Psychoanalysis for dummies

It seems to me that preventing this is one of the main purposes of isolates: https://docs.flutter.dev/perf/isolates

We do use isolates in Smoothie, for a single case: image compression (i.e. for crops only).

Reading again the isolate docs, it looks like the only potential case where we'd need isolates for language refresh is when we decode the received json (the rest being data download and saving data into the database, and none of them are "intense computations").
But that remains highly unlikely, as for language refresh the batch size is 20 products: the json should be about 1Mb, which isn't that much.

My hunch is rather that something fails again and again in the language refresh.

So you'll take a step in my direction, and let me code a page where we actually track what the language refresh tasks do.
And I'll take a step in your direction, and test if isolates for decoding json would make sense.

[monsieurtanuki]

They should never freeze the UI

They definitely shouldn't. They're not supposed to either. Worst case is when you have a very good connection: many background tasks being called rapidly in sequence.

This is fixed now in #6038 (the database queries were slow and blocking, and too many queries were called in vain), and anyway even with a good connection we're limited by the number of requests to the server per minute, so the whole process cannot be "too fast".

The wording on language refresh should be clarified (one product or the whole db)

I've added the product type to the language refresh background task label.

If I do several consecutive language switches, the previous should be cancelled (and similar behavior for more common use cases)

It already works like that: each incremental action is "download the next 20 local products that don't have the current app language".