salf423/app-nvel-burbuja

1. Project type and scope

- This is a .NET MAUI Android app for a bubble level / inclinometer, not a multi-service system.

- The architecture is intentionally small: one UI screen, one sensor-driven interaction loop, and Android-specific packaging/build configuration.

2. Application composition

- The repo is split into XAML UI and C# code-behind.

- The main functional boundary is between:

- visual layout (buendia/XAML)

- runtime behavior and sensor handling (buendia/C#)

- There is no backend, database, or network layer in the repository.

3. Startup and host layer

- App.xaml.cs and MauiProgram.cs define the app startup path.

- MainActivity.cs is the Android entry host that connects the MAUI app to the Android runtime.

- App.xaml provides the application-level shell/resources, while MainPage.xaml is the primary screen shown to the user.

4. Main UI subsystem

- MainPage.xaml is the single visible interface for the level indicator.

- The UI likely contains a movable visual element (miBurbuja) whose position represents tilt.

- The UI is updated continuously from sensor events, so the page is both the display surface and the target of live state changes.

5. Sensor processing subsystem

- The core logic is in MainPage.xaml.cs, where the accelerometer change handler is registered and executed.

- The app listens to accelerometer readings and uses them as the raw input stream.

- This is the central data source of the whole application.

6. Signal processing and motion logic

- Each accelerometer update reads the X, Y, and Z axes.

- The values are smoothed with an exponential filter using Alpha, reducing jitter.

- From the filtered values, the app computes:

- pitch from X relative to Y/Z magnitude

- roll from Y and Z

- These angles are then converted into visual offsets for the bubble.

7. UI update flow

- Sensor callbacks are not applied directly to the visual tree; updates are marshaled through the main thread.

- The bubble position is changed via TranslationX and TranslationY.

- The final displacement is scaled and clamped, which keeps the UI stable and prevents the bubble from moving outside the intended range.

8. Android platform boundary

- buendia/Propiedaes/AndroidManifest.xml defines Android-specific capabilities and app metadata.

- The manifest declares:

- app name/label

- minimum and target SDK levels

- required accelerometer hardware

- This means the app is explicitly tied to devices with an accelerometer.

9. Permissions and device constraints

- The README highlights that sensor permissions must be handled for Android runtime behavior.

- It also notes that testing should be done on a real Android device, which is important because the app depends on actual motion hardware.

- This is not an emulator-first design; physical sensor input is the critical dependency.

10. Build and packaging

- AccelerometerEssential.Android.csproj is the Android project definition.

- Directory-Build.props and global.json provide repo-wide build consistency and SDK pinning.

- The repository includes a GitHub Actions workflow at .github/workflows/build-android.yml, indicating automated Android builds/CI.

11. Runtime behavior summary

- The app’s data flow is linear:

- accelerometer hardware → change event → filtering → angle computation → UI translation

- The screen is continuously driven by live sensor input, so the system behaves like a real-time control loop rather than a request/response application.

12. Architecture diagram boundaries to show

- A good diagram should include these distinct blocks:

- Android device hardware (accelerometer)

- Android runtime / MainActivity

- MAUI app shell and page layer

- sensor processing logic

- bubble UI element

- build/CI pipeline

- The key dependency direction is from hardware input into the page logic, then outward to the UI.

13. Repo-specific note

- The folder names show a mix of Spanish labels and MAUI conventions, and Propiedaes appears to be a typo of Propiedades; architecturally, it still functions as the Android properties/manifest area.

- The repo is tightly focused: the accelerometer-driven bubble indicator is the main product behavior, and everything else supports that single flow.