anurajx/delhiunderground

1. This is a Flutter client app for Delhi NCR metro information. The repo is primarily a single cross-platform mobile/desktop/web application, with no separate backend service checked in. The architecture is centered around bundled transit data and in-app UI flows for route lookup, station details, maps, and schedules.

2. The application entry point is lib/main.dart. From there, the app likely wires the top-level navigation and shared app state into feature screens under lib/elements. The naming suggests a simple screen-driven architecture rather than a heavily layered domain system.

3. The main user-facing subsystems are:

- lib/elements/metro.dart for the metro network home/map experience

- lib/elements/route.dart for route planning

- lib/elements/search.dart for search-driven station discovery

- lib/elements/StationDir/stationSearch.dart and stopInfo.dart for station detail lookup

These form the primary navigation boundaries in the app.

4. Map rendering is isolated under lib/elements/MapDir. mapMetro.dart and svgMap.dart suggest a dedicated map subsystem that renders the network visually, likely using static SVG or vector assets rather than live GIS services. This boundary is important because map presentation is separate from route/schedule logic.

5. Route computation and route-related data access are separated under lib/elements/RouteDir/routeDataProvider.dart. That indicates a provider-style layer that feeds the route UI with route metadata and possibly calculated route options. The app likely keeps route logic distinct from station lookup and map display.

6. Service and data-access logic lives in lib/elements/ServicesDir, which is the most important non-UI boundary in the repo. Files such as scheduleService.dart, newScheduleService.dart, openingClosingFetcher.dart, stopInfoFetcher.dart, gatesFetcher.dart, and reportErrorService.dart show that the app centralizes access to schedules, station metadata, gates, operating hours, and error reporting behind service classes or fetchers.

7. ServicesDir also includes station and proximity helpers such as geolocatorService.dart, metroStationsList.dart, and miniMetroStationList.dart, plus data_Provider.dart and Station_element.dart. This suggests the app supports station list generation, possibly near-station lookup, and a common station model used across route, search, and station-detail flows.

8. The app’s core data is bundled locally in assets/ rather than pulled from a dedicated backend. Key data sets include:

- assets/Map/ for stations, gates, parking, shapes, timetable-related JSON, and map styling

- assets/TimeTable/ for multiple route/day-specific CSV schedules

- assets/routes.db and assets/newTimeTable.json for additional structured transit data

- assets/fonts/ and animation JSON files for UI polish

This means the app’s architecture depends heavily on offline/static asset loading.

9. The data flow is likely: UI screens in lib/elements/* call service/provider classes in ServicesDir and RouteDir, which in turn read bundled assets and possibly device location via geolocatorService.dart. The resulting station, route, and schedule data is then rendered in the metro map, search, and stop-info views. The main boundary is between presentation and asset-backed data services.

10. Platform support is standard Flutter scaffolding for Android, iOS, web, Linux, macOS, and Windows. The platform folders mostly contain generated runners and launch configuration, while app-specific native code is minimal (MainActivity.kt, AppDelegate.swift, platform manifests/plists). This indicates the architecture is overwhelmingly Dart-side, with native layers acting only as host shells.

11. The repo includes a small test surface (test/widget_test.dart) and standard Flutter tooling files (pubspec.yaml, Gradle/Xcode/CMake scaffolding). There is no evidence of a complex CI/CD or backend architecture in the repository itself; deployment appears focused on packaged app releases, especially Android APKs as described in the README.

12. For an architecture diagram, the key nodes are: platform shell, Flutter app entry, feature screens, service/provider layer, and local transit assets. The strongest structural distinction is that this is an offline-first, asset-driven metro information app with map, route, station-search, and timetable subsystems sharing a common service layer.