Flutter and Dart: from fundamentals to production on Ivaldo de Oliveira Batista Júnior

Flutter fundamentals for .NET developers

Mon, 01 Jan 0001 00:00:00 +0000

What you will build

You do not need to know how to create a Flutter page before starting. This module builds one with you, one small piece at a time. By the end, you will have a developer_profile project with:

an application configured with MaterialApp and ThemeData;
a DeveloperProfilePage in its own file;
a name, specialty, location, and contact button;
a layout that remains usable in a narrow window;
visible feedback when the button is pressed;
an automated test and a README with run instructions.

Do not paste the entire final solution at once. Run the app at every checkpoint. If something breaks, you will know which small change to inspect.

Modern Dart for C# developers

Mon, 01 Jan 0001 00:00:00 +0000

Dart is not C# with different punctuation

Classes, interfaces, and async/await feel familiar, but idiomatic Dart favors immutable data, named parameters, concise constructors, and explicit nullable types.

final class Product {
 const Product({
 required this.id,
 required this.name,
 required this.price,
 });

 final String id;
 final String name;
 final double price;
}

final prevents reassignment after initialization. const creates compile-time values when the complete expression is constant. Immutability is a strong default because it limits intermediate states and makes widgets easier to reason about.

Flutter architecture for professional projects

Mon, 01 Jan 0001 00:00:00 +0000

The problem architecture should solve

A small application can mix API access, validation, and UI updates in one widget. In a real product, that creates a fragile dependency chain. Architecture establishes a direction:

presentation -> domain <- data
 ^
 external

The domain stays in the center and does not import Flutter, Dio, Firebase, or a database. External layers implement internal contracts and remain replaceable.

Feature-first, with layers inside

Group code that changes together:

Professional interfaces with Material 3

Mon, 01 Jan 0001 00:00:00 +0000

A professional interface is a system

An isolated screen can look polished and still fall apart as the product grows. Professional interfaces need shared rules for spacing, typography, color, states, and responsive behavior.

Material 3 supplies foundations and components, but it does not make product decisions for you. Keep those decisions in the theme:

ThemeData buildTheme(ColorScheme colors) => ThemeData(
 useMaterial3: true,
 colorScheme: colors,
 textTheme: const TextTheme(
 headlineMedium: TextStyle(fontWeight: FontWeight.w700),
 bodyLarge: TextStyle(fontSize: 16, height: 1.5),
 ),
 inputDecorationTheme: const InputDecorationTheme(
 border: OutlineInputBorder(),
 ),
);

Avoid arbitrary colors and sizes inside widgets. A theme enables consistency, dark mode, and safer brand changes.

State management with Provider and Riverpod

Mon, 01 Jan 0001 00:00:00 +0000

State is information over time

Form fields, authenticated sessions, filters, remote data, and failures have different lifecycles. Before choosing a library, ask who owns the state, who observes it, whether it survives navigation, and whether it is a source value or a derivation.

setState is appropriate for short-lived local state. Trouble begins when distant widgets depend on the same value or asynchronous effects are triggered from build.

Provider and ChangeNotifier

final class CounterController extends ChangeNotifier {
 int _value = 0;
 int get value => _value;

 void increment() {
 _value++;
 notifyListeners();
 }
}

ChangeNotifierProvider(
 create: (_) => CounterController(),
 child: const CounterPage(),
)

Keep controllers focused, do not expose mutable collections, and avoid notifications for changes the UI does not use. ChangeNotifier is approachable, but large models can accumulate implicit dependencies and broad rebuilds.

REST APIs with Dio and production architecture

Mon, 01 Jan 0001 00:00:00 +0000

Integration is a boundary

An external API should not dictate the domain or leak transport details into the UI.

Widget -> Controller -> Use case -> Repository -> Data source -> HTTP

The return path translates JSON into a DTO, the DTO into an entity, and exceptions into known failures.

Centralize Dio configuration

Dio buildDio(AppEnvironment environment) {
 return Dio(
 BaseOptions(
 baseUrl: environment.apiUrl,
 connectTimeout: const Duration(seconds: 10),
 receiveTimeout: const Duration(seconds: 20),
 sendTimeout: const Duration(seconds: 20),
 headers: const {'Accept': 'application/json'},
 ),
 );
}

Do not create a client for every request. A shared instance supports consistent interceptors, cancellation, metrics, and policy.

Local persistence with SharedPreferences, Hive, and Drift

Mon, 01 Jan 0001 00:00:00 +0000

Persistence changes product behavior

Preferences, tokens, catalogs, and offline orders do not have the same requirements.

Need	Typical option
Theme, language, simple flag	SharedPreferences
Object and key-value cache	Hive
Relations, filters, transactions	Drift/SQLite
Small secret	Platform secure storage

