Fix UI jank from file reads and SQLite inserts using Isolates

WHAT THIS TESTS: This question evaluates whether you understand Dart's single-threaded event loop model and the critical distinction between asynchronous scheduling and true parallelism. The interviewer wants to see that you know why CPU-bound or blocking synchronous work on the UI isolate causes frame drops, and that you can correctly apply Dart's isolate-based concurrency to offload that work.

A GOOD ANSWER COVERS: First, the root cause: Dart code runs on isolates, each with its own memory heap and event loop. The Flutter UI runs on the main isolate. When you synchronously read a large file or execute thousands of SQLite inserts on that isolate, you monopolize the event loop and prevent the framework from rendering frames. At 60 frames per second, each frame has about 16 milliseconds to complete; blow that budget and you get jank. Second, the solution: move the heavy work to a worker isolate using compute or Isolate.run. Because isolates do not share memory, you pass the file path or raw bytes to the worker, perform the parsing and database operations there, and send back only the necessary result such as a success flag or a small list of IDs. Third, message passing mechanics: the worker isolate performs the work independently, and the result is transferred back to the UI isolate through a port, allowing the main event loop to stay responsive throughout.

COMMON WRONG ANSWERS: A major red flag is claiming that wrapping the operation in an async function or using Futures eliminates the jank. Async/await yields control between await points, but heavy synchronous computation between those points still blocks the event loop. Another red flag is treating isolates like threads in Java or Swift, expecting shared mutable state; Dart isolates are memory-isolated, so you must serialize data across the boundary. A third mistake is suggesting you should chunk the work into microtasks on the UI isolate; while slightly better, this still risks frame drops and is inferior to true parallel isolation for large batches.

LIKELY FOLLOW-UPS: The interviewer may ask how you pass large data to an isolate efficiently, prompting a discussion about typed data lists or TransferableTypedData to avoid copying overhead. They might also ask how you update the UI with progress, which leads to sending periodic messages back through a SendPort or using a Stream. Another follow-up is error handling: how do you catch exceptions in the worker isolate and propagate them to the UI isolate without crashing the app.

ONE CONCRETE EXAMPLE: Suppose a user imports a 50 megabyte CSV. On the UI isolate, you call compute(parseAndInsert, filePath) where parseAndInsert opens the file in the worker, parses rows, and batches inserts into a SQLite database opened within that same worker isolate. The function returns a count of inserted records. The UI isolate awaits the result, showing a loading spinner the entire time, and only rebuilds once with the final count. The main event loop never blocks, so animations and scrolling remain at 60 frames per second.