One Codebase, Every Screen

Flutter builds iOS, Android, web, and desktop apps from a single Dart codebase. This track takes you from your first line of Dart to a published app — widgets, state, networking, Firebase, and release. Everything you learn goes into one small app you build session by session: DayList, a personal task manager.

Dart Basics

Sources: Dart Language Tour · dart.dev/language

Theory

Flutter is written in Dart, a typed language that stays terse. Every program starts in main(). Types include int, double, String, and bool — but var lets the compiler infer them. final is set once at runtime; const is fixed at compile time.

Null safety means a variable can only be null if you say so with ?. The ?? operator gives a fallback for a null value.

Demonstration

void main() {
  var name = 'Ahmad';        // inferred String
  final city = 'Peshawar';   // set once
  const pi = 3.14159;        // compile-time constant

  int age = 25;
  double price = 9.99;
  bool isStudent = true;

  // Null safety: ? allows null, ?? gives a fallback value.
  String? nickname = null;   // the ? is Dart syntax: "may be null"
  print(nickname ?? 'no nickname');   // ?? = use the right side if null
}

Open dartpad.dev and run it. Now remove the ? from nickname — the analyzer refuses, because null safety caught a crash before it happened.

Practice

1. Declare your name, age, and city using var, final, and const.
2. Create a nullable int and print it with a ?? fallback.
3. What is the difference between final and const?
4. Why does null safety exist?

Project step: Create daylist.dart and declare the app constants: appName and defaultPriority with final and const, plus a nullable dueDate set to null.

Wrap Up

Dart is typed but terse — var for inference, final for set-once, const for constants, ? for maybe-null.

Functions and Control Flow

Sources: Dart Language Tour · dart.dev/language

Theory

Functions bundle logic and take parameters. Dart supports named parameters in curly braces with defaults — Flutter's own APIs use them constantly, so reading them is essential. Control flow is familiar: if / else, switch, for, while, and for-in.

Demonstration

String greet(String name, {String greeting = 'Hello'}) {
  return '$greeting, $name!';
}

int add(int a, int b) => a + b;   // arrow function

void main() {
  print(greet('Ahmad'));                // Hello, Ahmad!
  print(greet('Ahmad', greeting: 'Salam'));

  for (var i = 1; i <= 5; i++) {
    if (i % 2 == 0) print('$i is even');
  }
}

The arrow syntax => is shorthand for a function whose body is a single returned expression.

Practice

1. Write a function that greets by name with a customizable greeting.
2. Convert a two-line function into an arrow function.
3. Print FizzBuzz for 1–15 (Fizz for 3, Buzz for 5, FizzBuzz for both).
4. Iterate over a list with for-in.

Project step: Add three functions to daylist.dart: priorityLabel(int), isOverdue(DateTime?), and taskSummary(String title, {bool isCompleted = false, int priority = 1}) using named parameters.

Wrap Up

Named parameters keep calls readable — and Flutter's APIs use them everywhere.

Collections

Sources: Dart Language Tour · dart.dev/language

Theory

A List keeps ordered items, a Set keeps unique items, and a Map stores key → value pairs. Functional methods do the heavy lifting: where filters, map transforms, reduce combines. Most app data is one of these three shapes.

Demonstration

void main() {
  final students = ['Ali', 'Sara', 'Bilal'];
  students.add('Hina');
  print(students.length);              // 4

  final ages = {'Ali': 20, 'Sara': 22};
  print(ages['Ali']);                  // 20

  final adults = ages.keys
      .where((name) => ages[name]! >= 21)
      .toList();
  print(adults);                       // [Sara]
}

Chain the methods: take a collection, filter it, transform it, convert it back to a list — this pattern appears in every Flutter screen that shows data.

Practice

1. Build a list of five cities and print its length.
2. Filter the list to cities starting with a chosen letter.
3. Store names and ages in a map, then list everyone over 18.
4. What is the difference between a List and a Set?

Project step: Store tasks in a List of maps: add four tasks, filter the unfinished ones with where, and print the count of completed tasks.

Wrap Up

List for order, Set for uniqueness, Map for lookup — and where() filters anything.

Classes and Objects

Sources: Dart Language Tour · dart.dev/language

Theory

A class bundles data and behavior. The constructor initializes the fields; Dart's named parameters make construction readable. Methods operate on the object's data. Every Flutter widget is a class with a build method — this session is the foundation of all of Flutter.

Demonstration

class Student {
  final String name;
  final int age;

  Student({required this.name, required this.age});

  String introduce() => 'I am $name, $age years old.';

  @override
  String toString() => 'Student($name, $age)';
}

void main() {
  final s = Student(name: 'Ahmad', age: 25);
  print(s.introduce());
  print(s);
}

required forces the caller to provide the field; final makes the object immutable — the same conventions Flutter widgets follow.

Practice

1. Define a Book class with title and pages.
2. Add a method that describes the book.
3. Instantiate three books and print each description.
4. Why are the fields final in the example?

Project step: Replace the task maps with a Task class: id, title, isCompleted, priority, dueDate — with a named constructor, a copyWith method, and toString. This class is the heart of the whole app.

Wrap Up

A class bundles data and behavior — Flutter widgets are classes with build().

