Creating and structuring our project

Presentation (Building the UI)

31:21

Summary

This lesson focuses on the initial setup and directory structure of a Flutter project. The instructor emphasizes the practical benefits of building the user interface before implementing the underlying logic, arguing that it provides stakeholders with visible progress and tangible deliverables early in the development lifecycle. Additionally, the lesson introduces a feature-based folder architecture, dividing the lib directory into a core folder for shared utilities and a features folder for isolated, self-contained functional modules. This modular structure is presented as a crucial step for maintaining a clean, navigable, and scalable codebase as the application grows.

Key Ideas

User Interface (UI) should be developed before logic to provide clients with immediate, visible progress.
"Pubspec Assist" VS Code extension allows for quick addition of packages without manually editing the pubspec.yaml file.
get (GetX) package is introduced specifically for its streamlined, boilerplate-free routing and navigation capabilities.
GetMaterialApp replaces the standard MaterialApp widget at the root of the project to enable GetX navigation features.
lib directory is split into two primary folders: core and features to ensure scalability.
features folder isolates individual app functionalities (e.g., Home, Notifications) into self-contained directories to prevent file clutter.
Feature-based grouping prevents the confusion associated with grouping files by type (e.g., all views together or all controllers together).
core folder houses shared components, utilities, and widgets utilized across multiple features, adhering to the DRY (Don't Repeat Yourself) principle.

Code Snippets

Initializing the app with GetMaterialApp and setting the initial view.dart

import 'package:flutter/material.dart';
import 'package:get/get.dart';

void main() {
  runApp(const BooklyApp());
}

class BooklyApp extends StatelessWidget {
  const BooklyApp({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return GetMaterialApp(
      home: SplashView(),
    );
  }
}

Architecture Insight

Architecture insight

Feature-first folders (lib/features/<feature>/{domain,data,presentation}/) are the foundation that makes Clean Architecture tractable in Flutter. The alternative — type-first folders (lib/views/, lib/controllers/) — works for tiny apps but collapses under any real feature load: a single feature gets scattered across five places, and a teammate touching auth ends up reading four unrelated folders.

The split between `core/` (cross-cutting infrastructure) and `features/` (vertical slices) maps directly to a CA principle: stable abstractions go in core/, volatile feature work goes in features/. Code in core/ should never import from features/. The reverse is fine.

Looking ahead — When the Domain layer arrives, each feature folder will grow domain/{entities,repositories,usecases}/ and data/{models,datasources,repositories}/ siblings. The shape you set up here is what makes that incremental.

My Notes

UI vs. Domain First: The instructor makes a pragmatic point about real-world freelancing—clients want to see screens to feel like progress is happening. However, in enterprise Clean Architecture, the Domain layer is usually the starting point. It dictates what the application *does* independent of how it *looks*.
GetX Coupling: [Editor's note] Using GetMaterialApp right at the root is a common GetX shortcut, but it introduces a massive framework dependency. Clean Architecture aims to keep external frameworks at arm's length. If you ever want to swap out GetX for go_router or auto_route in the future, you will have to rewrite your root app widget and all navigation calls.
Feature-First Architecture: The shift to feature-based folders (lib/features/home, lib/features/search) rather than type-based folders (lib/views, lib/controllers) is an excellent and highly recommended practice for scaling Flutter applications.