SDGM is a Flutter campus guide with floor-level 3D models. It provides Firebase sign-in and bottom navigation, with a center button for the 3D map. A dashboard also shows meals, water, exercise and body information.

Implementation

The repository includes Flutter application structure, Firebase authentication UI, custom navigation, wellness cards and animation, a flutter_3d_controller viewer and Android, iOS and web runners.

Current status

The public repository provides app source and 3D assets, but no public application deployment or operational data service is confirmed. User volume, wayfinding success, 3D loading performance and accessibility are not measured.

1. Bootstrap and identity boundary

main.dart initializes Firebase and opens LoginPage. Email sign-in, sign-up and password reset call Firebase Auth directly; Google exchanges provider credentials for a Firebase session. Success uses pushReplacement to enter MainPage, removing authentication from the back stack.

2. Shell and navigation boundary

MainPage owns the selected tab and transition AnimationController. BottomBarView changes four tabs through a callback, while its raised center action pushes the 3D MapView as a separate route. Adding screens requires coordinated tab state, controller disposal and route-state decisions.

3. Wellness presentation composition

My Diary and training/account compose meal, water-wave, exercise, body and identity widgets. Each receives an interval from a parent animation controller for staggered entry. Values are built around local models and sample presentation; a synchronized persistence repository is not confirmed.

4. 3D model path

MapView uses flutter_3d_controller to choose B2, B1 and 1F–4F GLB floors, route FBX files and animations. Floor controls change bundled asset paths, while the renderer exposes orbit, camera, texture and playback operations. The heavy 3D state stays outside the regular tab shell.

5. Platform and failure boundaries

Firebase configuration differs across Android, iOS and web, while 3D behavior depends on platform GPU, WebGL and asset loading. Facebook currently reports provider success without completing the commented Firebase credential exchange. A web options file exists, but public web delivery and provider compatibility still require separate validation.

6. State and asset ownership

Firebase owns the identity session, main_page and bottom navigation own the current tab, and Map.dart owns floor selection and the 3D controller. GLB and FBX files are bundled assets, so server refresh and version negotiation are missing.

7. Performance and failure recovery

Model weight and GPU/WebGL capability determine startup and memory cost. Floor-level lazy loading, controller disposal, low-end fallback imagery and asset-decode error states require validation. FPS and memory have not been measured.

8. Security, observability and debt

Every identity provider must complete the Firebase credential exchange to share one security contract. Crash and asset-latency observability are missing. Platform branches and login logic should move into dedicated service boundaries.

Share app and web runners with Flutter

Flutter keeps identity, dashboard cards and the 3D map in one Dart codebase. UI reuse is strong, while social login and 3D rendering still require platform-specific configuration and compatibility work.

Delegate identity to Firebase

Email, Google and reset flows avoid a custom identity server. Firebase configuration and provider-console setup become runtime dependencies, and each provider must complete the same Firebase session contract.

Push the center 3D action as a route

The heavy map is not retained as one of four ordinary tabs. This avoids keeping the renderer alive continuously, but selected floor and camera state need explicit preservation when users return.

Bundle model files with the app

Local GLB and FBX files make the experience reproducible without a model server. The cost is application size, first decode time, GPU memory and a full deployment whenever a model changes.

Stagger dashboard cards

Parent controllers and intervals create a coordinated presentation. Every screen must correctly own controller lifetime and provide an alternative for reduced motion.

Identity scenarios

• Exercise email sign-up, sign-in, sign-out and password reset success and Firebase errors.
• Verify Google cancel, success and credential-exchange failure leave routes and loading state coherent.
• For Facebook, inspect currentUser instead of treating the provider-success message as a Firebase session.
• Confirm back navigation does not expose login after successful replacement.

Navigation and 3D scenarios

• Rapidly switch all four tabs and watch for duplicate or disposed controllers and lost state.
• Repeatedly enter and leave the center map and verify renderer memory is released.
• Load every floor GLB and route FBX and expose missing-asset or decode failures to the user.
• Test floor controls and orbit gestures on small, landscape and web viewports.

Automated evidence

An iOS Runner test skeleton and lint configuration exist, but no confirmed Dart widget, unit or integration suite covers the app. Platform login success, model load time, memory and frame stability are not measured.

Known limits

• Facebook does not complete Firebase credential exchange.
• Persistent wellness repositories are not confirmed.
• Bundled models increase both app size and update cost.
• A web runner exists without a verified public web deployment or provider matrix.
• The 3D guide is not sensor-based real-time indoor positioning.

Completed

• Firebase email and Google identity plus password-reset UI
• Four-tab shell with a raised center 3D map action
• Meal, water, exercise and body-measurement cards
• Floor GLB, route FBX and camera/animation controls
• Android, iOS and web runners with platform configuration

Priority improvements

• Complete Facebook-to-Firebase credential exchange or remove unsupported UI
• Initialize with DefaultFirebaseOptions.currentPlatform and validate each environment
• Expose model loading, decode and unsupported-renderer error states
• Add automated coverage for identity, routes, floors and controller lifecycle
• Label sample wellness values separately from real user data

Later work

• Preserve floor, camera and destination state with deep links
• Compress and lazy-load models with device-tier quality controls
• Provide accessible text directions that do not require a 3D renderer
• Validate OAuth origins, WebGL and mobile browsers before web deployment

Out of scope

Medical diagnosis, health prescriptions, real-time indoor positioning and emergency evacuation decisions are outside this app. Wellness values are interface examples, not professional health evidence.