Async: Futures and async/await

Sources: Dart Language Tour · dart.dev/language

Theory

Network calls and file reads take time. A Future<T> is a value that will arrive later. Marking a function async lets you await a Future — code pauses there until the value is ready, without blocking the whole app. Errors are caught with try / catch.

Demonstration

Future<String> fetchName() async {
  await Future.delayed(Duration(seconds: 2));
  return 'Ahmad';
}

void main() async {
  try {
    final name = await fetchName();
    print(name);
  } catch (e) {
    print('Failed: $e');
  }
}

await never freezes the app — only this function waits.

Practice

1. Write an async function that returns a number after a delay.
2. Await it in main and print the result.
3. Add a try/catch around a function that throws.
4. What does async mark on a function?

Project step: Write Future<List<Task>> loadTasks() and Future<void> saveTasks(List<Task>) that simulate storage with Future.delayed, and wrap the load in try/catch with a fallback empty list.

Wrap Up

Futures are Flutter's heartbeat — every network call is an await away.

First Console Apps

Sources: Dart Language Tour · dart.dev/language

Theory

Before any UI, practice pure logic: model the data, write the functions, run main(). Every Flutter screen is this same pattern with widgets on top — the logic is identical. Work in DartPad; keep each app in one file; run after every change.

Demonstration

void main() {
  final grades = {'Ali': 85, 'Sara': 92, 'Bilal': 78};

  double average(Map<String, int> grades) =>
      grades.values.reduce((a, b) => a + b) / grades.length;

  final best = grades.entries
      .reduce((a, b) => a.value >= b.value ? a : b);

  print('Average: ${average(grades)}');
  print('Top: ${best.key} (${best.value})');
}

The thought process: what is the data (a map)? What do we want (average, best)? One small function per answer, then print the results.

Practice

1. Build a to-do list app: add, remove, and print tasks.
2. Build a temperature converter: Celsius to Fahrenheit.
3. Build a quiz app: questions, answers, and a score.
4. When your program misbehaves, print the state at each step and explain what changed.

Project step: Finish the console version of DayList: a menu loop with add, list, complete, and delete, loading the list with await loadTasks() at start and saving after every change. Module 1 complete — you have the app's brain.

Wrap Up

Console apps teach logic without UI noise — every Flutter screen is this logic plus widgets.

Flutter Setup and First App

Sources: docs.flutter.dev/get-started

Theory

Flutter needs the SDK, an editor (VS Code or Android Studio), and at least one device — an emulator, a physical phone, or the desktop/web target. flutter doctor checks every dependency and tells you what is missing. A project starts with flutter create.

flutter doctor
flutter create daylist
cd daylist
flutter run

Hot reload re-sends only your changed code to the running app in under a second — state survives. Hot restart rebuilds from scratch. That loop is the reason Flutter development feels fast.

Demonstration

Save a file, press r, and the change appears immediately.

Practice

1. Run flutter doctor and fix anything it flags.
2. Create a project and run the default counter app.
3. Change the counter text and hot reload without restarting.
4. What is the difference between hot reload and hot restart?

Project step: Create the daylist project, run the default counter app, and rename it to DayList — this project will hold everything from now on.

Wrap Up

flutter create makes the project, flutter run makes it live, and hot reload makes it fast.

Widgets, Widgets, Widgets

Sources: docs.flutter.dev/ui/widgets-intro

Theory

In Flutter everything on screen is a widget — buttons, padding, text, even the app itself. Widgets compose into a tree, and each build() method describes a piece of the UI. Flutter redraws the tree whenever something changes.

Demonstration

import 'package:flutter/material.dart';

void main() => runApp(const DayListApp());

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

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: Scaffold(
        appBar: AppBar(title: const Text('DayList')),
        body: const Center(child: Text('No tasks yet')),
      ),
    );
  }
}

MaterialApp is the app root; Scaffold gives the page its frame (app bar, body); Center positions the text. Four widgets, one screen.

Practice

1. Explain what a widget tree is.
2. Write a StatelessWidget that shows your name centered on screen.
3. Add an AppBar with a different title.
4. Why is composition preferred over inheritance in Flutter?

Project step: Replace the counter app with a DayListApp StatelessWidget: an AppBar titled DayList and a centered placeholder message.

Wrap Up

Widgets are lego bricks — build() describes the UI, and Flutter draws it.

Layouts: Row, Column, and Friends

Sources: docs.flutter.dev/ui/layout

Theory

Row lays children out horizontally, Column vertically. mainAxisAlignment positions children along that axis; Expanded gives a child the remaining space. Padding and SizedBox control breathing room.

Const gotcha: const only works when everything inside is const too. Writing const TaskTile(task: Task(...)) fails with "isn't a const constructor" — because Task is built at runtime. Drop the const and it compiles.

Demonstration

Row(
  children: [
    const Icon(Icons.circle_outlined),
    const SizedBox(width: 12),
    Expanded(child: Text('Buy groceries')),
    const Icon(Icons.star, color: Colors.orange),
  ],
)

This row is already a task row: a leading icon, a title that takes the space, and a trailing priority star. The Expanded title pushes the star to the right edge.

Practice

