RespiraBem
Local scheduling and weather context in a mobile interface.
Flow summarized from the reviewed implementation. Details and limits are explained below; this visualization is not a production screenshot or proof of measured performance.
Prototype objective and scope
RespiraBem is a mobile application study with profiles, schedules and weather information. It explores everyday organization through a simple interface without presenting the software as a validated clinical product.
Its technical contribution connects Flutter widgets, asynchronous operations, Dart models and local persistence. Seed data and a demonstration API support flow exploration before real authentication and synchronization infrastructure.
Interface and widget composition
The application separates entry and home pages from components such as welcome cards, action cards and schedule items. Smaller widgets encapsulate presentation and reuse the schedule’s visual organization.
Home loads asynchronous data and updates state to display users and appointments. Empty and failure states participate in the flow, distinguishing an empty dataset from rendering errors.
SQLite and local models
DatabaseHelper centralizes SQLite opening through sqflite. Tables represent users and schedule items; models convert database maps to Dart objects and back. Queries order items by time.
Schedule insertion and profile updates occur on the device. This persistence does not imply account synchronization, local encryption or remote backup; those capabilities require additional components.
Weather integration
WeatherApi queries Open-Meteo through HTTP and converts JSON into a weather model. Code provides a default query and a coordinate-and-city-parameterized operation.
Handling distinguishes successful HTTP responses from retrieval failures. Weather context is an interface feature; the project does not derive medical recommendations or create its own forecasts.
Demo entry and dependencies
UserApi queries a fake API and finds users by email, comparing returned data to simulate entry. This exercises parsing, timeouts and error messages but is not secure server-side authentication.
The prototype has permissive demonstration paths. A real version would need protected credentials, backend verification, tokens, per-user data isolation and an appropriate privacy policy.
Learning and next steps
The project demonstrates UI composition, local modeling, on-device SQL, API consumption and coordination of remote and local data. Review inspected code without device execution or clinical-use validation.
Evolution could include database migrations, widget and repository tests, controlled notifications and replacing the fake API. The scope remains a mobile-development study.