Realtime Transit Board

Project roadmap

1. 01

   Define the feed and the app

   ~2h

   Choose a live data source: a real transit API with realtime arrivals (many cities publish one), or your own small mock server (for example in Dart with shelf) that sends arrivals for a few stops and can simulate delays and outages. Write README.md describing the data (stop, line, destination, expected and scheduled time) and the rules: when data counts as stale (for example after 60 seconds) and how reconnecting works. Done when: README.md describes the feed, and the data source works.

2. 02

   Build the live data client

   ~2.5h

   Write an ArrivalsClient that exposes a Dart Stream of arrival lists for a stop, by polling every 15 seconds or listening on a WebSocket. Parse the data into typed classes, ignore duplicate or out-of-date updates, and report errors on the stream without closing it. Done when: listening to the stream prints updated arrivals for a stop.

3. 03

   Reconnect automatically

   ~2h

   When a request fails or the connection drops, retry after 1, 2, 4 and up to 30 seconds, resetting after success. Pause updates when the app goes to the background and resume when it comes back, using the app lifecycle. Expose the connection state (live, reconnecting, offline). Done when: stopping and restarting the data source makes the app reconnect by itself.

4. 04

   Cache boards with Drift

   ~2h

   Create a Drift database with favorite stops and the last received arrivals per stop with the time they were received. Save each update, and show the cached board immediately when the app opens, before live data arrives. Done when: in airplane mode, the app shows the last known board for each favorite stop.

5. 05

   Build the boards with Riverpod

   ~2.5h

   Create Riverpod providers for the client, the database and a board per stop that combines live and cached data. Build a favorites screen and a board screen listing arrivals with the line, destination, minutes until arrival (updated every few seconds) and delay in red. Show a banner with the connection state, and dim the board when data is stale. Done when: boards update live, and stale data is clearly marked.

6. 06

   Handle edge cases

   ~1.5h

   Handle arrivals that have already departed (remove them), a stop with no arrivals, times across midnight, and a feed returning broken data (keep the last good board and log the error). Let users add and remove favorite stops. Done when: none of these cases shows wrong times or crashes the app.

7. 07

   Test it

   ~2h

   Write tests with a fake client and a controllable clock (for example package:fake_async): reconnect waits grow and reset, data becomes stale after the limit, departed arrivals are removed, and the cache is used when offline. Add a widget test for the stale banner. Done when: flutter test passes.

Resources

• DocsDart: asynchronous programming with streams
• DocsRiverpod documentation
• DocsDrift documentation
• Docsfake_async package
• DocsGTFS Realtime overview