1. Build a row with an icon, a text, and a trailing icon.
2. Center three icons horizontally using mainAxisAlignment.
3. What does Expanded do?
4. Stack a Column inside a Padding and explain the order.

Project step: Build a TaskTile widget: a Row with a checkbox icon, the task title in Expanded, and a priority star on the right.

Wrap Up

Rows lay out horizontally, Columns vertically — Expanded shares the leftover space.

State and setState

Sources: docs.flutter.dev/ui/interactivity

Theory

A StatelessWidget has no memory; its UI depends only on its inputs. A StatefulWidget holds state in a companion State object. Calling setState tells Flutter "my state changed — rebuild me".

Demonstration

class ToggleTile extends StatefulWidget {
  const ToggleTile({super.key});
  @override
  State<ToggleTile> createState() => _ToggleTileState();
}

class _ToggleTileState extends State<ToggleTile> {
  bool _isCompleted = false;

  void _toggle() {
    setState(() {
      _isCompleted = !_isCompleted;
    });
  }

  @override
  Widget build(BuildContext context) {
    return IconButton(
      icon: Icon(_isCompleted ? Icons.check_circle : Icons.circle_outlined),
      onPressed: _toggle,
    );
  }
}

Tap the icon: setState flips _isCompleted, and build() runs again with the new value. Without setState the icon would never change.

Practice

1. Convert a stateless tile into a StatefulWidget.
2. Toggle a boolean with setState and show the value as text.
3. What happens if you change the variable without calling setState?
4. Why does StatefulWidget have two classes?

Project step: Make TaskTile interactive: tapping the checkbox icon toggles isCompleted with setState and changes the icon to check_circle.

Wrap Up

setState says 'the UI changed — redraw me'.

Text, Images, and Icons

Sources: docs.flutter.dev/ui/assets

Theory

Text takes a string and an optional TextStyle (size, weight, color, decoration). IconButton is a tappable icon with built-in feedback. Image.network loads from a URL — always give it an errorBuilder because networks fail.

Demonstration

Text(
  'Buy groceries',
  style: TextStyle(
    fontWeight: FontWeight.bold,
    decoration: isCompleted ? TextDecoration.lineThrough : null,
  ),
)

IconButton(
  icon: const Icon(Icons.delete_outline),
  onPressed: () => print('delete pressed'),
)

Image.network(
  url,
  errorBuilder: (context, error, stack) => const Icon(Icons.broken_image),
)

Practice

1. Style a title in bold with strikethrough.
2. Add a delete IconButton that prints on tap.
3. Load a network image with an errorBuilder fallback.
4. Why does Image.network need an errorBuilder?

Project step: Give TaskTile a nicer look: bold task titles with strikethrough when completed, a delete IconButton, and a fallback image for task attachments.

Wrap Up

Text conveys, icons hint, images illustrate — and every one of them is still a widget.

Styling and Themes

Sources: docs.flutter.dev/cookbook/design/theming

Theory

Styling every widget by hand does not scale. ThemeData sets the app's colors, text styles, and component shapes in one place; every Material widget inherits it. ColorScheme.fromSeed generates a consistent Material 3 palette from a single color.

Demonstration

MaterialApp(
  theme: ThemeData(
    colorScheme: ColorScheme.fromSeed(seedColor: Colors.deepOrange),
    useMaterial3: true,
  ),
  darkTheme: ThemeData.dark(),
  themeMode: ThemeMode.system,
  home: const HomeScreen(),
)

Read the theme anywhere with Theme.of(context) — the seeded orange now tints buttons, switches, and the app bar automatically.

Practice

1. Seed a Material 3 theme from one color.
2. Add a dark theme and system theme mode.
3. Read the primary color with Theme.of(context) and use it on an icon.
4. Why theme at the app level instead of per widget?

Project step: Give DayList its theme: a deep-orange Material 3 seed, a dark theme that follows the system, and consistent text styles across the app.

Wrap Up

Theme once, inherit everywhere — ThemeData is the app's wardrobe.

Building the Home Screen

Sources: docs.flutter.dev/ui/widgets

Theory

A screen is a Scaffold with an AppBar and a body. AppBar actions place buttons on the right. Conditional UI is just a Dart expression: show the list when there are tasks, an empty-state widget otherwise.

Demonstration

Scaffold(
  appBar: AppBar(
    title: const Text('DayList'),
    actions: [
      IconButton(
        icon: const Icon(Icons.add),
        onPressed: () => print('open add screen'),
      ),
    ],
  ),
  body: tasks.isEmpty
      ? const Center(child: Text('No tasks yet'))
      : Column(children: tasks.map((task) => TaskTile(task: task)).toList()),
)

Practice

1. Add two actions to an AppBar.
2. Render one widget or another based on a condition.
3. Explain what Scaffold provides.
4. Where does the + button for adding tasks belong?

Project step: Assemble the HomeScreen: an AppBar with a + action, the list of TaskTiles, and a centered empty state when the list is empty.

Wrap Up

A screen is just a widget tree with a Scaffold at the top.

Routes and the Navigator

Sources: docs.flutter.dev/cookbook/navigation/navigation-basics

Theory

Navigator manages a stack of screens. Navigator.push puts a new route on top; Navigator.pop removes it. Data travels into the new screen through its constructor — plain Dart, no magic.