Do not place sensitive tokens in regular preferences. Do not treat a cache as the only source of truth without an expiration policy.

SharedPreferences for configuration

final class PreferencesDataSource {
 PreferencesDataSource(this._preferences);
 final SharedPreferences _preferences;

 bool get darkMode => _preferences.getBool('darkMode') ?? false;
 Future<void> setDarkMode(bool enabled) {
 return _preferences.setBool('darkMode', enabled);
 }
}

Centralize keys and defaults. UI should talk to a controller or use case, not directly to a storage package.

Firebase for business applications

Mon, 01 Jan 0001 00:00:00 +0000

Backend as a Service does not remove architecture

Firebase accelerates identity, real-time data, files, and push. The risk is allowing SDK calls to spread through widgets or treating login as authorization. Keep Firebase at the edge:

presentation -> use cases -> repositories -> Firebase adapters

Create separate projects for development, staging, and production. Client configuration identifies the project; administrative credentials and rules still require protection.

Authentication and session

abstract interface class AuthRepository {
 Stream<AppUser?> authStateChanges();
 Future<AppUser> signInWithEmail(String email, String password);
 Future<void> signOut();
}

The implementation translates FirebaseAuthException into application failures. Login messages should not disclose account existence when that creates an enumeration risk.

Testing, quality, and observability

Mon, 01 Jan 0001 00:00:00 +0000

Quality is layered feedback

Tests do not prove that defects are absent; they reduce uncertainty around important behavior. A balanced strategy uses many fast domain tests, widget tests for user-visible behavior, and a small number of high-value integrated journeys.

Unit tests

test('applies a ten percent discount', () {
 const calculator = DiscountCalculator();
 final result = calculator.apply(total: 100, percentage: 10);
 expect(result, 90);
});

Use Arrange, Act, and Assert, and name the behavior. A test should fail for one clear reason.

Release, CI/CD, and distribution

Mon, 01 Jan 0001 00:00:00 +0000

Delivery is part of the product

An application is not finished when it compiles on a developer machine. A professional release must be reproducible, identifiable, signed, verified, and monitored.

Versioning and artifacts

In pubspec.yaml:

version: 1.2.0+42

The value before + communicates the version to users; the build number identifies a store delivery. Generate artifacts from the exact revision that passed validation:

flutter build appbundle --release
flutter build ipa --release
flutter build web --release

Artifact flutter build <target> --release

build produces an artifact for the requested target; --release selects optimizations and removes development tooling incompatible with distribution. The command neither publishes nor proves production behavior.

Capstone: Sales Management

Mon, 01 Jan 0001 00:00:00 +0000

The challenge

Build Sales Management, a business application for products, customers, and orders. The goal is not to reproduce one prescribed screen. It is to demonstrate that you can turn requirements into a cohesive, secure, operable solution.

Continue from the foundation created throughout the modules. Commit in small increments and keep the application runnable at each milestone.

Functional scope

Identity and users

Email sign-in and one social provider in the lab environment.
Sign-out and safe session restoration.
admin, supervisor, and seller profiles.
Routes and actions also protected by backend rules.

Dashboard

Total revenue, order count, active customers, and product count.
Loading, empty, data, and failure states.
Phone, tablet, and desktop/web layouts.

Products and customers

List, search, create, edit, and validate.
Product image upload with progress and failure recovery.
Paging or incremental loading.
Updated timestamps for synchronization.

Orders

Customer and product selection.
Quantity, unit price, and domain-calculated total.
Protection against empty orders and invalid quantity.
Order status and consistent stock updates.

Continuity and notifications

Local cache for important reads.
Clear stale-data and pending-operation feedback.
A documented conflict and reconnection policy.
Business-event notifications without sensitive payloads.

Expected architecture

lib/
 core/
 environment/
 error/
 network/
 observability/
 features/
 auth/
 dashboard/
 products/
 customers/
 orders/
 main.dart

Each feature should separate domain, data, and presentation when its complexity justifies those boundaries. Do not create empty layers merely to satisfy a diagram; document decisions and exceptions in the README.

Flutter and Dart command and concept reference

Mon, 01 Jan 0001 00:00:00 +0000

This page is a supporting reference, not a replacement for the lessons. Return whenever you need to interpret a diagnostic, choose a command, or recall a concept. Examples assume a terminal opened at the project root, where pubspec.yaml lives.

In this reference: reading commands · Flutter diagnostics · creation and execution · dependencies · quality and tests · build · Dart tools · Dart glossary · Flutter glossary · diagnostic workflow.

How to read a command

In flutter run -d <deviceId> --debug: