SinaSys/flutter_go_rest_app
42.9
Weak · 21 September 2026
33.7k
lines of production code
Dart
primary language
4
measurements over time
What this system is
This codebase is a comprehensive educational repository demonstrating multiple architectural patterns for a Flutter application that manages users, posts, todos, and comments via the GoRest API. It provides parallel implementations of Layered Architecture, Clean Architecture, and MVVM, each realized with different state management solutions including GetX, BLoC/Cubit, and Provider/RxDart. The system features a shared network layer using Dio v5, environment-based configuration for backend switching, and reusable UI components for consistent user feedback.
How it got here
2022 — Multi-architecture refactoring
53 changes.
This period was defined by the systematic refactoring of the codebase into multiple parallel implementations using different state management patterns (GetX, Cubit, Bloc) and architectural styles (Layered, Clean). The team removed an obsolete Flutter application, upgraded the networking layer to Dio v5, and established shared UI and network components to support these diverse architectural approaches.
2023–2025 — multi-architecture implementation
66 changes.
The project expanded its codebase to implement the same application features across multiple architectural patterns, including Clean Architecture with Cubit, GetX, and Provider, as well as an MVVM structure using Bloc and GetX. This period focused on establishing the foundational scaffolding, dependency injection, and core network layers for each variant, while also introducing a new Spring Boot backend to support these diverse frontend implementations.
Features
Add Todo list item and circle container widgets
Introduced new UI components for the Todo feature: a reusable CircleContainer widget for rendering status indicators, and a TodoListItem widget that displays individual todo items with title, due date, and edit/delete actions. These widgets form the visual building blocks for the todo list interface.
\#1 - Layered Architecture Version (GetX)/lib/features/todo/view/widget · high confidence
Add common UI widget components
Introduced a new set of reusable UI widgets for the application, including a date and time picker, a generic dropdown selector, an empty state display, a popup menu, a loading indicator, and a styled text input field. These components provide consistent styling and behavior across the app's interface.
\#4 - Clean Architecture Version (Bloc)/lib/common/widget · high confidence
Add common UI widget components for the MVVM GetX architecture
Introduced a set of reusable UI components in the common widget library to support the new MVVM (GetX) architecture. The update adds a DateTimePicker for selecting date and time, a generic DropDown for list selection, a PopupMenu for action menus, a TextInput for form inputs, a SpinKitIndicator for loading states, and an EmptyWidget for empty states. These widgets provide the foundational UI elements required for the MVVM implementation.
\#9 - MVVM Version (GetX)/lib/common/widget · high confidence
Add common dialog components for user management and error handling
The application now includes reusable dialog components for the Clean Architecture (Bloc) version. This includes a create/update user dialog with form validation, a delete confirmation dialog, a progress indicator dialog, and an error/retry dialog. These components provide a consistent user interface for common interactions across the app.
\#4 - Clean Architecture Version (Bloc)/lib/common/dialog · high confidence
Add common dialog components for user management and status feedback
Added four new dialog components to the application's common UI library: a reusable form dialog for creating or updating users, a confirmation dialog for deleting users, and two status dialogs (progress and retry) for handling loading states and errors. These widgets provide consistent user interfaces for key user interactions within the MVVM/GetX architecture.
\#9 - MVVM Version (GetX)/lib/common/dialog · high confidence
Add complete Clean Architecture implementation for Todo and Comment features
Introduces a full Clean Architecture implementation for the Todo and Comment features, each comprising data models, remote data sources, repositories, domain entities, use cases, and presentation layers (BLoC/State). The Todo feature includes create, update, delete, and fetch operations with status filtering, while the Comment feature supports creating, deleting, and fetching comments. Both features use RxDart for reactive state management and Provider for dependency injection, with UI screens and widgets handling user interactions and displaying results.
\#10 - Clean Architecture Version (RxDart + Provider)/lib/features/todo · high confidence
Add data layer for comments, posts, todos, and users
Introduced the complete data layer for the MVVM GetX architecture, including API client classes (CommentApi, PostApi, ToDoApi, UserApi) that handle HTTP requests, and corresponding data models (Comment, Post, ToDo, User) with JSON serialization support.
\#9 - MVVM Version (GetX)/lib/data · high confidence
Add generic BLoC state and helper mixin for common BLoC operations
Users gain a reusable, generic BLoC state representation (GenericBlocState) that tracks loading, success, failure, and empty states for any data type. A new BlocHelper mixin provides standardized create, update, delete, and select operations, reducing code duplication across BLoCs by centralizing API result handling and state emission logic.
\#7 - MVVM Version (Bloc)/lib/common/bloc · high confidence
Add generic BLoC state, builder, and helper for simplified API handling
A new set of reusable BLoC utilities has been added to the common layer to streamline API interactions in the UI. This includes a GenericBlocState to represent empty, loading, success, and failure states; a GenericBlocBuilder widget that automatically handles these states by showing a progress indicator, a retry dialog on error, or a success widget; and a BlocHelper mixin that provides standard get, create, update, and delete methods to reduce boilerplate when calling APIs.
\#4 - Clean Architecture Version (Bloc)/lib/common/bloc · high confidence
Add post and comment features using the Bloc architecture
The application now includes full support for managing posts and comments through a layered architecture using the Flutter Bloc pattern. This introduces new screens for listing, creating, updating, and deleting posts, as well as viewing and managing comments on those posts. The implementation includes the necessary BLoC classes, event and state definitions, data models with JSON serialization, and API providers to handle the underlying business logic and data fetching.
\#3 - Layered Architecture Version (Bloc)/lib/features/post · high confidence
Add user data layer with remote data source and repository
Introduced the user feature's data layer, including a remote data source that communicates with the API via a Dio client, a repository implementation that wraps data source calls with error handling, and a User model with JSON serialization and a copyWith method for unit testing.
\#6 - Clean Architecture Version (Getx)/lib/features/user/data · high confidence
Add user management feature with layered architecture
Introduced a complete user management feature built on a layered architecture using Cubit. This includes a UserCubit for state management, a User data model with JSON serialization, a UserApi for remote data fetching, and a UserListScreen UI that allows users to create, update, delete, and filter a list of users. The implementation follows a clean separation of concerns with distinct layers for data, presentation, and business logic.
\#2 - Layered Architecture Version (Cubit)/lib/features/user · high confidence
Added Flutter project scaffolding for the Cubit-based layered architecture
The directory now contains the initial project configuration files for a Flutter application using the Cubit state management pattern. This includes a .gitignore file tailored for Flutter/Dart development, a .metadata file tracking the Flutter SDK revision and platform states, an analysis\_options.yaml file that enables recommended Flutter lints, and a README.md that directs users to the main project documentation.
\#2 - Layered Architecture Version (Cubit) · high confidence
Added MVVM (Bloc) implementation for the Todo list view
Introduced a new MVVM architecture using the Flutter Bloc pattern for the Todo application. This includes the main TodoListScreen which manages state via TodoBloc, along with supporting widgets like TodoListItem and CircleContainer. The implementation handles creating, updating, and deleting todo items, displaying loading and error states, and filtering by status.
\#7 - MVVM Version (Bloc)/lib/view/todo · high confidence
Added MVVM/Bloc-based post management screens
Introduced new Flutter screens for the MVVM architecture using the Bloc pattern: CreatePostScreen for creating and updating posts, PostDetailScreen for viewing post details and comments, and PostListScreen for displaying the list of posts. These components implement the UI layer for post-related features, handling state management via BLoC and providing user interactions for creating, updating, deleting, and viewing posts and comments.
\#7 - MVVM Version (Bloc)/lib/view/post · high confidence
Added Todo data layer with model, serialization, and API provider
Introduced the Todo feature's data layer, including the ToDo model class with JSON serialization and a TodoStatus enum, alongside a remote API provider that implements create, update, delete, and list operations for todos.
\#3 - Layered Architecture Version (Bloc)/lib/features/todo/data · high confidence
Added Todo data layer with remote data source, model, and repository
Introduced the data layer for the Todo feature, including a remote data source that handles CRUD operations via the network, an immutable Todo model for JSON serialization, and a repository implementation that wraps these calls with error handling.
\#5 - Clean Architecture Version (Cubit)/lib/features/todo/data · high confidence
Added Todo feature with Bloc state management and UI components
Users can now view, create, update, and delete tasks through a new Todo feature. This includes a TodoListScreen for managing tasks, a TodoBloc for handling state transitions (loading, success, failure), and supporting widgets like TodoListItem and CircleContainer. The implementation uses the Flutter Bloc pattern to manage asynchronous operations and UI updates.
\#3 - Layered Architecture Version (Bloc)/lib/features/todo/view · high confidence
Added TodoList and CircleContainer widgets for the Todo feature
Introduced two new presentation widgets for the Todo feature: a reusable CircleContainer for status indicators and a TodoListItem that renders individual todo cards with title, due date, and edit/delete actions.
\#6 - Clean Architecture Version (Getx)/lib/features/todo/presentation/widgets · high confidence
Added common UI widget components
The \lib/common/widget\ directory now includes several reusable UI components: a \DateTimePicker\ for selecting date and time, a generic \DropDown\ for selection, an \EmptyWidget\ for displaying empty states, a \PopupMenu\ for action lists, a \SpinKitIndicator\ for loading states, and a \TextInput\ for form fields.
\#5 - Clean Architecture Version (Cubit)/lib/common/widget · high confidence
Added common UI widgets for the Bloc architecture version
The project introduces a new set of reusable UI components in the common widget layer to support the Bloc-based architecture. This includes a generic DropDown widget for handling item selection, a PopupMenu for context actions, a TextInput field with validation and icon support, a DateTimePicker updated to use the newer WidgetState API, an EmptyWidget for displaying empty states, and a SpinKitIndicator for loading feedback. These widgets provide a consistent interface for user interactions and visual feedback across the application.
\#3 - Layered Architecture Version (Bloc)/lib/common/widget · high confidence
Added common dialog and BLoC helper components
The application now includes reusable UI components for user interactions and state management. A generic BLoC helper mixin (BlocHelper) and a GenericBlocState class provide a standardized way to handle API results and emit loading, success, failure, and empty states. For the UI, new dialog widgets have been added: a create/update form dialog for user data entry, a confirmation dialog for delete actions, a progress indicator dialog, and a retry/error dialog. These components standardize how the app handles user input, loading states, and error scenarios.
\#3 - Layered Architecture Version (Bloc)/lib/common/dialog · high confidence
Added data layer for MVVM (Cubit) architecture
Introduced the complete data layer for the MVVM (Cubit) version of the application. This includes new API client classes for managing comments, posts, todos, and users, each handling standard CRUD operations via a shared \ApiHelper\ mixin. Additionally, data models for comments, posts, todos, and users have been added, featuring JSON serialization support for data mapping.
\#8 - MVVM Version (Cubit)/lib/data · high confidence
Added data models and API providers for comments and todos
Introduced new data models and API providers for the comment and todo features. The comment feature now includes a \Comment\ model with JSON serialization and a \CommentApi\ class handling create, delete, and fetch operations. Similarly, the todo feature adds a \ToDo\ model with status enum support and a \ToDoApi\ class managing create, update, delete, and fetch operations, all extending the \ApiBase\ class.
\#2 - Layered Architecture Version (Cubit)/lib/features/comment, \#2 - Layered Architecture Version (Cubit)/lib/features/todo/data · high confidence
Added new dialog components and refactored existing ones
The application now includes new dialog components for delete, progress, and retry scenarios, each providing specific user interactions: a confirmation dialog for deletion, a loading indicator for progress states, and an error handling dialog with a retry option. The existing create/update user dialog was moved and refactored to use absolute imports and updated internal structure. These changes introduce new UI elements for common user interactions.
\#2 - Layered Architecture Version (Cubit)/lib/common/dialog, \#7 - MVVM Version (Bloc)/lib/common/dialog · medium confidence
Added new user management and error-handling dialog components
The application introduces three new common dialog components to improve user interaction and error handling. A \createDialog\ is added to handle user creation and update forms, supporting both create and update modes with validation. A \deleteDialog\ is added to confirm user deletion with a warning interface. A \RetryDialog\ is added to display error messages with a retry option. Additionally, the existing \ProgressDialog\ is refactored to use modern Flutter syntax (e.g., \super.key\) and imports are reorganized, while unused code and comments are removed.
\#1 - Layered Architecture Version (GetX)/lib/common/dialog, \#5 - Clean Architecture Version (Cubit)/lib/common/dialog · high confidence
Added project configuration and metadata files for the MVVM (Bloc) variant
The MVVM (Bloc) version of the application now includes standard Flutter project configuration files. A .gitignore file is added to exclude build artifacts, IDE settings, and generated files from version control. A .metadata file is included to track the Flutter SDK version and channel, supporting the Flutter migrate tool. Additionally, an analysis\_options.yaml file is added to configure static code analysis and linting rules using the recommended Flutter lints. These changes establish the foundational project structure for this specific architectural variant.
\#7 - MVVM Version (Bloc) · high confidence
Added reusable dialog components for user management and status feedback
The application now includes new reusable dialog widgets in the common layer: createDialog for creating or updating user records with form validation, deleteDialog for confirming user deletion, RetryDialog for displaying error states with a retry action, and ProgressDialog for showing loading and success states. These components provide a consistent user experience for critical interactions and status updates.
\#6 - Clean Architecture Version (Getx)/lib/common/dialog, \#8 - MVVM Version (Cubit)/lib/common/dialog · high confidence
Adds new common UI widgets for the MVVM/Bloc architecture
Introduced a suite of reusable UI components in the common widget library to support the new MVVM/Bloc architecture. This includes a DateTimePicker for date and time selection, a TextInput field with validation and icon support, a generic PopupMenu for item selection, a EmptyState display for list views, and a SpinKitIndicator for loading states. Additionally, the existing DropDown widget was migrated to the new package structure.
\#7 - MVVM Version (Bloc)/lib/common/widget · high confidence
Android project scaffolding for MVVM (Bloc) architecture
The Android module for the MVVM (Bloc) version of the app has been added, providing the necessary Android configuration files to support the Flutter application. This includes the Gradle wrapper configuration for version 9.6.0, the main AndroidManifest.xml defining the activity and Flutter embedding, the Kotlin MainActivity class, and the standard Android resource files for launch screens and themes. These changes establish the foundational build and runtime environment for the new architecture.
\#7 - MVVM Version (Bloc)/android · high confidence
Initial Android configuration for Clean Architecture (GetX) project
The Android module has been initialized with standard Flutter project scaffolding, including the Gradle 9.6.0 wrapper configuration, AndroidManifest.xml files for debug, profile, and main builds, the MainActivity Kotlin class, and default launch theme styles. This establishes the baseline Android environment required to build and run the Clean Architecture GetX application on Android devices.
\#6 - Clean Architecture Version (Getx)/android · high confidence
Initial Android configuration for MVVM Cubit app
The Android module for the MVVM (Cubit) version of the app has been added, establishing the native Android project structure. This includes the Gradle wrapper configured for version 9.6.0, standard Android manifest files for debug, profile, and main builds, the main Kotlin activity class, and the default launch screen and theme styles. These files provide the necessary Android-side foundation for the Flutter application.
\#8 - MVVM Version (Cubit)/android · high confidence
Initial Android configuration for the Bloc architecture demo
The Android module is initialized with standard Flutter V2 embedding configuration, including the main activity, manifest, and resource styles. The project is configured to use Gradle 9.6.0, as specified in the gradle-wrapper.properties file.
\#3 - Layered Architecture Version (Bloc)/android · high confidence
Initial Android configuration for the Cubit layered architecture
The Android module for the Cubit-based layered architecture is introduced, including the Gradle wrapper configured for version 9.6.0, the main and debug AndroidManifest files, the Kotlin MainActivity, and the standard Flutter launch theme and style resources.
\#2 - Layered Architecture Version (Cubit)/android · high confidence
Initial Android project scaffolding for Clean Architecture (Cubit) app
The Android module for the Clean Architecture (Cubit) application is introduced, providing the foundational Android configuration and resources. This includes the AndroidManifest files for debug, profile, and main builds, the MainActivity Kotlin class extending FlutterActivity, and standard Android resource files for launch screens and themes. The project is configured to use Gradle 9.6.0, as specified in the wrapper properties.
\#4 - Clean Architecture Version (Bloc)/android, \#5 - Clean Architecture Version (Cubit)/android · medium confidence
Initial Android project scaffolding for the MVVM (GetX) version
This change introduces the complete Android configuration for the MVVM (GetX) variant of the application. It includes the AndroidManifest files for debug, profile, and main builds, the Kotlin MainActivity class, and the necessary resource files for the launch screen and themes. The project is configured to use Gradle 9.6.0, as specified in the wrapper properties.
\#10 - Clean Architecture Version (RxDart + Provider)/android, \#5 - Clean Architecture Version (Cubit)/ios, \#5 - Clean Architecture Version (Cubit)/web, \#9 - MVVM Version (GetX)/android · high confidence
Initial Clean Architecture (Cubit) implementation for user features
The user feature is now implemented using a Clean Architecture approach with BLoC/Cubit state management. This includes a new \UserCubit\ that handles user CRUD operations (create, update, delete, list) by delegating to domain use cases. The \UserListScreen\ has been updated to use \BlocBuilder\ for reactive UI updates and status dialogs, and a new \StatusContainer\ widget provides visual indicators for user status.
\#5 - Clean Architecture Version (Cubit)/lib/features/user/presentation, \#6 - Clean Architecture Version (Getx)/lib/features/todo/presentation/controller · medium confidence
Initial Clean Architecture (Cubit) implementation with dependency injection
The application now uses a Clean Architecture structure with a Cubit-based state management approach. A new dependency injection setup (using GetIt) wires up repositories, use cases, and Cubits for User, Todo, Post, and Comment features. The app entry point initializes this DI container and provides the Cubits via BlocProvider, enabling a structured, testable codebase.
\#5 - Clean Architecture Version (Cubit)/lib · high confidence
Initial Clean Architecture implementation for Todo feature
The Todo feature now uses a Clean Architecture structure, introducing a remote data source that communicates with the API via a Dio client, a repository implementation that wraps data source calls with error handling, and a data model class with JSON serialization and unit-testing support (equality, hashCode, copyWith).
\#6 - Clean Architecture Version (Getx)/lib/features/todo/data · high confidence
Initial Clean Architecture structure with GetX dependency injection
The application now uses a new dependency injection setup via the \get\_it\ package to wire up controllers, use cases, repositories, and remote data sources. The app entry point initializes this DI container and supports dynamic backend environment selection at startup, allowing the app to load configuration for different backend environments.
\#6 - Clean Architecture Version (Getx)/lib · high confidence
Initial GetX-based MVVM architecture for core entities
The application introduces a new MVVM (Model-View-ViewModel) architecture using the GetX framework. This includes a shared \BaseController\ mixin for managing API states and a \RepositoryHelper\ for handling API responses. Specific repositories for Post, Comment, Todo, and User entities have been added to manage data operations, each paired with a corresponding GetX controller (e.g., \PostController\, \CommentController\) that handles state management and business logic for their respective domains.
\#9 - MVVM Version (GetX)/lib/common/controller, \#9 - MVVM Version (GetX)/lib/repository, \#9 - MVVM Version (GetX)/lib/viewmodel · high confidence
Initial Spring Boot backend for managing posts, comments, todos, and users
The gorest-backend now provides a complete REST API for managing posts, comments, todos, and users. The backend exposes endpoints to create, read, update, and delete these resources, with validation and error handling for common scenarios. This initial commit establishes the foundational structure of the application, including controllers, services, repositories, and data transfer objects.
gorest-backend · high confidence
Initial commit for Clean Architecture (Bloc) project structure
The project directory now includes essential configuration files for a Flutter application using the Bloc state management pattern. This includes a .gitignore file tailored for Flutter/Dart development, a .metadata file tracking the Flutter SDK version and migration state, an analysis\_options.yaml file enabling recommended Flutter lints, and a README.md that links to the main project documentation.
\#4 - Clean Architecture Version (Bloc) · high confidence
Initial commit for Clean Architecture GetX version
This change introduces a new Clean Architecture implementation using the GetX state management library. The addition includes a \.gitignore\ file configured for Flutter/Dart projects, a \.metadata\ file tracking the Flutter stable channel and migration state, an \analysis\_options.yaml\ file that enables recommended Flutter lints and excludes generated files, and a \README.md\ that links to the main project documentation.
\#3 - Layered Architecture Version (Bloc), \#6 - Clean Architecture Version (Getx) · high confidence
Initial commit for Clean Architecture Getx project scaffolding
The project has been initialized with the standard scaffolding for a Flutter application using the GetX state management and Clean Architecture principles. This includes the iOS native configuration files (such as the Xcode project, build settings, and asset catalogs), the web entry point and manifest, and the core \UseCase\ interface in the common layer, establishing the foundational structure for the application.
\#6 - Clean Architecture Version (Getx)/ios, \#6 - Clean Architecture Version (Getx)/lib/common/usecase, \#6 - Clean Architecture Version (Getx)/web · high confidence
Initial commit for Clean Architecture version using RxDart and Provider
The repository now includes a new implementation of the Flutter Go REST app that adopts Clean Architecture principles, utilizing RxDart for reactive streams and the Provider package for state management. This change introduces the foundational project structure, including configuration files (.gitignore, analysis\_options.yaml) and metadata (.metadata) specific to this architectural approach, alongside a README that directs users to the main project documentation.
\#10 - Clean Architecture Version (RxDart + Provider) · high confidence
Initial commit for MVVM Version (Bloc) iOS and Web scaffolding
The iOS and Web directories for the MVVM Version (Bloc) project have been added, establishing the foundational build and runtime environment. On iOS, this includes the Xcode project configuration, build scripts, and the \AppDelegate\ entry point that registers Flutter plugins. On the web, the \index.html\ entry point and \manifest.json\ for Progressive Web App support are included. These changes provide the necessary infrastructure to build and run the application on both platforms.
\#7 - MVVM Version (Bloc)/ios, \#7 - MVVM Version (Bloc)/web · high confidence
Initial commit for MVVM architecture using GetX
The project now includes the foundational configuration files for a Flutter application structured with an MVVM architecture using the GetX state management library. This includes a .gitignore tailored for Flutter/Dart projects, project metadata tracking the Flutter SDK version and channel, an analysis\_options.yaml file enabling recommended Flutter lints, and a README linking to the main project documentation.
\#9 - MVVM Version (GetX) · high confidence
Initial domain layer for Comment and Todo features
The domain layer for the Comment and Todo features has been introduced, establishing the core business logic and data structures for these functionalities. This includes immutable entity classes (CommentEntity, TodoEntity), repository interfaces (CommentRepository, TodoRepository), and a set of use cases (e.g., CreateCommentUseCase, GetTodosUseCase) that implement the Clean Architecture pattern. These components define the contracts and logic required to manage comments and todos within the application.
(repo-wide) · high confidence
Initial domain layer for the Todo feature
The domain layer for the Todo feature has been introduced, establishing the core business logic and contracts. This includes the \TodoEntity\ and \TodoStatus\ enum, a \TodoRepository\ interface defining CRUD operations, and four immutable use-case classes (\CreateTodoUseCase\, \DeleteTodoUseCase\, \GetTodoUseCase\, \UpdateTodoUseCase\) that implement the repository to handle specific todo operations.
\#4 - Clean Architecture Version (Bloc)/lib/features/todo/domain, \#5 - Clean Architecture Version (Cubit)/lib/features/todo/domain · high confidence
Initial iOS and Web platform scaffolding for the Cubit architecture project
This change adds the initial iOS and Web platform files for the 'Layered Architecture Version (Cubit)' project. On iOS, it introduces the standard Flutter project structure including the Xcode project configuration, build scripts, asset catalogs, and the main application entry point. On the Web, it provides the default HTML entry point and the PWA manifest file. These files establish the foundational build and runtime environment for the application on both platforms.
(repo-wide) · high confidence
Initial iOS and Web platform scaffolding for the MVVM Cubit architecture
This commit introduces the foundational project files for the iOS and Web targets of the 'MVVM Version (Cubit)' application. On iOS, it adds the standard Xcode project structure, including the \project.pbxproj\ build configuration, \AppDelegate.swift\ entry point, \Info.plist\ with the app name 'mvvm\_cubit', and asset catalogs for app icons and launch screens. For the Web target, it adds the \index.html\ entry point and \manifest.json\ for progressive web app support. These files establish the native host environments required to run the Flutter/Cubit application on both platforms.
\#8 - MVVM Version (Cubit)/ios, \#8 - MVVM Version (Cubit)/web · high confidence
Initial iOS and Web platform support for the MVVM GetX architecture
The iOS and Web platforms are now fully configured for the MVVM GetX architecture. On iOS, the project includes the standard Flutter runner configuration, including the Xcode project structure, build phases, and asset catalogs for the app icon and launch screen. For the web, the entry point and a Progressive Web App manifest are added, enabling the Flutter application to run in a browser with proper icons and metadata.
\#9 - MVVM Version (GetX)/ios, \#9 - MVVM Version (GetX)/web · high confidence
Initial implementation of Post and User data layers
Added the data layer for the Post and User features, including remote data sources, repository implementations, and data models with JSON serialization. This introduces the initial API integration for creating, updating, and deleting posts and users, as well as fetching them with optional filtering by gender and status for users.
\#5 - Clean Architecture Version (Cubit)/lib/features/post/data, \#5 - Clean Architecture Version (Cubit)/lib/features/user/data · high confidence
Initial implementation of Post and User features using Clean Architecture with RxDart and Provider
This change introduces the complete implementation for Post and User features, structured according to Clean Architecture principles. For Posts, it adds domain entities, repositories, and use cases for creating, updating, and deleting posts, along with a PostBloc for state management. Similarly, it adds the full stack for User management, including entities, repositories, and use cases for CRUD operations, managed by a UserBloc. The presentation layer includes screens for listing, creating, and viewing details of posts and users, utilizing RxDart streams and Provider for reactive UI updates.
\#10 - Clean Architecture Version (RxDart + Provider)/lib/features/post, \#10 - Clean Architecture Version (RxDart + Provider)/lib/features/user · high confidence
Initial implementation of comment feature using Clean Architecture and Cubit
The comment feature has been implemented following a Clean Architecture pattern with a Cubit presentation layer. This includes domain entities and repositories for comments, data sources and models for remote API interaction, and specific use cases for creating, deleting, and retrieving comments. The presentation layer utilizes a CommentCubit to manage state and interact with the use cases, providing methods to fetch, create, and delete comments.
(repo-wide) · high confidence
Initial implementation of post management screens and controller
Added the initial Clean Architecture (GetX) implementation for the post feature, introducing the PostController and four presentation screens: PostListScreen, PostDetailScreen, and CreatePostScreen. The controller exposes a global failureOrSuccess field to facilitate unit testing, while the screens utilize the AsyncWidget helper to manage API call states and display loading, success, and error conditions to the user.
\#6 - Clean Architecture Version (Getx)/lib/features/post/presentation · high confidence
Initial user management UI and controller
Added the UserListScreen, UserController, and StatusContainer widget to the app. The controller exposes methods for creating, updating, and deleting users, while the screen provides a list of users with options to edit, delete, or view posts and todos for each user. The status container visually indicates user active/inactive states.
\#6 - Clean Architecture Version (Getx)/lib/features/user/presentation · high confidence
Introduce Bloc-based layered architecture for the app entry point
The application entry point (main.dart) has been updated to initialize the app using the Flutter Bloc pattern. This includes setting up a MultiBlocProvider to manage state for User, Todo, Post, and Comment features, and supporting dynamic backend selection at startup via environment variables.
\#3 - Layered Architecture Version (Bloc)/lib · high confidence
Introduce Clean Architecture data layer for posts
Added the data layer for the Post feature, including the PostRemoteDataSource with a DioClient dependency for network calls, a Post model with JSON serialization and equality support, and a PostRepositoryImpl that wraps data source calls with error handling.
\#6 - Clean Architecture Version (Getx)/lib/features/post/data · high confidence
Introduce Clean Architecture with Bloc state management and dependency injection
The application now implements a Clean Architecture structure using the Flutter BLoC pattern for state management. A new dependency injection setup via GetIt wires up repositories, use cases, and BLoCs for User, Todo, Post, and Comment features. The app entry point initializes this DI container and configures the backend environment at startup, allowing the app to dynamically select the backend environment based on build-time environment variables.
\#4 - Clean Architecture Version (Bloc)/lib · medium confidence
Introduce Clean Architecture with Cubit for post management
Users can now create, update, and delete posts, as well as view post details and comments through a new presentation layer built on the Cubit state management pattern. This includes a post list screen, a post detail screen with comment support, and a create/update screen that handles both creation and editing modes.
\#5 - Clean Architecture Version (Cubit)/lib/features/post/presentation · high confidence
Introduce Cubit-based Todo list view with state-driven UI updates
The Todo list screen now uses a Flutter BLoC/Cubit architecture to manage and display todo items. The view integrates with a TodoCubit to fetch, create, and update todos, displaying status-based UI states (loading, success, failure) via a dialog. The list items are rendered using a dedicated TodoListItem widget, which has been refactored to support the new state management approach. A new CircleContainer widget is also introduced for visual styling.
\#2 - Layered Architecture Version (Cubit)/lib/features/todo/view · high confidence
Introduce Cubit-based post feature with layered architecture
The post feature is now implemented using the Cubit state management pattern, introducing a new \PostCubit\ that handles CRUD operations (create, update, delete, and fetch) by delegating to a \PostApi\ remote provider. This is supported by a new \Post\ data model with JSON serialization and a suite of Flutter screens (\PostListScreen\, \PostDetailScreen\, \CreatePostScreen\) that consume the cubit to display post lists, individual post details with comments, and forms for creating or updating posts.
\#2 - Layered Architecture Version (Cubit)/lib/features/post · high confidence
Introduce GetX-based MVVM architecture with dependency injection
The application now uses a GetX-based MVVM architecture, featuring a new dependency injection setup via GetIt that registers API clients, repositories, and view controllers. The app entry point initializes this DI container and supports dynamic backend selection at startup through the BACKEND environment variable, allowing the app to load configuration for different environments (e.g., staging vs. production) before launching the UI.
\#9 - MVVM Version (GetX)/lib · medium confidence
Introduce MVVM architecture using Cubit and dependency injection
The application now uses a new MVVM architecture based on the Cubit pattern, with a dedicated dependency injection setup via GetIt. This includes registering repositories, API clients, and Cubits, and wiring them into the Flutter widget tree using MultiBlocProvider.
\#8 - MVVM Version (Cubit)/lib · high confidence
Introduce MVVM architecture with Bloc state management and dependency injection
The application now uses an MVVM architecture with the BLoC pattern for state management, replacing previous implementations. A new dependency injection setup using GetIt is introduced in di.dart, registering repositories, API clients, and BLoCs. The main entry point initializes the dependency injection and configures MultiBlocProvider to supply UserBloc, TodoBloc, PostBloc, and CommentBloc to the Flutter widget tree.
\#7 - MVVM Version (Bloc)/lib · high confidence
Introduce MVVM architecture with Cubit for Posts, Todos, and Users
A new MVVM implementation using the Cubit state management pattern has been added to the app, providing new screens for managing posts, todos, and users. Users can now create, update, and delete posts and todos, as well as manage user profiles, with all state changes handled through dedicated Cubits (PostCubit, TodoCubit, UserCubit). The UI includes list views, detail screens, and creation/update forms that interact with the new architecture.
\#8 - MVVM Version (Cubit)/lib/view · high confidence
Introduce MVVM architecture with Cubit-based viewmodels and repositories
Added a new MVVM (Model-View-ViewModel) architecture using the Flutter BLoC/Cubit pattern. This includes a reusable \GenericCubit\ and \GenericCubitState\ in the common layer, along with specific Cubits (e.g., \PostCubit\, \UserCubit\) that manage state for their respective domains. Corresponding repositories (e.g., \PostRepository\, \UserRepository\) were added to handle data fetching and API interactions, providing a structured way to manage application state and business logic.
\#7 - MVVM Version (Bloc)/lib/repository, \#7 - MVVM Version (Bloc)/lib/viewmodel, \#8 - MVVM Version (Cubit)/lib/common/cubit, \#8 - MVVM Version (Cubit)/lib/repository, \#8 - MVVM Version (Cubit)/lib/viewmodel · high confidence
Introduce MVVM architecture with GetX for post, todo, and user screens
The application now implements an MVVM architecture using the GetX state management library. This change introduces new screen components for managing posts, todos, and users, each utilizing GetX controllers for state management. The screens feature improved UI with consistent styling, error handling via retry dialogs, and loading states. The implementation includes new widgets for todo items and status containers, and refactors existing screens to use GetX's reactive programming model, enhancing code organization and maintainability.
\#9 - MVVM Version (GetX)/lib/view · high confidence
Introduce Todo feature with Cubit state management
The Todo feature is now implemented using the Cubit state management pattern. This includes a new TodoCubit that manages the state for creating, updating, and deleting todos, along with the corresponding presentation layer containing the TodoListScreen, TodoListItem widget, and CircleContainer widget. The UI allows users to view, add, edit, and remove tasks, with state changes handled through the Cubit architecture.
\#5 - Clean Architecture Version (Cubit)/lib/features/todo/presentation · high confidence
Introduce environment-based API configuration and core utilities
The app now supports switching between backend environments (GoRest and Spring Boot) via JSON config files loaded from assets. This is enabled by new core files: \app\_config.dart\ (loads environment-specific URLs and API keys), \api\_config.dart\ (provides static API endpoints and headers), \app\_asset.dart\ (defines asset paths for configs and images), \app\_string.dart\ (error messages and environment keys), \app\_style.dart\ (logging and style constants), and \app\_theme.dart\ (Material 2 theming with explicit \useMaterial3: false\). These changes allow the application to dynamically configure its API base URL and authentication headers based on the selected backend environment.
\#9 - MVVM Version (GetX)/lib/core · high confidence
Introduce environment-based configuration and core utilities for the Cubit architecture
The core layer now supports loading backend configuration from JSON files (GoRest or Spring Boot) via a new AppConfig and ConfigLoader, allowing the app to dynamically adjust its base URL and API keys based on the selected environment. Additionally, the codebase adds several utility extensions (for strings, iterables, maps, and integers), a centralized AppAsset class for managing image and config paths, and an AppStyle file that defines reusable text styles, input borders, and a logger. These changes provide the foundational configuration and helper tools required by the rest of the application.
\#2 - Layered Architecture Version (Cubit)/lib/core · high confidence
Introduce generic Cubit for common API operations
Added a reusable GenericCubit and its associated state class to handle standard CRUD operations (create, update, delete, select) via a template method pattern. This provides a consistent way to manage loading, success, failure, and empty states for any data type T, reducing duplication across feature-specific Cubits.
\#5 - Clean Architecture Version (Cubit)/lib/common/cubit · high confidence
Introduce new MVVM/Cubit network layer with structured error handling
A new network infrastructure has been added to the application, introducing a structured approach to API interactions. This includes an \ApiHelper\ mixin for standard HTTP methods, a \DioClient\ wrapper for configuring the Dio HTTP client, and a \DioInterceptor\ for logging requests and responses. Error handling is centralized via a \DioExceptions\ class that maps HTTP status codes and Dio errors to user-friendly messages. Additionally, a generic \ApiResult\<T\>\ type (generated via Freezed) and a \RepositoryHelper\ mixin are provided to standardize success/failure states across the repository layer.
\#8 - MVVM Version (Cubit)/lib/common/network · high confidence
Introduce new network layer with Dio v5 compatibility
Added a new network abstraction for the Clean Architecture GetX version, including \ApiBase\ for generic HTTP request templates, \ApiConfig\ for environment-based base URLs and headers, a \DioClient\ wrapper around the Dio package to improve testability, and a \DioInterceptor\ for logging requests and responses. The implementation is explicitly compatible with Dio v5.2 and Dart v3.0.0, and the \RepositoryHelper\ mixin uses \Either\ types to handle success/failure states for API calls.
\#6 - Clean Architecture Version (Getx)/lib/common/network · high confidence
Introduce post management screens and BLoC for the Clean Architecture (Bloc) version
The post feature is now implemented using the BLoC pattern, introducing a new \PostBloc\ that handles fetching, creating, updating, and deleting posts. This is supported by corresponding event classes (\PostFetched\, \PostCreated\, \PostUpdated\, \PostDeleted\) and three new UI screens: \PostListScreen\ to display all posts, \PostDetailScreen\ to view a single post and its comments, and \CreatePostScreen\ to add or edit posts. The implementation leverages a shared \GenericBlocBuilder\ widget to manage loading, success, and error states across these screens.
\#4 - Clean Architecture Version (Bloc)/lib/features/post/presentation · medium confidence
Introduce user data layer with remote data source and repository
Added the user feature's data layer, including a UserRemoteDataSource for API communication, a User model for JSON serialization, and a UserRepositoryImpl that bridges the data source to the domain layer. This provides the foundational data access for user-related operations.
\#4 - Clean Architecture Version (Bloc)/lib/features/user/data · high confidence
Introduce user management capabilities via a new layered architecture implementation
Added a complete user feature implementation using the Bloc state management pattern, including the UserBloc for handling events (fetching, creating, updating, and deleting users), user data models with JSON serialization, a remote API provider for network calls, and the corresponding UI screens and widgets for displaying and managing user lists.
\#3 - Layered Architecture Version (Bloc)/lib/features/user · high confidence
Introduced new network layer with Dio v5 and Freezed-based result handling
The network layer has been restructured to use the Dio HTTP client for making requests, with a new \DioClient\ singleton and \DioInterceptor\ for logging. Error handling is now managed through a \DioExceptions\ class that maps Dio errors to user-friendly messages. Additionally, a new \ApiResult\<T\>\ type, generated via Freezed, provides a consistent way to handle API success and failure states across the application.
\#3 - Layered Architecture Version (Bloc)/lib/common/network · high confidence
Introduces a new network layer with structured error handling and API result types
A new network implementation is introduced for the MVVM Bloc version, featuring a structured \ApiResult\<T\>\ type (success/failure) and a \DioExceptions\ class that maps HTTP status codes and Dio errors to user-friendly messages. The \ApiHelper\ mixin provides generic request methods (GET, POST, PUT, DELETE) that leverage this result type, while \RepositoryHelper\ wraps API calls to return \ApiResult\ states, allowing the UI to react to both successful data and specific error conditions.
\#7 - MVVM Version (Bloc)/lib/common/network · high confidence
Introduces clean architecture with RxDart and Provider for state management
The app now uses a clean architecture structure with RxDart for reactive streams and Provider for state management. Dependency injection is handled via GetIt, wiring up BLoC-style components for users, todos, posts, and comments. The main entry point initializes the DI container and configures the app with dynamic backend selection at startup, supporting environment-based configuration loading.
\#10 - Clean Architecture Version (RxDart + Provider)/lib · high confidence
Introduces common UI widgets and network utilities for the Clean Architecture implementation
Adds a suite of reusable UI components including dialogs (create, delete, progress, retry), a generic BLoC state model, and network infrastructure (Dio client, interceptors, and API helpers) to support the Clean Architecture version of the app. This includes new widgets for date/time selection, dropdowns, text inputs, and empty states, alongside the \ApiResult\ type and repository helpers that standardize how the app handles API responses and errors.
\#10 - Clean Architecture Version (RxDart + Provider)/lib/common · high confidence
Introduces core configuration and theming infrastructure
The app now supports loading environment-specific backend configurations (GoRest and Spring Boot) from local JSON assets, allowing the application to dynamically connect to different API backends. Additionally, the core library introduces a centralized theming system with reusable style constants and a logger, while explicitly disabling Material 3 to maintain the existing visual design.
\#5 - Clean Architecture Version (Cubit)/lib/core · high confidence
Introduces environment-based configuration and API client setup
The core module now supports loading backend configuration from JSON assets for different environments (GoRest and Spring Boot), allowing the application to dynamically switch API endpoints and authentication headers based on the selected environment. This includes new files for configuration loading, asset paths, string constants, and API header management, alongside a centralized logger and style definitions.
\#7 - MVVM Version (Bloc)/lib/core · high confidence
Introduces new shared UI widgets and modernizes existing ones
Adds three new reusable widgets to the common library: AsyncWidget for handling API states (loading, failure, success) with retry and success callbacks, DateTimePicker for selecting date and time, and DropDown for selecting from a list of items. Additionally, existing widgets are updated: TextInput gains support for icons, controllers, and auto-validation modes; EmptyWidget and PopupMenu are refactored to use modern Flutter constructors and updated styling.
\#1 - Layered Architecture Version (GetX)/lib/common/widget · high confidence
New MVVM Bloc-based user list screen and status widget
The application now includes a new implementation of the user list interface using the MVVM architecture with the Bloc state management pattern. This change introduces the \UserListScreen\ component, which displays a list of users and allows users to create, edit, and delete user profiles. The UI is powered by the \UserBloc\ to handle state changes for operations like fetching, creating, and deleting users. Additionally, a new \StatusContainer\ widget has been added to visually represent a user's status (active or inactive) with distinct color coding.
\#7 - MVVM Version (Bloc)/lib/view/user · high confidence
New Todo List screen with async API handling
A new Todo List screen has been added to the application, providing the user interface for viewing, creating, and updating tasks. The screen integrates with the GetX state management layer and includes a reusable \AsyncWidget\ component to manage the loading, success, and error states of API calls, ensuring a smoother user experience during data fetching and task operations.
\#6 - Clean Architecture Version (Getx)/lib/features/todo/presentation/screens · high confidence
New common widget components for the Cubit architecture version
The \lib/common/widget\ directory now includes several new reusable UI components: a \DateTimePicker\ for selecting date and time, a generic \DropDown\ for list selection, an \EmptyWidget\ for displaying empty states, a \PopupMenu\ for contextual actions, a \SpinKitIndicator\ for loading states, and a \TextInput\ for form fields. These widgets provide standardized, reusable building blocks for the application's user interface.
\#2 - Layered Architecture Version (Cubit)/lib/common/widget · high confidence
New core configuration and styling infrastructure
The app introduces a new core module to manage application settings and UI consistency. An \AppConfig\ class and \ConfigLoader\ singleton now load backend URLs and API keys from environment-specific JSON files (Gorest or Spring Boot), enabling runtime configuration switching. Additionally, \AppStyle\ centralizes text styles, input border themes, and a shared color palette, while \AppTheme\ defines the global Material 2 theme with disabled Material 3 support. Utility extensions for string formatting, HTTP status checking, and map serialization are also added to the core layer.
\#10 - Clean Architecture Version (RxDart + Provider)/lib/core, \#6 - Clean Architecture Version (Getx)/lib/core · high confidence
Removals
Removal of the Flutter-based user management application
The entire Flutter application for managing users, posts, and todos via the Gorest API has been removed. This includes the main entry point, all feature modules (user, post, todo, comment), their respective controllers, API providers, and the README documentation. Users will no longer have access to this specific implementation of the layered architecture pattern for this project.
(repo-wide) · high confidence
Behavioural changes
Add Flutter project configuration and analysis settings
The project directory now includes standard Flutter configuration files: a .gitignore to exclude build artifacts and IDE files, a .metadata file tracking the Flutter stable channel version and migration state, an analysis\_options.yaml file that enables Flutter's recommended lints, and a README.md that links to the main project documentation.
\#8 - MVVM Version (Cubit) · medium confidence
Add app entry point with dynamic backend selection
The application now supports selecting the backend environment at startup via the 'BACKEND' environment variable, defaulting to 'gorest'. This change introduces the main entry point that initializes the Flutter binding, loads the configuration for the selected environment, and launches the user list screen.
\#1 - Layered Architecture Version (GetX)/lib · medium confidence
Comment controller refactored for improved testability
The CommentController now exposes the failureOrSuccess state as a global, visible variable to facilitate unit testing of the controller's logic. This change makes it easier to verify the outcome of operations like fetching or creating comments in isolation.
\#6 - Clean Architecture Version (Getx)/lib/features/comment/presentation · medium confidence
Core app configuration and styling updates
The core module introduces environment-based configuration loading via AppConfig and ConfigLoader, supporting both GoRest and Spring Boot backends. The app's visual style is centralized in app\_style.dart, and the global theme is defined in app\_theme.dart, which explicitly sets useMaterial3 to false and replaces the deprecated DialogTheme with DialogThemeData. Additionally, asset paths for backend JSON configs are added to app\_asset.dart, and various utility extensions and string constants are introduced to support these changes.
\#4 - Clean Architecture Version (Bloc)/lib/core · medium confidence
Core configuration and styling updates
The core module introduces environment-based configuration loading via AppConfig and ConfigLoader, allowing the app to load settings from JSON assets for GoRest and Spring backends. A new ApiConfig class manages base URLs, timeouts, and headers. The app theme is updated to disable Material 3 (useMaterial3: false) and uses DialogThemeData instead of the deprecated DialogTheme. Additionally, the logger is moved to app\_style.dart, and the Map extension's format method is fixed to handle multiple query parameters correctly.
\#1 - Layered Architecture Version (GetX)/lib/core · high confidence
Initial Clean Architecture implementation for the Comment feature
The Comment feature is introduced with a full Clean Architecture structure, including a remote data source that accepts a Dio client for easier unit testing, a repository implementation that wraps data source calls with success/failure handling, and a Comment model class equipped with equality and hash code overrides to support unit testing.
\#6 - Clean Architecture Version (Getx)/lib/features/comment/data · medium confidence
Introduce Cubit-based layered architecture with dynamic backend selection
The app now uses a Cubit-based layered architecture, with the main entry point initializing a dynamic backend environment at startup via the 'BACKEND' compile-time environment variable, which is then loaded into the configuration. The application registers global BLoC/Cubit providers for User, Todo, Post, and Comment features, each wired to their respective Cubits, and renders the UI using a shared AppTheme and a default UserListScreen.
\#2 - Layered Architecture Version (Cubit)/lib · medium confidence
Introduce GetX-based user management interface with async feedback
The user list screen has been rewritten using GetX for state management, replacing the previous implementation. This change introduces an AsyncWidget component that provides visual feedback (progress, success, and error states) for API calls such as creating, updating, and deleting users. The UI now leverages GetX controllers and reactive bindings to manage user data and operation statuses, improving the responsiveness and user experience during network requests.
\#1 - Layered Architecture Version (GetX)/lib/features/user/view · medium confidence
Introduce base controller for common API state management
A new base controller mixin has been added to the application's common controller layer, providing a standardized way to manage API states (loading, failure, success) and error messages. This mixin implements a template method pattern to handle API operations, reducing code duplication across different controllers by centralizing the logic for checking failure or success conditions and updating the UI state accordingly.
\#6 - Clean Architecture Version (Getx)/lib/common/controller · high confidence
Introduce new MVVM/GetX network layer with Dio v5 and freezed
A new network infrastructure for the MVVM (GetX) version of the app has been added, introducing a modernized HTTP client and result handling. The \Dio\ library has been upgraded to v5, with the \DioClient\ class now configuring the client using \ApiConfig\ for base URLs, headers, and timeouts. Error handling is centralized in \DioExceptions\, which maps \DioException\ types and HTTP status codes to user-friendly messages. Additionally, \ApiResult\<T\>\ is introduced as a \freezed\-generated sealed class to represent API outcomes, and \ApiHelper\ provides generic request templates (GET, POST, PUT, DELETE) that leverage the new error and result types.
\#9 - MVVM Version (GetX)/lib/common/network · high confidence
Introduce shared base controller for feature controllers
The Todo and User feature controllers now extend a new generic base controller class (BaseController) that provides common state management and CRUD helper methods (createItem, updateItem, deleteItem). This change standardizes how controllers handle loading, success, empty, and error states using GetX's StateMixin, reducing duplication across feature controllers.
\#1 - Layered Architecture Version (GetX)/lib/features/todo/controller, \#1 - Layered Architecture Version (GetX)/lib/features/user/controller · medium confidence
Introduces a base controller mixin for standardized API state management
A new \BaseController\ mixin is added to \lib/common/controller/base\_controller.dart\, providing a shared implementation for managing API loading, success, and failure states using GetX's reactive types. This change introduces a template method pattern that automatically updates the \apiStatus\ and \errorMessage\ based on the result of API callbacks, reducing code duplication across controllers that perform create, update, or delete operations.
\#1 - Layered Architecture Version (GetX)/lib/common/controller · medium confidence
Introduces a new network layer with Dio v5 and structured error handling
Adds a new network implementation using the Dio HTTP client (v5) to handle API requests and responses. This includes a centralized \ApiBase\ class for making requests, a \DioClient\ singleton for managing the HTTP client, and a \DioInterceptor\ for logging. The change also introduces an \ApiResult\ type for handling success and failure states, and a \DioExceptions\ class that maps Dio errors to user-friendly messages, fixing the issue where no internet connection messages were not displaying after the upgrade.
\#2 - Layered Architecture Version (Cubit)/lib/common/network · high confidence
Introduces environment-based configuration and updated UI themes
The core module now supports loading backend configuration from JSON assets (GoRest or Spring Boot) via a new \AppConfig\ and \ConfigLoader\ system, allowing the app to dynamically adjust its base URL and API keys based on the selected environment. Additionally, the app's visual style has been updated to use \DialogThemeData\ and \WidgetStateColor\ for consistent theming, while explicitly disabling Material 3 to maintain the existing UI behavior.
\#8 - MVVM Version (Cubit)/lib/core · high confidence
Migrate networking layer to Dio v5 and introduce ApiBase template
The common/network layer has been refactored to support Dio v5. A new abstract ApiBase class provides generic HTTP method templates (GET, POST, PUT, DELETE) that handle success and failure states, while the existing DioClient and DioInterceptor have been updated to align with the new API, including a change from DioError to DioException and adjusted logging levels.
\#1 - Layered Architecture Version (GetX)/lib/common/network · high confidence
New network layer with environment-based configuration and improved error handling
The app introduces a new network infrastructure in the common layer, featuring an ApiConfig that loads the base URL and API key from a central ConfigLoader, allowing environment-specific settings. The Dio HTTP client is initialized with these headers and timeouts, and a new ApiResult type (success/failure) is used to wrap API responses. Error handling is improved with a dedicated DioExceptions class that maps HTTP status codes and Dio errors to user-friendly messages, ensuring that network failures (such as no internet connection) are properly caught and displayed to the user.
\#4 - Clean Architecture Version (Bloc)/lib/common/network, \#5 - Clean Architecture Version (Cubit)/lib/common/network · high confidence
Post feature refactored to GetX architecture with unified API state widget
The Post feature has been migrated to a GetX-based layered architecture. A new PostController manages API interactions, and the view layer now uses a shared AsyncWidget to handle loading, success, and error states for API calls, replacing previous switch-based status handling. The PostListScreen no longer supports swipe-to-delete or edit via swipe; instead, it navigates to a PostDetailScreen for viewing and editing, and uses the new controller for data fetching.
\#1 - Layered Architecture Version (GetX)/lib/features/post/view · high confidence
Refactor feature modules to use shared ApiBase and BaseController
The comment, post, and user feature modules have been refactored to adopt a shared architecture: remote API classes (CommentApi, PostApi, UserApi) now extend a new ApiBase class that centralizes HTTP request handling, while their respective controllers extend a new BaseController that standardizes item creation and deletion logic. Additionally, manual JSON serialization helpers (fromJson/toJson) have been removed from the data models, relying instead on code generation. This change simplifies the implementation of new features by reusing common networking and controller patterns.
\#1 - Layered Architecture Version (GetX)/lib/features/comment, \#1 - Layered Architecture Version (GetX)/lib/features/post/data, \#1 - Layered Architecture Version (GetX)/lib/features/user/data · high confidence
Renamed Layered Architecture folder to specify GetX implementation
The project directory for the simple layered architecture version using GetX has been renamed from "\#1 - Layered Architecture" to "\#1 - Layered Architecture Version (GetX)". This change clarifies that this specific folder contains the GetX-based implementation of the layered architecture, distinguishing it from other state management solutions like Bloc or Cubit in the same project structure.
\#1 - Layered Architecture Version (GetX) · high confidence
Restructured Todo data layer with new API provider
The Todo feature's data layer has been reorganized. A new remote API provider (todo\_api.dart) was added to handle HTTP requests for creating, updating, and deleting todos, delegating the actual network calls to a shared ApiBase class. The Todo model and its generated serialization code were moved to the data layer, and unused JSON parsing utilities were removed.
\#1 - Layered Architecture Version (GetX)/lib/features/todo/data · medium confidence
Rewrite of the Todo List screen with improved async handling
The Todo List screen has been rewritten to use a generic base controller and includes an \AsyncWidget\ for easier API call handling in the UI. The implementation now uses a \Mode\ enum to distinguish between create and update operations, and integrates with the \ToDoController\ to manage state and API status.
\#1 - Layered Architecture Version (GetX)/lib/features/todo/view/screen · medium confidence
Support environment-based API configuration and update UI components
The app now loads the API base URL and authentication headers dynamically from environment-specific JSON configuration files (GoRest or Spring Boot) via a new AppConfig system. This allows the application to connect to different backend services based on the selected environment. Additionally, the codebase has been updated to support Flutter 3.27.0, which includes migrating the Dio HTTP client to version 5 and replacing deprecated Material 2 components (such as DialogTheme and MaterialStateColor) with their Material 3 and WidgetState equivalents.
\#3 - Layered Architecture Version (Bloc)/lib/core · high confidence
Updated Android build configuration and added internet permission
The Android module has been renamed to reflect the GetX architecture version. The Gradle build tool has been upgraded from version 7.4 to 9.6.0. Additionally, the INTERNET permission has been explicitly added to the AndroidManifest.xml, ensuring the app can access the network.
\#1 - Layered Architecture Version (GetX)/android · medium confidence
iOS and web project directories renamed to specify GetX architecture
The iOS and web project directories have been renamed from '\#1 - Layered Architecture' to '\#1 - Layered Architecture Version (GetX)'. This change updates the folder structure to explicitly indicate that this version of the application utilizes the GetX state management and routing solution, distinguishing it from previous iterations or other architectural approaches.
\#1 - Layered Architecture Version (GetX)/ios, \#1 - Layered Architecture Version (GetX)/web · high confidence
Test coverage
Added code coverage reports for common modules; Added unit tests for network, repository, and extension utilities; Added unit tests for the Post feature.
Dependencies
Updated Android build configuration and Dart dependencies
The Android build configuration has been migrated to the declarative plugins block in settings.gradle, specifying Android Gradle plugin 9.0.1, Kotlin 2.3.20, and the Flutter Gradle plugin 1.0.0. Additionally, the Dart package lockfile (pubspec.lock) has been updated to resolve the latest compatible versions for all transitive and direct dependencies, including the Dio HTTP client.
(dependencies) · high confidence
Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.
How this codebase got here
Score
- CAI 48 → 43 (-5.1)
- Rubric changed (rubric-2026.08.19 → rubric-2026.09.15) — scores are not directly comparable.
Lenses
- Code Health 100 → 93 (-7.4)
- Architecture 99 → 96 (-2.9)
- Maturity 63 → 63 (+0.0)
- Readiness 36 → 24 (-11.8)
- Security 67 → 75 (+8.3)
- Domain Modelling 100 → 100 (+0.0)
- Accessibility 40 → 40 (+0.0)
Resolved (21)
- Change coupling clique: comment_api.dart, post_api.dart, user_api.dart (#1 - Layered Architecture Version (GetX)/lib/features/comment/data/provider/remote/comment_api.dart)
- Change coupling: create_post_screen.dart ↔ todo_list_screen.dart (#1 - Layered Architecture Version (GetX)/lib/features/post/view/screen/create_post_screen.dart)
- Change coupling: create_post_screen.dart ↔ user_list_screen.dart (#1 - Layered Architecture Version (GetX)/lib/features/post/view/screen/create_post_screen.dart)
- Change coupling: post_detail_screen.dart ↔ user_list_screen.dart (#1 - Layered Architecture Version (GetX)/lib/features/post/view/screen/post_detail_screen.dart)
- Change coupling: post_list_screen.dart ↔ todo_list_screen.dart (#1 - Layered Architecture Version (GetX)/lib/features/post/view/screen/post_list_screen.dart)
- Dependency hygiene not measured — dependency manifest found but not parsed for hygiene
- No exposed public API
- Secret: generic-api-key (#1 - Layered Architecture Version (GetX)/asset/config/gorest_config.json)
- Secret: generic-api-key (#10 - Clean Architecture Version (RxDart + Provider)/asset/config/gorest_config.json)
- Secret: generic-api-key (#2 - Layered Architecture Version (Cubit)/asset/config/gorest_config.json)
- Secret: generic-api-key (#3 - Layered Architecture Version (Bloc)/asset/config/gorest_config.json)
- Secret: generic-api-key (#4 - Clean Architecture Version (Bloc)/asset/config/gorest_config.json)
- Secret: generic-api-key (#5 - Clean Architecture Version (Cubit)/asset/config/gorest_config.json)
- Secret: generic-api-key (#6 - Clean Architecture Version (Getx)/asset/config/gorest_config.json)
- Secret: generic-api-key (#7 - MVVM Version (Bloc)/asset/config/gorest_config.json)
- Secret: generic-api-key (#8 - MVVM Version (Cubit)/asset/config/gorest_config.json)
- Secret: generic-api-key (#9 - MVVM Version (GetX)/asset/config/gorest_config.json)
- Test reliability not included
- The main README links to itself for setup documentation ("For full information...please see the main project README") across several subsections, which is a standard cross-linking convention but does not add value beyond pointing readers to the single source of truth. (README.md)
- complexity unreadable for .dart, .kt, .swift — churn × complexity hotspots could not be measured
- …and 1 more
New (344)
- Dependency hygiene PARTLY measured — Maven/Gradle declarations read, no dependency graph resolved
- Duplicated block (10 lines × 10) (#1 - Layered Architecture Version (GetX)/lib/common/widget/drop_down.dart)
- Duplicated block (10 lines × 10) (#1 - Layered Architecture Version (GetX)/lib/core/api_config.dart)
- Duplicated block (10 lines × 10) (#1 - Layered Architecture Version (GetX)/lib/features/todo/view/screen/todo_list_screen.dart)
- Duplicated block (10 lines × 2) (#10 - Clean Architecture Version (RxDart + Provider)/lib/features/todo/presentation/screens/todo_list_screen.dart)
- Duplicated block (10 lines × 2) (#2 - Layered Architecture Version (Cubit)/lib/features/todo/view/screen/todo_list_screen.dart)
- Duplicated block (10 lines × 2) (#3 - Layered Architecture Version (Bloc)/lib/features/todo/view/screen/todo_list_screen.dart)
- Duplicated block (10 lines × 2) (#3 - Layered Architecture Version (Bloc)/lib/features/user/view/screen/user_list_screen.dart)
- Duplicated block (10 lines × 2) (#4 - Clean Architecture Version (Bloc)/lib/main.dart)
- Duplicated block (10 lines × 2) (#5 - Clean Architecture Version (Cubit)/lib/main.dart)
- Duplicated block (10 lines × 3) (#2 - Layered Architecture Version (Cubit)/lib/common/cubit/generic_cubit.dart)
- Duplicated block (10 lines × 3) (#3 - Layered Architecture Version (Bloc)/lib/common/bloc/bloc_helper.dart)
- Duplicated block (11 lines × 10) (#1 - Layered Architecture Version (GetX)/lib/common/widget/empty_widget.dart)
- Duplicated block (11 lines × 2) (#10 - Clean Architecture Version (RxDart + Provider)/lib/features/user/presentation/screens/user_list_screen.dart)
- Duplicated block (11 lines × 2) (#2 - Layered Architecture Version (Cubit)/lib/features/todo/data/provider/remote/todo_api.dart)
- Duplicated block (11 lines × 2) (#7 - MVVM Version (Bloc)/lib/repository/comment/comment_repository.dart)
- Duplicated block (11 lines × 3) (#1 - Layered Architecture Version (GetX)/lib/features/user/view/screen/user_list_screen.dart)
- Duplicated block (11 lines × 3) (#2 - Layered Architecture Version (Cubit)/lib/features/todo/view/screen/todo_list_screen.dart)
- Duplicated block (11 lines × 3) (#2 - Layered Architecture Version (Cubit)/lib/features/user/view/screen/user_list_screen.dart)
- Duplicated block (11 lines × 4) (#10 - Clean Architecture Version (RxDart + Provider)/lib/common/repository/repository_helper.dart)
- …and 324 more
Architecture
- Unchanged — 0 containers · 1 contexts · 0 edges
Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.
Survey your own repository
SinaSys/flutter_go_rest_app 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.
About this page
- The score is its most recent published measurement, taken on 21 September 2026 at a pinned commit. It is not a live figure and does not change until the project is measured again.
- Measured at commit 9bab542dafa83b0dca422c41c923a55303e1b853 — the exact code this score is about.
- Scored under rubric-2026.09.15 — the same rubric and the same method as every other entry in this index.
- Measured by watchdog.canine.dev using codehealth-analyzer preprod-fa71c66cabd8.