Demonstration

Navigator.push(
  context,
  MaterialPageRoute(
    builder: (context) => TaskDetailScreen(task: task),
  ),
);

// inside TaskDetailScreen:
Navigator.pop(context);

Practice

1. Push a detail screen when a task is tapped.
2. Pass the tapped task into the screen.
3. Pop back and confirm the home screen still shows the list.
4. Where does context come from in Navigator.push?

Project step: Tap a task to open a TaskDetailScreen that receives the Task in its constructor and shows title, priority, and due date, with a back button.

Wrap Up

Navigator is a stack — push to go forward, pop to come back.

Named Routes and Arguments

Sources: docs.flutter.dev/cookbook/navigation/named-routes

Theory

Named routes replace constructor calls with string names declared once on MaterialApp — like URLs for your app. Arguments ride along via the arguments parameter and are read with ModalRoute.of(context).

Demonstration

MaterialApp(
  routes: {
    '/home': (context) => const HomeScreen(),
    '/task': (context) => const TaskDetailScreen(),
  },
);

Navigator.pushNamed(context, '/task', arguments: task);

// read it back:
final task = ModalRoute.of(context)!.settings.arguments as Task;

Practice

1. Declare routes for home and task detail.
2. Navigate with pushNamed and pass a task.
3. Read the arguments and display the task.
4. When are named routes worth it?

Project step: Convert DayList navigation to named routes ('/home' and '/task') and pass the selected Task as arguments.

Wrap Up

Named routes turn navigation into URLs — easier to read and maintain.

Forms and Validation

Sources: docs.flutter.dev/cookbook/forms/validation

Theory

A Form groups fields and runs their validators together. A TextFormField's validator returns an error string, or null when valid. On submit, formKey.currentState!.validate() checks everything, then save() copies the values out.

Demonstration

final _formKey = GlobalKey<FormState>();

Form(
  key: _formKey,
  child: TextFormField(
    decoration: const InputDecoration(labelText: 'Title'),
    validator: (value) =>
        value == null || value.trim().isEmpty ? 'Title is required' : null,
    onSaved: (value) => _title = value ?? '',
  ),
)

if (_formKey.currentState!.validate()) {
  _formKey.currentState!.save();
}

Practice

1. Build a form with a title field.
2. Write a validator that rejects empty input.
3. Save the value and print it on submit.
4. What does the validator's return value mean?

Project step: Build the AddTaskScreen: a Form with title (required) and priority fields, a submit button that only accepts valid input, and an inline error for an empty title.

Wrap Up

The Form collects, validates, and saves — three jobs, one widget.

Lists and ListView

Sources: docs.flutter.dev/cookbook/lists/long-lists

Theory

A Column builds every child up front; ListView.builder builds only the rows visible on screen and recycles them as you scroll — a thousand tasks costs the same as ten.

Demonstration

ListView.builder(
  itemCount: tasks.length,
  itemBuilder: (context, index) {
    final task = tasks[index];
    return TaskTile(task: task);
  },
)

Practice

1. Render the task list with ListView.builder.
2. Add separators between rows.
3. Scroll with a hundred tasks and watch memory stay flat.
4. Why not just use a Column?

Project step: Replace the hand-built task Column with a ListView.builder of TaskTiles — the home screen now scrolls with any number of tasks.

Wrap Up

ListView.builder only builds what fits on screen — the long list stays cheap.

State Management: Provider

Sources: docs.flutter.dev/data-and-backend/state-mgmt/simple

Theory

setState only works for one widget. When many screens share data, lift it into a ChangeNotifier — a store that calls notifyListeners() when it changes. ChangeNotifierProvider hands it down the tree, and context.watch rebuilds any widget when it changes.

Demonstration

class TaskStore extends ChangeNotifier {
  final List<Task> _tasks = [];
  List<Task> get tasks => List.unmodifiable(_tasks);

  void add(Task task) {
    _tasks.add(task);
    notifyListeners();
  }

  void toggle(String id) {
    final index = _tasks.indexWhere((t) => t.id == id);
    _tasks[index] = _tasks[index].copyWith(isCompleted: !_tasks[index].isCompleted);
    notifyListeners();
  }
}

// main():
ChangeNotifierProvider(
  create: (_) => TaskStore(),
  child: const DayListApp(),
)

// any widget:
final store = context.watch<TaskStore>();

Practice

1. Move the task list into a TaskStore.
2. Provide it at the app root.
3. Watch it from the home screen and add from the form.
4. What happens if you forget notifyListeners()?

Project step: Create TaskStore with add, toggle, and remove, provide it at the app root, and rewire the home list and add form through Provider — the app now shares state properly.

Wrap Up

Provider holds the truth; widgets watch it and rebuild when it changes.

Local Storage: shared_preferences

Sources: docs.flutter.dev/cookbook/persistence/key-value

Theory

shared_preferences persists small key-value settings — strings, bools, ints — across app restarts. It is a settings drawer, not a database: tasks belong in SQLite or the cloud, preferences belong here.

Demonstration

final prefs = await SharedPreferences.getInstance();
await prefs.setString('sortOrder', 'priority');

