malikkurosaki/phis_mobile

1. This is a Flutter client application named probus_mobile, built to run across Android, iOS, web, and macOS. The repository is mostly a frontend app plus its platform shells; there is no backend service code here.

2. The main app entrypoint is lib/main.dart. Shared app-wide concerns appear to live in lib/store.dart and lib/tema.dart, which likely provide global state and theming used by multiple screens.

3. The codebase is split into two major business domains:

- components_phis / models_phis for a hotel/property-operations workflow

- components_presto / models_presto for a restaurant/F&B workflow

This split is one of the clearest architectural boundaries in the repo.

4. The UI/navigation layer lives under lib/views. The visible app surfaces include login.dart, home.dart, hotel.dart, and restaurant.dart, which likely act as top-level routes or section launchers into the two business domains.

5. The hotel/PHIS feature set includes operational dashboards and daily status views: arrivals, departures, in-house guests, next-day variants, reservations, forecast occupancy, and room production by geography. The corresponding models mirror those screens, suggesting a fairly direct mapping from API payloads to display components.

6. The restaurant/Presto feature set centers on analytics and reporting: daily revenue, home index, payment breakdowns, product sales, sales performance, sales traffic, transaction summary, and various sales-analysis screens. There is also a master subfolder with reference-data screens such as outlet, department, date, type, and product group.

7. Calendar-specific functionality is isolated in lib/model_calendar and lib/views/calendar_*. The presence of booking/room-type models suggests a booking/calendar workflow separate from the hotel and restaurant dashboards.

8. The network/data layer is concentrated in lib/rest_api.dart plus the response wrappers rest_response_restaurant.dart, rest_restponse_calendar.dart, and rest_restponse_phis.dart. These files likely normalize external API responses into typed Dart models before the data reaches the UI components.

9. The repository contains a few auxiliary or experimental files at the root such as response.js, x_fake_api.dart, x.rest, xcoba.dart, and perintah.dart. These look like developer tooling, mock API scaffolding, or scratch code rather than core runtime architecture.

10. Assets are lightweight but functional: assets/sound contains several audio cues, which implies the UI uses sound feedback for interactions or status events. Standard Flutter-generated native wrappers are present under android/, ios/, macos/, and web/, with no special native subsystem beyond the usual platform launch/configuration files.

11. Testing is split between test/widget_test.dart for basic widget coverage and integration_test/ for end-to-end app flows. This indicates the app is expected to be exercised at both unit/widget and device-integration levels.

12. For an architecture diagram, the most important flow is: platform shell launches Flutter app → main.dart initializes shared state/theme → user enters via login/home → navigates into hotel, restaurant, or calendar modules → each module renders component screens backed by typed models → data is fetched and normalized through the REST/response layer.