Wembley Park Trains Roadmap

A simple Expo app showing the next southbound Jubilee and Metropolitan line trains from Wembley Park Underground Station.

This roadmap is the overall project backlog. Items can be promoted into individual GitHub Issues as they become ready to work on.

Project setup

Create the Expo project
Set up the initial Expo and React Native app, then confirm that the default project runs successfully.
Create the GitHub repository
Add the project to GitHub, invite both developers and confirm that each person can clone and update the repository.
Add project documentation
Create a basic README explaining what the app does, how to install dependencies and how to run it through Expo.
Define the branch and pull request workflow
Agree on branch naming, commit messages, code review and the rule that substantial changes should reach main through pull requests.
Protect secrets and local configuration
Ensure TfL API keys and other private values are excluded from GitHub using .env, .gitignore and .env.example.

Create the TfL API exploration requests
Store the working REST Client requests in the repository so both developers can inspect TfL responses.
Document the Wembley Park data findings
Record the station ID, line IDs, relevant platform numbers and any unusual or unreliable fields found in the API.
Define the app's internal departure format
Design a small data structure containing only the fields the app needs, such as line, destination, platform and expected arrival.
Create mock departure data
Add sample Jubilee and Metropolitan departures so the interface can be developed without depending on the live API.

Build the basic Wembley Park screen
Create the main app screen with a station heading and separate areas for Jubilee and Metropolitan departures.
Create a reusable departure row
Build a component that displays a train's destination, platform and time until arrival.
Add TfL line styling
Give the Jubilee and Metropolitan sections clear visual identities while keeping the interface readable and accessible.

Create the TfL API service
Add a dedicated service responsible for sending requests to the TfL API and returning the response data.
Convert TfL responses into the internal format
Transform TfL's large prediction objects into the smaller departure format used by the app.
Filter to Jubilee and Metropolitan lines
Explicitly discard any unexpected records that do not belong to the two required lines.
Filter to southbound platforms
Keep Jubilee platform 4 and Metropolitan platforms 5 and 6 while avoiding reliance on incomplete direction fields.
Handle missing destinations
Use destinationName where available and fall back to towards or a suitable destination-unavailable label.
Sort departures by arrival time
Ensure trains are shown in the order they are expected to reach Wembley Park.
Limit the number of displayed trains
Show only the next three or four departures for each line to keep the screen uncluttered.
Format destination names
Remove unnecessary text such as Underground Station before displaying destination names.
Format arrival times
Convert TfL arrival data into clear passenger-facing labels such as 5 min, 1 min and Due.

Add the live local countdown
Recalculate displayed arrival times every second using expectedArrival, without making a network request every second.
Add automatic TfL refreshing
Fetch a fresh set of predictions at a suitable interval, such as every 15 seconds while the app is open.
Handle app foreground and background state
Stop timers when the app moves into the background and perform an immediate refresh when it becomes active again.
Prevent overlapping API requests
Ensure a new refresh does not begin while a previous request is still in progress.
Add manual refresh
Allow the user to request updated data immediately using pull-to-refresh or a refresh button.

Add a loading state
Show a clear loading message or indicator while the first TfL request is being made.
Add a network error state
Display a useful message if TfL cannot be reached rather than leaving the screen blank.
Retain the last successful data
Continue showing the most recent departures after a temporary refresh failure while making it clear that the information may be old.
Add a last-updated indicator
Show when the app last successfully received live data from TfL.
Detect stale prediction data
Warn the user when the latest successful update is too old to be considered reliable.
Handle empty departure results
Show a suitable message when TfL returns no departures for one or both lines.
Handle departed trains cleanly
Remove a train when it disappears from TfL's refreshed response rather than relying only on the local countdown reaching zero.

Investigate duplicate Metropolitan predictions
Examine whether duplicate-looking Metropolitan records need to be removed and decide which fields can distinguish them safely.
Test unusual TfL data
Check behaviour for missing vehicle IDs, repeated IDs, missing destinations and Check Front of Train records.

Test the interface on Android
Check text wrapping, spacing, safe areas, refreshing and app-state behaviour on an Android phone.
Test the interface on iPhone
Check the same features on an iPhone and record any platform-specific differences.
Add accessibility support
Ensure text is readable, information is not communicated through colour alone and screen readers receive useful labels.

Add line status information
Retrieve and display the current Jubilee and Metropolitan line status beneath the departure predictions.

Decide whether to add a Cloudflare Worker
Evaluate moving TfL requests behind a Worker to protect the API key, simplify responses and provide brief caching.
Create the Cloudflare Worker API
If chosen, build a small endpoint that returns only the Wembley Park southbound departure data required by the app.
Move the TfL key to a Worker secret
Remove the API key from the Expo app and store it securely as a Cloudflare Worker secret.

Add basic automated tests
Test important functions such as southbound filtering, sorting, destination formatting and arrival-time formatting.
Add pull request checks
Run formatting, type checking and automated tests whenever a pull request is opened.

Create an Android development build
Produce and install a proper Android test build when the project moves beyond Expo Go.
Create an iOS development build
Produce and install an iPhone development build through Expo EAS when needed.
Prepare the first release
Check the app name, icon, version number, documentation and known limitations before creating the first usable release.

Create a future-features backlog
Record ideas such as home-screen widgets, notifications, walking-time alerts and favourite departure views without adding them to the first release.