final order = prefs.getString('sortOrder') ?? 'date';
print(order); // priority

Practice

1. Add shared_preferences to pubspec.yaml.
2. Save a sort order and read it back.
3. Handle the first-run case where nothing is saved.
4. Why not store the task list in shared_preferences?

Project step: Persist the user's sort order (date or priority) in shared_preferences and apply it when DayList starts.

Wrap Up

shared_preferences is the drawer for small settings — not your task database.

HTTP and REST APIs

Sources: docs.flutter.dev/data-and-backend/networking

Theory

Most backends speak REST over HTTP: a URL identifies a resource, a verb describes the action (GET read, POST create, PUT/PATCH update, DELETE remove), and a status code reports the result. In Flutter the http package makes the call; everything is async.

Demonstration

import 'package:http/http.dart' as http;

final response = await http.get(
  Uri.parse('https://jsonplaceholder.typicode.com/todos'),
);

if (response.statusCode == 200) {
  print(response.body);   // the JSON string
} else {
  print('Failed: ${response.statusCode}');
}

Practice

1. Add http to pubspec.yaml.
2. Fetch the todos list and print the body.
3. Force a 404 by hitting a bad URL and print the status.
4. What does a 200 versus a 404 mean?

Project step: Write an ApiClient with fetchTasks() that GETs the todo list from a public test API and returns the raw JSON string.

Wrap Up

Every API call is a Future — await it, check the status, then parse.

JSON Parsing and Models

Sources: docs.flutter.dev/data-and-backend/serialization/json

Theory

JSON arrives as a string; jsonDecode turns it into maps and lists. The rule: convert at the edge — a fromJson factory builds a typed model, and the rest of the app never touches raw JSON again.

Demonstration

import 'dart:convert';

class RemoteTask {
  final int id;
  final String title;
  final bool isCompleted;

  RemoteTask({required this.id, required this.title, required this.isCompleted});

  factory RemoteTask.fromJson(Map<String, dynamic> json) => RemoteTask(
        id: json['id'] as int,
        title: json['title'] as String,
        isCompleted: json['completed'] as bool,
      );

  Map<String, dynamic> toJson() =>
      {'id': id, 'title': title, 'completed': isCompleted};
}

// decode a list:
final decoded = jsonDecode(response.body) as List<dynamic>;
final tasks = decoded
    .map((item) => RemoteTask.fromJson(item as Map<String, dynamic>))
    .toList();

Practice

1. Parse one JSON object into a RemoteTask.
2. Parse a list of them.
3. Write toJson for the model.
4. Why not pass raw maps around the app?

Project step: Add fromJson/toJson to a RemoteTask model and convert the API response into List<Task> your UI already understands.

Wrap Up

Convert once at the edge — the rest of the app speaks models, not JSON.

Loading, Error, and Empty States

Sources: docs.flutter.dev/cookbook/networking/fetch-data

Theory

Every screen that loads data has four moods: loading (spinner), error (message + retry), empty (nothing to show), and data. FutureBuilder watches a Future and rebuilds as it completes — a clean way to cover all four in one place.

Demonstration

FutureBuilder<List<Task>>(
  future: api.fetchTasks(),
  builder: (context, snapshot) {
    if (snapshot.connectionState == ConnectionState.waiting) {
      return const Center(child: CircularProgressIndicator());
    }
    if (snapshot.hasError) {
      return ErrorState(
        message: 'Could not load tasks',
        onRetry: () => setState(() {}),
      );
    }
    final tasks = snapshot.data ?? [];
    if (tasks.isEmpty) {
      return const Center(child: Text('No tasks yet'));
    }
    return TaskList(tasks: tasks);
  },
)

Practice

1. Render a spinner while a future is waiting.
2. Show an error widget with a retry button.
3. Show an empty message when the result is empty.
4. What are the four states called?

Project step: Add a sync screen to DayList: a spinner while fetching, a retry button on error, an empty message when the API returns nothing, and the list when it works.

Wrap Up

Every async screen has four moods: loading, error, empty, and data.

Persistence: SQLite (sqflite)

Sources: docs.flutter.dev/cookbook/persistence/sqlite

Theory

sqflite is a real SQL database on the device. The pattern: open once, define the schema in onCreate, then run CRUD with SQL. Tasks saved here survive restarts — the local source of truth.

Demonstration

final db = await openDatabase(
  'daylist.db',
  version: 1,
  onCreate: (db, version) => db.execute(
    'CREATE TABLE tasks('
    'id INTEGER PRIMARY KEY, '
    'title TEXT, is_completed INTEGER, priority INTEGER)',
  ),
);

await db.insert('tasks', {'title': 'Buy milk', 'is_completed': 0, 'priority': 1});
final rows = await db.query('tasks', where: 'is_completed = ?', whereArgs: [0]);
await db.update('tasks', {'is_completed': 1}, where: 'id = ?', whereArgs: [1]);
await db.delete('tasks', where: 'id = ?', whereArgs: [1]);

Practice

1. Create a database with a tasks table.
2. Insert three tasks and query the unfinished ones.
3. Update one task to completed and verify the change.
4. Why is sqflite a better home for tasks than shared_preferences?

