IsaiasCuvula/random_user

This is a mobile application designed to fetch and display profiles from the RandomUser API, supporting both online and offline usage through local SQLite caching. It enables users to interact with these profiles by initiating phone calls and sending emails via native device handlers. The system is built on a clean architecture using Riverpod for state management and GoRouter for navigation, and is currently restricted to iOS and Android platforms.

New files have been introduced in the core library to centralize configuration: \api\_urls.dart\ defines the base URL for the RandomUser API, \database\_constants.dart\ specifies the SQLite database name, table structure, and column definitions for caching user data, and \core.dart\ exports these modules along with existing error and network utilities.

lib/core · high confidence

The random user feature now includes domain use cases that allow users to initiate phone calls and send emails. The implementation uses the \url\_launcher\ package to open the device's native dialer via \tel:\ URIs and the default mail client via \mailto:\ URIs, handling success and failure states through Riverpod providers.

_lib/features/random\_user, lib/features/random\_user/domain/usecases/makecall, lib/features/random\user/domain/usecases/sendemail · high confidence

The domain layer for the Random User feature has been established, introducing the core data models (User, RandomUser, Email, Location, Picture, Username) and the repository interface (RandomUserRepository) that defines methods for fetching single or list of random users. This change also includes the implementation of use cases (GetRandomUser, GetListOfRandomUsers) to encapsulate business logic and Riverpod providers to wire these use cases and the repository together, completing the clean architecture separation for this feature.

_lib/features/random\user/domain · high confidence

The application now includes a dedicated error handling layer in the core module, introducing specific exception classes (Server, Cache, ParsingJson, Unknown) and corresponding failure classes (Server, Cache, ParsingJson, SendingEmail, MakingCall) to standardize how errors are represented and propagated throughout the system.

lib/core/error · high confidence

The application now includes a new core network module that allows the app to check if the device is currently connected to the internet via mobile, Wi-Fi, or Ethernet. This feature is implemented using the \connectivity\_plus\ package and is exposed through a \NetworkInfo\ interface and its \NetworkInfoImpl\ class. The implementation is provided as a Riverpod provider (\networkInfoProvider\), making it easy for other parts of the app to inject and use this connectivity status check.

lib/core/network · high confidence

This change introduces the complete presentation layer for the Random User feature, adding Flutter UI pages (Home, List, Detail, Error) and a suite of reusable widgets (UserCard, DisplayUserImage, BodyInfo) to display user profiles and lists. It also implements the corresponding Riverpod providers and state management logic to fetch single or multiple random users, handle loading and error states, and support user actions such as sending emails and making phone calls.

_lib/features/random\user/presentation · high confidence

The data layer for the Random User feature has been implemented, introducing a clean architecture structure with local and remote data sources, a repository, and data models. Users can now fetch random user data from a remote API or retrieve cached data from a local SQLite database when offline, with the repository handling the logic to switch between these sources based on network connectivity. The implementation includes an HTTP client for API requests, a mapper for converting JSON responses to domain models, and Riverpod providers for dependency injection.

_lib/features/random\user/data · high confidence

The Linux desktop platform support has been removed from the application. All Linux-specific source files, including the CMake build scripts, main entry point, and GTK application wrapper, have been deleted, meaning the application can no longer be built or run on Linux desktop environments.

linux · high confidence

The Windows desktop platform files have been completely removed from the project. This includes the CMake build configuration, the Win32 window runner implementation, and the Flutter engine integration code. As a result, the application can no longer be built or run on Windows desktop environments.

windows · high confidence

The default \index.html\ and \manifest.json\ files for the web platform have been removed from the project. This eliminates the standard Flutter web bootstrap script and the web app manifest configuration (including icons and theme colors), meaning the application will no longer load or register as a standalone web app using these default assets.

web · high confidence

The entire macOS platform directory has been removed, including the Xcode project configuration, build schemes, and native Swift source files (AppDelegate, MainFlutterWindow). This eliminates the ability to build or run the application as a native macOS app.

macos · high confidence

The application's root widget has been updated to use MaterialApp.router with a router configuration, replacing the previous navigation setup. This change enables declarative routing via GoRouter, allowing for more structured and maintainable navigation flows within the app.

lib/app · high confidence

The application now organizes core configuration settings into a dedicated \lib/config\ directory, separating concerns for theming and routing. Users benefit from a consistent dark theme with green accents and standardized spacing/margins applied across the UI. Additionally, navigation is now managed via \go\_router\, enabling structured routes for the home page, user list, and user detail views, complete with fade transitions and the ability to pass user objects between screens.

lib/config · high confidence

The application now uses Riverpod for state management, wrapping the root widget in a ProviderScope instead of running the previous MyApp widget directly. Additionally, the main entry point has been updated to run asynchronously and initialize Flutter bindings before launching the app, ensuring proper setup for the new state management layer.

lib · high confidence

The iOS configuration has been updated to allow the app to query and open external mail and phone applications. Specifically, the Info.plist now includes LSApplicationQueriesSchemes for 'mailto' and 'tel', enabling users to trigger email composition and phone calls from within the app. This change is supported by the integration of CocoaPods dependencies, which are now properly linked and embedded in the Xcode project build phases.

ios · high confidence

Added unit and widget tests for network info and app initialization; Added unit tests for Random User data layer; Added unit tests for Random User presentation providers; Added unit tests for Random User use cases and providers; Added unit tests for RandomUser repository and provider; Updated code coverage report.

The project dependencies have been configured to support the core features of the application. Direct dependencies include state management via flutter\_riverpod, navigation with go\_router, local storage using sqflite, HTTP requests via http, URL launching with url\_launcher, network connectivity monitoring with connectivity\_plus, and image caching via cached\_network\_image. Additional libraries such as dartz, equatable, and path\_provider are included to support data modeling and platform-specific file operations. Development dependencies have also been added, including build\_runner for code generation, sqflite\_common\_ffi for desktop database support, and mocktail for testing utilities.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 57 → 57 (-0.0)
• Rubric changed (rubric-2026.08.17 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 100 → 100 (-0.2)
• Architecture 100 → 91 (-9.2)
• Maturity 48 → 51 (+3.0)
• Readiness 48 → 41 (-6.8)
• Security 58 → 80 (+21.8)
• Domain Modelling 100 → 100 (+0.0)

• Dependency hygiene not measured — no supported dependency manifest was read
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• No exposed public API
• Test reliability not included
• The assets README is thin and only describes the launch screen, with no guidance on how to customize it or what files are needed. (ios/Runner/Assets.xcassets/LaunchImage.imageset/README.md)
• complexity unreadable for .dart, .kt, .swift — churn × complexity hotspots could not be measured
• single-maintainer — knowledge-concentration (bus factor) risk

• Dependency hygiene PARTLY measured — Maven/Gradle declarations read, no dependency graph resolved
• Documentation: no installation or build instructions (README.md)
• Documentation: no usage examples (README.md)
• Duplicated block (24–26 lines × 2) (lib/features/random_user/data/datasources/local/random_user_local_data_source_impl.dart)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• Medium: security finding (details withheld)
• Medium: security finding (details withheld)
• No dependency advisory monitoring
• Workflow token permissions not restricted

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

IsaiasCuvula/random_user was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.