Flutter: The Better Structure Example

✅ Disclaimer: This is a Better Pattern

This project is structured in a way to resolve the issues of the Bad Structured Conference App which was shown in the Open Conf 2025 Flutter workshop. This acts as an educational example of what to do in a Flutter application. It is designed to highlight best practices that help in building scalable, maintainable, and testable applications.

**You CAN use this project as a template for your own applications or use the Flutter Skeleton **

This approach is based on the structure proposed in:

• A Simple way to organize your code in Flutter
• A Simple way to organize your Styles & Themes in Flutter

---

About The Project

This is a simple conference application that displays information about:

• A home screen with event details
• A list of speakers
• The event agenda
• Conference sponsors

The app fetches data from local JSON files and displays it in various screens.

Why is This a "Better" Example?

As a project grows, its structure becomes crucial for maintainability, scalability, and collaboration. This project follows several best practices:

1. Feature-First Directory Structure

Files are grouped by feature (e.g., lib/screens/speakers/, lib/screens/agenda/).

• Benefit: This approach is highly scalable. When you work on a feature, all the related files (UI, logic, data) are in one place but separated to avoid complexity. This makes it easy to find files and understand the scope of a feature. It also helps in large teams where different developers might work on different features simultaneously.

2. Clear Separation of Concerns (Layered Architecture)

Each feature is divided into three distinct layers: data, logic, and presentation.

• Data Layer: Contains the models (the raw data structures). It's responsible for creating meaningful objects from JSON.

• Logic Layer: Contains the controllers (which handle business logic). This layer is independent of the UI and the data source, making it highly reusable and testable.

• Presentation Layer: Contains the screens and the widgets. It's responsible for displaying the UI and handling user input. It gets its state from the Logic layer.

• Benefit: This separation makes the code easier to read, test, and maintain. You can test your business logic without needing to render any UI. You can also swap out your data source (e.g., move from a local JSON to a real API) without changing the UI or domain logic.

3. Scalable

The organized structure of the app allows scalability without issues. It is easy to read, maintain and add features.

4. High Reusability

Common widgets, styles, and screens are placed in a lib/ directory and use a better folder structure.

• Benefit: This prevents code duplication. If you need to change a color, a font style, or a reusable component, you only have to do it in one place. This ensures consistency and speeds up development.

What Would a "Bad" Structure Look Like?

For an example of a poorly structured application with a flat directory structure and mixed concerns, see the "bad structure" example project. This anti-pattern is what this current project's architecture successfully avoids.