Project step: Give TaskStore a TaskDatabase: persist every add, toggle, and remove to SQLite so tasks survive app restarts, and load them at startup.

Wrap Up

SQLite is the real database on the phone — tables, queries, and transactions.

Pagination and Infinite Scroll

Sources: docs.flutter.dev/ui/widgets/scrolling

Theory

APIs cap responses — a page of 20, not all 10,000. Pagination fetches page by page. A ScrollController reports when the user nears the bottom, the screen fetches the next page, and the rows are appended.

Demonstration

final _controller = ScrollController()..addListener(() {
  if (_controller.position.pixels >=
      _controller.position.maxScrollExtent - 200) {
    _loadNextPage();
  }
});

Future<void> _loadNextPage() async {
  if (_loading) return;      // guard against duplicate fetches
  _loading = true;
  final page = await api.fetchTasks(page: _page);
  setState(() {
    tasks.addAll(page);
    _page += 1;
  });
  _loading = false;
}

Practice

1. Fetch page one of the todos API.
2. Trigger a fetch when the user scrolls near the bottom.
3. Guard against double fetches.
4. Show a small loading footer while the next page loads.

Project step: Paginate the remote task list: load 20 at a time and fetch the next page automatically as the user scrolls to the bottom, with a loading footer.

Wrap Up

Fetch a page, render it, and pull the next one when the user reaches the bottom.

Firebase Setup and Authentication

Sources: firebase.flutter.dev/docs/auth/usage

Theory

Firebase gives apps a hosted backend: authentication, a database, storage, and messaging. After adding the config files, FirebaseAuth handles sign-in. The authStateChanges() stream tells you whenever the user logs in or out — the app's security boundary.

Demonstration

final auth = FirebaseAuth.instance;

final user = await auth.signInWithEmailAndPassword(
  email: email,
  password: password,
);

await auth.signOut();

StreamBuilder<User?>(
  stream: auth.authStateChanges(),
  builder: (context, snapshot) {
    final user = snapshot.data;
    return user == null ? const SignInScreen() : const HomeScreen();
  },
)

Practice

1. Create a Firebase project and add the config to the app.
2. Sign in with a test account and print the user's UID.
3. Wire authStateChanges to switch between sign-in and home.
4. What is the UID used for?

Project step: Add a SignInScreen to DayList with email/password fields, error messages, and a sign-out button — the app now knows who is using it.

Wrap Up

FirebaseAuth hands you a signed-in user and a stream that tells you when it changes.

Firestore CRUD

Sources: firebase.flutter.dev/docs/firestore/usage

Theory

Firestore is a document database in the cloud: collections hold documents, each a JSON-like map. Tasks become documents in a tasks collection, with a userId field so every query filters to the signed-in user.

Demonstration

final firestore = FirebaseFirestore.instance;

// create
final doc = await firestore.collection('tasks').add({
  'title': title,
  'isCompleted': false,
  'priority': 1,
  'userId': user.uid,
});

// update
await firestore.collection('tasks').doc(doc.id).update({'isCompleted': true});

// delete
await firestore.collection('tasks').doc(doc.id).delete();

// read only my tasks
final snapshot = await firestore
    .collection('tasks')
    .where('userId', isEqualTo: user.uid)
    .get();

Practice

1. Add a task document with a userId field.
2. Update its isCompleted flag.
3. Query only the signed-in user's tasks.
4. Why does every document carry userId?

Project step: Replace local persistence with Firestore: tasks are stored per user (userId field), and add, toggle, and delete now hit the cloud.

Wrap Up

Firestore is a document database in the cloud — collections of documents you can query and update live.

Streams and StreamBuilder

Sources: firebase.flutter.dev/docs/firestore/usage

Theory

A Future delivers one value; a Stream delivers many, over time. Firestore's snapshots() is a stream that emits every time the data changes. StreamBuilder rebuilds on each emission — realtime UI with no manual refresh.

Demonstration

StreamBuilder<QuerySnapshot>(
  stream: FirebaseFirestore.instance
      .collection('tasks')
      .where('userId', isEqualTo: user.uid)
      .snapshots(),
  builder: (context, snapshot) {
    if (snapshot.hasError) return const ErrorState();
    if (!snapshot.hasData) {
      return const Center(child: CircularProgressIndicator());
    }
    final tasks = snapshot.data!.docs
        .map((doc) => Task.fromFirestore(doc))
        .toList();
    return TaskList(tasks: tasks);
  },
)

Practice

1. Explain how a Stream differs from a Future.
2. Subscribe to the user's tasks with snapshots().
3. Render the docs as Task objects.
4. Why does the list update without any refresh code?

Project step: Wrap the task list in a StreamBuilder on the user's tasks query — changes made on any device appear instantly.

Wrap Up

Streams push data — StreamBuilder redraws the screen the moment Firestore changes.

Firebase Storage

Sources: firebase.flutter.dev/docs/storage/usage

Theory

Firebase Storage holds files — images, audio, attachments. The pattern: pick a file, upload it to a path, save the returned download URL on the task document. Storage keeps the bytes; Firestore keeps the pointer.

Demonstration

final ref = FirebaseStorage.instance
    .ref('tasks/${taskId}.jpg');

await ref.putFile(file);
final url = await ref.getDownloadURL();

