stopwatch

Task 1, Task 2, and Nice-to-Have Task of Flutter take home test.

Screenshots

Portrait	Landscape

Exploring the code

I tagged stages of the test to ease inspection of Task 1 and Task 2 stages of completion. I followed the instructions to the letter up until task2, but to also provide good UX, I implemented changes to the UI in ux-enhancements, which contradict the task descriptions to an extent (has fewer buttons to clear confusion, doesn't allow pressing start after the stopwatch is started, only allows pausing, adding a lap, and the paused state allows restarting and resetting, which is how other stopwatch apps work).

Design decisions worth an explanation

The built-in Stopwatch class in Flutter doesn't allow for surviving process death with precise elapsed time preservation. Instead, I implemented PersistentStopwatch, which seemed more appropriate for a mobile application. This implementation uses a wall clock, so start time, elapsed time, and other required values can easily be persisted on change. On application restart, they can then be restored.

Cut corners

Compared to what was discussed on the interview, there are a couple of corners intentionally cut that I considered out of scope. I'm listing them here.

• Using the material widgets instead of introducing a design system for the sake of a stopwatch
• Navigation. The application has a single screen.

Manual test coverage

This application was tested as a Linux desktop app, and on Android using emulator and real devices.

AI usage disclaimer

AI was not used to create implementations of either production code or tests. OpenCode and OpenCode Zen were, however, used for debugging an async automated testing bug I had.