Create splash view body

Presentation (Building the UI)

05:58

Summary

This lesson establishes the foundational folder structure for a feature-driven Clean Architecture implementation in Flutter, focusing specifically on the Presentation layer. The instructor demonstrates how to isolate the Splash screen into its own feature module and creates the initial SplashView widget. Along the way, the underlying philosophy of separating the UI components from state management within the presentation layer is explained, setting the stage for scalable feature development.

Key Ideas

Features represent independent modules containing a specific screen or a cohesive set of related screens.
The Presentation layer within a feature is strictly responsible for the user interface and its immediate state.
The Presentation folder is explicitly divided into views (for UI widgets) and manager (for state management tools like Bloc/Cubit).
GetMaterialApp from the GetX package is used temporarily but will be replaced, as GetX is not recommended for core routing in large Clean Architecture projects.
UI and logic should be developed incrementally on a feature-by-feature basis rather than building the entire app's UI upfront.

Code Snippets

main.dart - Application entry point loading the SplashViewdart

import 'package:bookly/Features/splash/presentation/views/splash_view.dart';
import 'package:flutter/material.dart';
import 'package:get/get.dart';

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

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

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

Features/splash/presentation/views/splash_view.dart - Initial splash screen UIdart

import 'package:flutter/material.dart';

class SplashView extends StatelessWidget {
  const SplashView({super.key});

  @override
  Widget build(BuildContext context) {
    return const Placeholder();
  }
}

Architecture Insight

Architecture insight

The presentation/{views,manager}/ split is the CA-friendly shape for this layer:

`views/` holds pure widget code — declarative UI, no business logic.
`manager/` will eventually hold Cubits or Blocs — state machines that own *presentation state* (loading, error, success), kept out of widgets where they'd be untestable.

Even an empty manager/ folder is communicating intent: "state logic does not live in widgets." That intent matters more than the file count.

Looking ahead — When you wire BlocProvider in section 5, this is exactly where the Cubits will land.

My Notes

The instructor's explicit comment about removing GetX (GetMaterialApp) later in the course is a strong indicator of adhering to true Clean Architecture. GetX often tightly couples routing, dependency injection, and state management, which violates the separation of concerns Clean Architecture strives for.

Feature-First Organization: Nesting presentation/views/ inside Features/splash/ is industry standard for scalable Flutter apps.
The "Manager" Folder: Using a manager folder specifically for State Management (where Bloc or Cubit will eventually reside) keeps the views folder purely declarative.
[Editor's note] Even though the instructor deleted the manager folder temporarily because there is no state logic yet, it is best practice to keep these empty folders in a project scaffolding template to enforce the structure for future features.