await FirebaseFirestore.instance
    .collection('tasks')
    .doc(taskId)
    .update({'imageUrl': url});

Practice

1. Upload an image to a task-specific path.
2. Fetch the download URL and store it on the task.
3. Display the image in the detail screen.
4. Why store the URL instead of the file itself in Firestore?

Project step: Let users attach one image per task: pick it, upload it to Storage, save the download URL on the task, and display it in the detail screen.

Wrap Up

Storage holds the files, Firestore holds the metadata, and the URL connects them.

Notifications and Reminders

Sources: firebase.flutter.dev/docs/messaging/usage

Theory

Local notifications are scheduled on the device — perfect for due-date reminders. Push notifications (FCM) arrive from a server — announcements and sync events. A task app mostly needs local reminders; FCM comes later when a backend sends messages.

Demonstration

final plugin = FlutterLocalNotificationsPlugin();
await plugin.initialize(const InitializationSettings(
  android: AndroidInitializationSettings('@mipmap/ic_launcher'),
));

await plugin.zonedSchedule(
  task.hashCode,
  'Task due soon',
  '${task.title} is due today',
  tz.TZDateTime.from(task.dueDate!, tz.local),
  const NotificationDetails(
    android: AndroidNotificationDetails('tasks', 'Task reminders'),
  ),
  androidScheduleMode: AndroidScheduleMode.exactAllowWhileIdle,
);

Practice

1. Initialize a notifications plugin.
2. Schedule a reminder for a task's due date.
3. Handle permission denial gracefully.
4. When would you use FCM instead?

Project step: Schedule a local reminder when a task has a due date — DayList now nudges you before tasks are due.

Wrap Up

Local notifications remind on schedule; FCM brings messages from the server.

Animations

Sources: docs.flutter.dev/ui/animations

Theory

Implicit animations animate a property when it changes — hand the widget a duration and it tweens between values on its own. Explicit animations give you an AnimationController for full control. Start implicit; most polish needs nothing more.

Demonstration

AnimatedOpacity(
  opacity: task.isCompleted ? 0.4 : 1.0,
  duration: const Duration(milliseconds: 250),
  child: TaskTile(task: task),
)

AnimatedContainer(
  duration: const Duration(milliseconds: 200),
  color: selected ? Colors.orange.shade50 : Colors.transparent,
  child: ...
)

Practice

1. Fade a completed task to 40% opacity.
2. Animate a container's color on selection.
3. Explain the difference between implicit and explicit animations.
4. Why does every animation need a duration?

Project step: Animate DayList: tasks fade and shrink slightly when completed, and the empty state fades in with AnimatedOpacity.

Wrap Up

Implicit animations animate when a property changes — give it a duration and Flutter tweens it.

Responsive Design and SafeArea

Sources: docs.flutter.dev/ui/layout/adaptive

Theory

LayoutBuilder tells you how much space a widget has; MediaQuery describes the screen itself. SafeArea pads content away from notches and system bars. Combine them: one widget on a phone, a side-by-side list-and-detail on a wide screen.

Demonstration

SafeArea(
  child: LayoutBuilder(
    builder: (context, constraints) {
      final wide = constraints.maxWidth > 600;
      return wide
          ? Row(children: [
              SizedBox(width: 320, child: TaskList()),
              const Expanded(child: TaskDetailPlaceholder()),
            ])
          : const TaskList();
    },
  ),
)

Practice

1. Wrap the home screen in SafeArea.
2. Switch layouts with LayoutBuilder at 600px.
3. Read the screen size with MediaQuery.
4. What is the difference between MediaQuery and LayoutBuilder?

Project step: Make DayList responsive: SafeArea everywhere, and a two-pane layout (list + detail side by side) on screens wider than 600px.

Wrap Up

LayoutBuilder asks how much room you have; SafeArea keeps you off the notch.

Testing

Sources: docs.flutter.dev/testing

Theory

Unit tests check pure logic — does add() really add? Widget tests pump a widget in a fake environment and assert on what it renders. Both run with flutter test in seconds and lock behavior in place.

Demonstration

// unit test
import 'package:flutter_test/flutter_test.dart';

test('TaskStore toggles a task', () {
  final store = TaskStore();
  final task = Task(id: '1', title: 'Buy milk');
  store.add(task);

  store.toggle('1');

  expect(store.tasks.first.isCompleted, isTrue);
});

// widget test
testWidgets('TaskTile renders the title', (tester) async {
  final task = Task(id: '1', title: 'Buy milk');
  await tester.pumpWidget(
    MaterialApp(home: Scaffold(body: TaskTile(task: task))),
  );

  expect(find.text('Buy milk'), findsOneWidget);
});

Practice

1. Write a unit test for TaskStore.add and toggle.
2. Write a widget test that expects a task title.
3. Run flutter test and read the results.
4. What is the difference between the two test kinds?

Project step: Write tests for DayList: a unit test for TaskStore add/toggle and a widget test that pumps TaskTile and expects the task title.

Wrap Up

Tests lock behavior in place — the task you fix today cannot quietly break tomorrow.

Build and Release

Sources: docs.flutter.dev/deployment/android

Theory

A release build strips debug tooling, shrinks the code, and signs the artifact. Android ships an appbundle for the Play Store (the store splits it per device); a plain APK is useful for direct testing. The app icon, splash, and version all live in project config.

Demonstration

flutter build apk --release
flutter build appbundle
flutter build ios --release

# pubspec.yaml
version: 1.0.0+1   # 1.0.0 = version shown, 1 = build number

# icon and splash: flutter_launcher_icons + flutter_native_splash

Practice

1. Set a custom app icon and splash.
2. Bump the version in pubspec.yaml.
3. Build a release APK and install it on a device.
4. What is the difference between an APK and an appbundle?

Project step: Give DayList its icon and splash, bump the version in pubspec.yaml, and produce a release APK.

Wrap Up

A release build strips debugging and shrinks the app — the same code, half the size.

Publishing to Stores

Sources: docs.flutter.dev/deployment

Theory

The store is a product page, not a technical step: name, short and long descriptions, screenshots, content rating, and a privacy policy. Both Google Play and the App Store review the listing and the app — the checklist is the same discipline as the rest of the course.

Demonstration

Store submission checklist:
1. Release build signed (appbundle / archive)
2. App name + short description (80 chars)
3. Long description — what DayList does
4. Screenshots per required device size
5. Feature graphic / icon at required resolutions
6. Content rating questionnaire
7. Privacy policy URL
8. Support contact + category
9. Version name matches pubspec

Practice

1. Write the 80-character short description for DayList.
2. Capture screenshots of the main screens.
3. Draft the privacy policy lines (what data does the app store?).
4. What belongs in the store listing besides the binary?

Project step: Prepare DayList's store listing: name, short description, screenshots, and a privacy policy page — the release checklist from the previous session.

Wrap Up

The store is a product page — screenshots, description, and privacy sell the app.

Capstone Brief

Sources: docs.flutter.dev

Theory

The capstone is not new features — it is assembling everything the modules built into one finished app. Write the definition of done first: the features that must work and the evidence that proves each one.

Demonstration

DayList — definition of done
1. Sign in / sign out works, auth state gates the UI
2. Add, toggle, and delete tasks, synced per user
3. Realtime updates via Firestore stream
4. Task images attach and display
5. Due-date reminders fire
6. Offline list falls back to SQLite cache
7. Animations, SafeArea, two-pane tablet layout
8. Unit + widget tests green (flutter test)
9. flutter analyze reports no issues
10. Release APK installed and manually tested

Practice

1. Write your own definition of done for the app.
2. For each item, name the module that built it.
3. List the evidence command or test for each item.
4. Why define done before building?

Project step: Write DayList's definition of done: the ten features that must work, and the evidence command or test for each.

Wrap Up

Define done before building — a checklist turns a big app into small wins.

Build the Capstone

Sources: docs.flutter.dev/testing

Theory

Integration order matters: wire state and navigation first, then data, then cloud, then polish. After every integration run the full verification loop — flutter analyze, flutter test, and a manual pass of the checklist.

Demonstration

# integration order
1. Theme + routes + TaskStore wiring
2. SQLite persistence behind TaskStore
3. Firestore sync + StreamBuilder list
4. Auth gate with authStateChanges
5. Storage attachments + detail screen
6. Reminders + notifications permission
7. Animations + responsive two-pane
8. Tests for store and tiles

# verify after each step
flutter analyze
flutter test
flutter run   # manual pass

Practice

1. Follow the integration order step by step.
2. After each step, run flutter analyze and flutter test.
3. Complete a manual pass of your definition of done.
4. What does flutter analyze catch that tests do not?

Project step: Complete any missing DayList feature and pass the full loop: flutter analyze clean, all tests green, and a manual run of the done checklist.

Wrap Up

Assemble what you built module by module — the capstone is integration, not new features.

Capstone Review and Rubric

Sources: docs.flutter.dev

Theory

The final review proves understanding: score the app honestly, then break it on purpose — remove a route, flip a field name, kill a listener — and fix each break with the evidence method. If you can break and repair it, you own it.

Demonstration

Practice

1. Score DayList on each rubric row.
2. Break a route, a field name, and a listener — fix each with evidence.
3. Write the one-paragraph release note.
4. What does the break/fix phase teach that building does not?

Project step: Run DayList's final review: score the rubric honestly, break three features and fix them with evidence, and write the one-paragraph release note.

Wrap Up

Ship it, break it, fix it — then show the work.

Study Plan

Follow this sequence, and do not skip the console apps — they are where the logic gets solid.

1. Dart first — work through Module 1 in DartPad. Type every example and rebuild each practice app without looking.
2. Install Flutter — follow the official setup guide and run the default counter app once before Module 2.
3. Widgets daily — one small screen per day: a card, a list, a form. Small screens beat big ones.
4. State before data — master setState and Provider patterns before touching APIs.
5. One real API — pick a public JSON API and build a screen around it; that exercise covers half of Module 4.
6. Capstone last — only start the capstone when Modules 1–6 are done; it assumes every pattern.

Rule of thumb: if you can rebuild yesterday's practice app from an empty file, you understood it. If not, that is today's task.

Learning Resources

The complete study stack for this track — official documentation, the browser playground, and the package ecosystem.