Mobile App Development & AI

In Module 4 you built a complete, navigable four-screen app using AI. Screens were generated, widgets were placed, navigation was connected, and the app was tested. AI did most of the heavy construction work — and that is exactly as it should be.

But now a critical question emerges — do you understand what AI built for you? Can you open a file in your project and read it with enough confidence to know what is happening? Can you make a small change without being afraid of breaking something? Can you describe a problem precisely enough that AI can fix it immediately — or find the problem yourself and fix it directly?

If the answer to any of those questions is no — Module 5 is exactly where you need to be. And even if you feel reasonably confident — this module will deepen that confidence into genuine mastery that serves you in every project you build from this point forward.

You do not need to become a traditional programmer to complete this module. You do not need to memorise syntax or learn to write Flutter code from scratch. What you need — and what this module builds — is the ability to read, navigate and understand the code AI generates. The ability to make confident small edits. The ability to explain problems clearly and apply AI-generated fixes correctly. That level of understanding is what separates a developer who uses AI from a developer who is controlled by AI. You direct. AI executes. Module 5 makes sure that relationship never reverses.

By the end of this module you will be able to:

✅ Open your project and navigate its file structure with complete confidence — knowing what every folder contains, what every file does, and exactly where to go when you need to find or change something specific.

✅ Read AI-generated Flutter code and understand what it does — not at an expert level but at a confident working level where the code no longer feels foreign or intimidating.

✅ Understand what a Widget is and how Flutter uses widgets to build every screen — the fundamental concept that underlies everything in your app's code.

✅ Make small but important manual edits directly in code — changing text labels, colours, sizes and simple logic without reprompting AI for every tiny change.

✅ Use AI to explain any part of your code you do not understand — turning confusion into clarity in seconds using a simple and highly effective technique.

✅ Identify and locate problems in your code — reading error messages, understanding what they mean, and knowing exactly where to look to fix them.

✅ Manage your app project professionally — keeping files organised, understanding what changes to commit, and maintaining a clean, well-structured project that grows sustainably as you add features.

Section 5.1 — Opening and Navigating Your Project Structure. A complete guided tour of your app project — every folder, every file, what it does and when you need to open it. By the end of 5.1 you will navigate your project like a developer who built it by hand — because you will know exactly where everything lives.

Section 5.2 — Understanding Flutter Widgets. Widgets are the building blocks of every Flutter app. Understanding what they are, how they nest inside each other, and how they build a screen from top to bottom is the most important conceptual breakthrough in this module — and in Flutter development generally.

Section 5.3 — Reading and Understanding AI-Generated Code. A practical, guided walkthrough of real code from your own app — explained in plain English, line by line, section by section. After this section code will never look the same to you again.

Section 5.4 — Making Manual Code Edits with Confidence. Practical exercises in making small, targeted edits directly in code — changing text, colours, sizes and simple values — using Acode on your phone or Cursor AI on your laptop. Building the muscle memory of confident code editing.

Section 5.5 — Reading Error Messages and Fixing Problems. A complete guide to understanding Flutter error messages — what they mean, where they come from, and how to resolve them using AI assistance and direct debugging.

A question students sometimes ask at this point in the course is — "If AI builds the code, why do I need to understand it?" It is a fair question. And it deserves a direct, honest answer.

Reason 1 — AI makes mistakes. AI is extraordinarily powerful but it is not perfect. It sometimes generates code that looks correct but has subtle logical errors. It sometimes misunderstands a prompt and builds something slightly different from what you described. A developer who cannot read their own code cannot catch these errors. A developer who can read their code catches them immediately — before they reach users.

Reason 2 — Clients and employers will ask you questions. When you deliver an app to a client they will ask — "How does the login work?" "What happens when a user deletes their account?" "Can we add a new field to the profile screen?" A developer who understands their code answers these questions confidently and immediately. A developer who does not understand their code cannot answer — and that destroys trust instantly.

Reason 3 — Features change. After your app is live, users will want new features, changes to existing features, and fixes to things that are not working as expected. Making these changes requires understanding what was built — where the relevant code lives, how it connects to other parts of the app, and what the impact of a change will be. An app that cannot be maintained is an app that cannot grow.

Reason 4 — AI works better when you understand the code. The more you understand what AI has built, the better prompts you write for changes and additions. Instead of saying "make the profile screen better" — you can say "in the ProfileScreen widget inside lib/screens/ profile_screen.dart, change the avatar Container border radius from 40 to 60 and increase the font size of the userName Text widget from 20 to 24." That level of precision produces instant, accurate results. Understanding your code makes you a dramatically more effective prompter.

Module 5 requires a different mindset from Modules 3 and 4. In those modules you were creating — building screens, generating designs, connecting navigation. The feedback was immediate and visual — you could see your progress on the canvas in real time.

Module 5 is about understanding — reading, analysing, interpreting. The feedback is internal — it happens in your mind as concepts click into place rather than on a screen in real time. This type of learning requires more patience and more deliberate attention. Do not rush through this module. Read each section slowly. Look at your own code as you read. Open the files being described. Find the exact elements being explained. Confirm that you see what is being described before moving to the next concept.

Every time something is unclear — open Gemini immediately. Do not sit with confusion for more than two minutes. Describe exactly what you are looking at, what you understand so far, and what specifically is unclear. Gemini will explain it in a different way that may connect more naturally with how you think. There is no shame in asking AI to explain something five different ways until one of them lands. That is not weakness — that is intelligent learning.

Every Flutter project — whether generated by AI, built in FlutterFlow, or written by hand — follows the same organised folder and file structure. This structure is not random. Every folder has a specific purpose. Every file lives exactly where it belongs. Understanding this structure means you always know where to look when you need to find, read or change something in your project.

Think of your project like a well-organised office building. Each floor is a folder. Each room is a file. The reception area is main.dart — the first place anyone enters. The offices are your screen files — where the real work happens. The supply room is the assets folder — where images and fonts are kept. The building's utilities panel is pubspec.yaml — controlling the resources and services the whole building depends on. Once you know the building's layout — you never get lost.

In this section we walk through every part of your project structure — opening each folder, reading each key file, and understanding exactly what role it plays. Follow along with your actual project open in Acode on your phone or Cursor AI on your laptop as you read. Reading about structure and seeing that structure in your own project at the same time is the fastest way to make this knowledge permanent.

📱 Phone Users — Opening in Acode:

Step 1 — Open Acode on your Android phone.

Step 2 — Tap the folder icon or the menu icon to open the file browser. Navigate to where your Flutter project is saved on your phone — this is usually in the Downloads folder or a folder you specified when you exported your project from FlutterFlow or created it in Sketchware.

Step 3 — Tap your project folder to open it. You will see a list of folders and files. This is the root of your Flutter project — the top level from which everything else is organised.

Step 4 — Do not open any file yet. First — look at the list of items at the root level. Note the names of every folder and file you see. In the next section we explain what each one does.

💻 Laptop Users — Opening in Cursor AI or VS Code:

Step 1 — Open Cursor AI or VS Code on your laptop.

Step 2 — Click File in the top menu bar. Select Open Folder. Navigate to your Flutter project folder and click Open or Select Folder.

Step 3 — The Explorer panel on the left side now shows your complete project folder structure. Every folder and file is listed in a tree view — you can expand folders by clicking the arrow next to them.

Step 4 — Do not open any file yet. Look at the root level items listed in the Explorer. Note every folder name and file name at the top level of the project.

Here is a complete explanation of every folder and file you will see at the root of your Flutter project. Read each one, find it in your own project, and confirm you can locate it before moving on.

The lib/ Folder — The Heart of Your App
This is the most important folder in your entire project. Every screen, every widget, every piece of logic, every line of code that makes your app function lives inside the lib folder. When you need to change anything about how your app looks or behaves — you will almost always be working in the lib folder. Open it now and look at what is inside.

lib/main.dart — The Starting Point
This is the very first file that runs when a user opens your app on their phone. It is the entry point — the front door of your entire application. It tells Flutter which screen to show first, sets up the app's theme — colours and fonts — and initialises any services the app needs before showing the first screen. Open this file now and look at it. You do not need to understand every line yet — we will read it together in section 5.3.

lib/screens/ — Your App Screens
Inside the lib folder there is usually a screens folder — sometimes called pages. Each file inside this folder is one screen of your app. You should see files like login_screen.dart, home_screen.dart, detail_screen.dart and profile_screen.dart — the four screens you built in Module 4. When you need to change anything on a specific screen — this is where you go. Open the screens folder and confirm all four screen files are there.

lib/widgets/ — Reusable Components
This folder contains widgets that are used on more than one screen — things like a custom card design, a custom button style, or the bottom navigation bar. Rather than building the same widget five times on five different screens — it is built once in the widgets folder and used everywhere. This is one of the most important principles of professional Flutter development — build once, reuse everywhere.

assets/ — Images, Icons and Fonts
This folder contains all the static files your app uses — your app icon, your splash screen image, any background images, custom font files, and any other media files. When you added your app icon to the project in Module 3 — it went into this folder or a subfolder of it. You should see your app-icon.png and splash-screen.png here.

pubspec.yaml — The Project Configuration File
This is one of the most important files in your project — and one of the most commonly misunderstood by beginners. The pubspec.yaml file is the configuration file for your entire project. It contains your app's name, its version number, a list of all the external packages your app depends on — like Firebase, image loaders and animation libraries — and a declaration of all the asset files your app uses. Any time you add a new package or a new asset file to your project, you must update this file. Open it now and look at its contents — we will read it together in section 5.3.

android/ — Android Platform Files
This folder contains all the Android-specific configuration for your app — settings that apply when the app runs on an Android device. Things like the app's package name, the minimum Android version it supports, and permissions the app requests from the user. You will rarely need to edit files in this folder — but you should know it exists and what it contains.

ios/ — iOS Platform Files
The equivalent of the android folder but for Apple devices — iPhone and iPad. Contains iOS-specific settings and configurations. You will only need to work in this folder when preparing your app for the Apple App Store — and even then AI assists with the specific changes needed.

test/ — Automated Tests
This folder is where automated test files live — code that automatically checks that specific parts of your app work correctly. Testing is covered in Module 7. For now just know this folder exists and what it is for.

.gitignore — What GitHub Should Ignore
This hidden file tells GitHub which files and folders to NOT include when you commit your code. Things like temporary build files, local configuration files, and private keys should never be shared on GitHub — the .gitignore file ensures they are not. You should not edit this file unless you have a specific reason to.

README.md — Your Project Description
This is the file you edited in Module 2 when you set up GitHub. It appears on your GitHub repository's homepage and describes what the project is, what it does, and how to use it. Keep this file updated as your project grows — a well-maintained README makes your portfolio look professional and communicates your work clearly to clients and employers.

Now that you know every part of your project structure — here is the single most useful rule for navigating it quickly and confidently in any situation:

"When you need to change something on a screen → go to lib/screens/
When you need to change a shared component → go to lib/widgets/
When you need to add an image or font → go to assets/ and then update pubspec.yaml
When you need to add a new package → update pubspec.yaml
When you need to change the starting screen → go to lib/main.dart"

Memorise this rule. Write it in your notes. Screenshot it. Refer to it whenever you are unsure where to go in your project. Five rules. Five situations. Always know where to go.

This exercise builds real navigation confidence in your own specific project. Do not skip it — the confidence built here directly supports every section that follows in Module 5.

Exercise Steps — Complete All Before Moving to Section 5.2:

Step 1 — Open your project in Acode or Cursor AI. Open a note on your phone and title it "My Project Map."

Step 2 — In your note write down every folder and file you can see at the root level of your project. Next to each one write one sentence describing what it does — based on what you learned in section 5.1.2. Do this from memory first. Then check against the section to confirm and correct any mistakes.

Step 3 — Open the lib/screens/ folder. Write down the name of every file inside it. Next to each file name write the screen it represents. Confirm that all four screens from Module 4 are present — login_screen.dart, home_screen.dart, detail_screen.dart and profile_screen.dart (your file names may vary slightly depending on your app name).

Step 4 — Open lib/main.dart. Do not try to understand every line yet. Just scroll through it slowly and look for things you recognise — screen names, colour values, font names, your app name. Write down in your note: three things you recognised in main.dart and one thing you did not recognise or understand.

Step 5 — Open pubspec.yaml. Scroll through it slowly. Look for your app name, your version number, and the list of dependencies — the packages your app uses. Write down the names of three packages you see listed. Then open Gemini and ask: "I found these three packages in my Flutter app's pubspec.yaml file: [list your three packages]. Can you explain in plain English what each one does and why my app might be using it?" Read the explanations carefully.

Step 6 — Open the assets/ folder. Confirm your app-icon.png and splash-screen.png are present. If they are — write "assets folder confirmed" in your note. If any are missing — add them to the folder now.

Step 7 — Save your "My Project Map" note. This document is your personal reference for your specific project structure. You now know your project better than most developers know theirs after a week of working on it. That is the IT International Academy standard.

If there is one concept in Flutter that unlocks everything else — it is the Widget. In Flutter everything is a widget. The button on your screen is a widget. The text label next to it is a widget. The column arranging them vertically is a widget. The padding creating space around them is a widget. The background colour of the screen is a widget. The entire screen itself is a widget.

This is not an exaggeration. It is the fundamental design philosophy of Flutter — and once you truly understand it, reading Flutter code becomes significantly easier. Because when you look at any screen in your app and any line of code that builds it — you are always looking at widgets. Widgets containing widgets containing widgets. Once you see Flutter as a tree of widgets — the code stops being a mystery and starts being a map.

A widget is a description of a part of a user interface. It is a blueprint — not the actual visual element itself, but the instructions that tell Flutter how to draw and behave that visual element on screen.

Think of a widget like a recipe. The recipe is not the meal — it is the precise instructions for creating the meal. A Text widget is not the text you see on screen — it is the instructions for Flutter to draw that text with a specific font, size, colour and alignment. Flutter reads those instructions and creates the visual result you see.

Every widget in Flutter is defined in code as a Dart class. You do not need to know how to write Dart classes — but you need to recognise them when you see them. A widget in code looks like this:

Text(
  "Welcome to SchoolNote",
  style: TextStyle(
    fontSize: 24,
    fontWeight: FontWeight.bold,
    color: Colors.white,
  ),
)

Read that code like plain English: Draw a Text widget that displays "Welcome to SchoolNote" — with a font size of 24, bold weight, and white colour. That is exactly what it says — just in Flutter's language rather than English. Once you start reading code this way — as plain English instructions written in a specific format — it becomes far less intimidating.

Now look at your own home_screen.dart file in Acode or Cursor AI. Find any Text widget. Read its properties. Can you understand what text it displays and how it is styled? If yes — you are already reading Flutter code. You were doing it without realising it.

There are hundreds of widgets in Flutter — but you do not need to know all of them. You need to know the ones that appear in almost every screen of almost every app. Master these and you can read and understand the vast majority of Flutter code you will ever encounter.

Text Widget — Displays a string of text on screen. The most commonly used widget in any app. Properties include the text content, font size, font weight, colour, alignment and maximum number of lines. Every label, title, button text, and paragraph in your app is a Text widget.

Text(
  "Announcement Title",
  style: TextStyle(
    fontSize: 18,
    fontWeight: FontWeight.bold,
    color: Color(0xFFFFFFFF),
  ),
  maxLines: 2,
  overflow: TextOverflow.ellipsis,
)

Container Widget — A box that can hold one child widget and apply styling to it — background colour, border, border radius, padding, margin and size. The Container is one of the most versatile and frequently used widgets. Every card, every coloured box, every bordered element in your app is likely a Container or built on one.

Container(
  width: double.infinity,
  padding: EdgeInsets.all(16),
  decoration: BoxDecoration(
    color: Color(0xFF0D1B3E),
    borderRadius: BorderRadius.circular(16),
  ),
  child: Text("Content goes here"),
)

Column Widget — Arranges its children vertically — stacked on top of each other from top to bottom. This is the primary layout widget for vertical arrangements. Most app screens are built on a Column — everything stacks downward from the header to the bottom navigation bar.

Column(
  crossAxisAlignment: CrossAxisAlignment.start,
  children: [
    Text("Title"),
    SizedBox(height: 8),
    Text("Subtitle"),
  ],
)

Row Widget — Arranges its children horizontally — side by side from left to right. Used whenever you need elements next to each other — like an icon and a label, or a name and a date on the same line. Your metadata row in the Detail Screen was built with a Row widget.

Row(
  mainAxisAlignment: MainAxisAlignment.spaceBetween,
  children: [
    Text("Mr. Banda"),
    Text("2 hours ago"),
  ],
)

Scaffold Widget — The base structure for a complete app screen. Every screen in a Flutter app starts with a Scaffold — it provides the basic visual structure including the AppBar at the top, the body content area in the middle, and optional elements like a Floating Action Button or Bottom Navigation Bar. When you open any of your screen files you will see a Scaffold as the outermost widget.

Scaffold(
  backgroundColor: Color(0xFF060D24),
  appBar: AppBar(
    title: Text("SchoolNote"),
  ),
  body: Column(
    children: [
      // screen content here
    ],
  ),
)

ListView Widget — Creates a scrollable list of items. Every scrollable list in your app — the announcement list on the Home Screen, a list of products, a list of messages — is a ListView. It efficiently displays many items by only rendering the ones currently visible on screen — making it fast even with hundreds of items.

ListView(
  padding: EdgeInsets.all(16),
  children: [
    AnnouncementCard(),
    AnnouncementCard(),
    AnnouncementCard(),
  ],
)

ElevatedButton Widget — A filled button that responds to taps. The primary action button on any screen — your Sign In button, your Submit button, your Mark as Read button — is an ElevatedButton or a similar button widget. It has an onPressed property — the function that runs when the button is tapped.

ElevatedButton(
  onPressed: () {
    // action when button is tapped
  },
  style: ElevatedButton.styleFrom(
    backgroundColor: Color(0xFFFF6B6B),
    foregroundColor: Colors.white,
  ),
  child: Text("Sign In"),
)

SizedBox Widget — An invisible box used purely for spacing. When you need a gap between two elements — a space between a title and a subtitle, or between a button and the text above it — you add a SizedBox with a specific height or width. It does not display anything visible — it is purely empty space.

SizedBox(height: 16) // adds 16px of vertical space
SizedBox(width: 8) // adds 8px of horizontal space

Padding Widget — Adds space inside a widget — between the widget's boundary and its content. Similar to SizedBox but applied around a child widget rather than as a standalone spacer. The difference between Padding and SizedBox: Padding wraps around something and pushes its edges in. SizedBox is a blank space between things.

Padding(
  padding: EdgeInsets.symmetric(
    horizontal: 20,
    vertical: 12,
  ),
  child: Text("Content with padding"),
)

Image Widget — Displays an image on screen. Can load images from your assets folder — like your app icon — or from the internet using a URL. The Image widget accepts properties for width, height, and how the image fills its space — whether it is cropped, fitted, or stretched.

Image.asset(
  "assets/app-icon.png",
  width: 80,
  height: 80,
)

TextField Widget — A text input field where the user can type. Your email and password fields on the Login Screen are TextField widgets. Properties include the hint text, keyboard type, obscure text for passwords, and a controller that captures what the user types.

TextField(
  keyboardType: TextInputType.emailAddress,
  decoration: InputDecoration(
    labelText: "Email Address",
    labelStyle: TextStyle(color: Colors.grey),
  ),
)

In Flutter every screen is a tree of widgets — widgets nested inside other widgets, which are nested inside more widgets, all the way down to the smallest text label. Understanding the widget tree is the key to reading any Flutter screen's code and understanding exactly how it is built.

Here is the widget tree of a simple card from your Home Screen — shown both as a diagram and as code:

Read that tree from top to bottom: A Container holds everything. Inside it Padding creates space. Inside that a Column stacks items vertically. The Column contains a title Text, a gap, a Row with author and date side by side, another gap, and a preview Text. Every element of the card accounted for — every relationship between elements clear.

Now open your home_screen.dart file in Acode or Cursor AI. Find the card code. Try to trace the same tree structure in your own code. The widget names may be exactly the same as above — because this is the standard way to build a card in Flutter. When you can trace the widget tree from code to the visual result you see on screen — you understand Flutter.

This exercise directly applies everything you learned in section 5.2 to your own real code. Do not skip it — by the end you will have read and understood your entire Login Screen's code.

Exercise Steps — Complete All Before Moving to Section 5.3:

Step 1 — Open login_screen.dart in Acode or Cursor AI.

Step 2 — Scroll through the file slowly. Every time you see a widget name from the list in section 5.2.2 — highlight it or note it down. How many Text widgets can you find? How many Containers? Any Columns? Any Rows? Any SizedBoxes? Any TextFields?

Step 3 — Find the Scaffold widget — it should be near the top of the screen's build method. Confirm it has a backgroundColor property set to your primary colour.

Step 4 — Find the Text widget that displays your app name. Read its TextStyle properties. Does the fontSize match your Design Spec? Does the colour match? Does the fontWeight match?

Step 5 — Find the TextField for the email input. Find the keyboardType property. Confirm it is set to TextInputType.emailAddress.

Step 6 — Find the ElevatedButton for Sign In. Find its backgroundColor in the style property. Confirm it matches your action colour from your Design Specification.

Step 7 — Find one widget in the file that you do not recognise or understand. Copy its name and properties. Open Gemini. Paste it and ask: "I found this widget in my Flutter login screen code. Can you explain in plain English what it does and why it is being used here?" Read the explanation.

Step 8 — In your notes write: "Login Screen Widget Count — Text: [number], Container: [number], Column: [number], Row: [number], SizedBox: [number], TextField: [number], ElevatedButton: [number]." This count shows you just how many individual widgets make up even a simple screen. Every one of them you now recognise and understand.

In section 5.2 you learned what widgets are and identified them in your login screen. In this section we go deeper — reading actual code from your app, understanding what every part does, and building the confidence to look at any file in your project and make sense of it.

Reading code is a skill — and like every skill it improves with deliberate practice. The first time you read a page of Flutter code it may feel overwhelming. The tenth time it feels familiar. The fiftieth time it feels natural. This section gives you your first structured, guided reading experience — so that the tenth and fiftieth times come faster and feel more confident.

We will read two key files from your project together — main.dart and your home_screen.dart. Every line we read will be explained in plain English. Every unfamiliar term will be defined. By the end of this section you will have read real Flutter code — not simplified examples, not shortened versions, but the actual code running in your actual app — and you will understand it.

Open main.dart in Acode or Cursor AI. Every Flutter app's main.dart looks similar — it follows a predictable structure that rarely changes between projects. Understanding it once means you understand it in every Flutter project you will ever open.

Here is a typical main.dart file with every section explained in plain English:

import 'package:flutter/material.dart';

Plain English: This line imports the Flutter Material library — the collection of pre-built widgets and tools that Flutter provides. Without this import nothing in Flutter works. You will see this line at the top of almost every Flutter file. Think of it as "loading the Flutter toolkit before using it."

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

Plain English: This is the very first function that runs when your app is opened. "void main()" means "here is where everything starts." The only thing it does is call runApp() — which tells Flutter to start running the app using the MyApp widget as the root. Everything in your app flows from this single function call.

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

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'SchoolNote',
      debugShowCheckedModeBanner: false,
      theme: ThemeData(
        primaryColor: Color(0xFF060D24),
        fontFamily: 'Poppins',
      ),
      home: LoginScreen(),
    );
  }
}

Plain English — line by line:

class MyApp extends StatelessWidget — This defines the root widget of your entire app. StatelessWidget means this widget never changes — it is always the same every time it is built.

Widget build(BuildContext context) — This is the function that tells Flutter what to display. Every widget has a build function. Flutter calls this function whenever it needs to draw the widget on screen.

return MaterialApp( — This returns a MaterialApp widget — the top-level widget that wraps your entire app and provides global settings like the theme and the starting screen.

title: 'SchoolNote' — The name of your app. This appears in the device's task switcher when the user switches between apps.

debugShowCheckedModeBanner: false — Removes the red "DEBUG" banner that appears in the top right corner during development. Setting this to false makes preview look cleaner.

theme: ThemeData( — Sets the global theme for your entire app — the default colours, fonts and styles that apply everywhere unless overridden on a specific widget.

home: LoginScreen() — This is the most important line in main.dart. It tells Flutter which screen to show first when the app opens. Changing LoginScreen() to HomeScreen() here would make the app open on the home screen instead of the login screen.

Open home_screen.dart. This is the most complex file in your project — it contains the most widgets and the most code. Do not be intimidated by its length. Read it section by section — the same way you read a long document. One paragraph at a time.

Here is the typical structure of a home screen file — every major section explained:

import 'package:flutter/material.dart';
import '../widgets/announcement_card.dart';
import 'detail_screen.dart';

Plain English: The imports at the top of every file load the tools and other files this file needs. The first import loads Flutter's toolkit. The second imports a custom widget from your widgets folder — the announcement card component. The third imports the detail screen so this file can navigate to it. Every file only imports what it specifically needs.

class HomeScreen extends StatefulWidget {
  const HomeScreen({super.key});

  @override
  State<HomeScreen> createState() => _HomeScreenState();
}

Plain English: This defines the HomeScreen as a StatefulWidget — unlike the StatelessWidget in main.dart. Stateful means this widget can change — it can update itself when something happens, like when the user selects a different filter chip or new data loads from the database. The createState() function creates the state object that manages those changes. You will see StatefulWidget on any screen that needs to update its content dynamically.

class _HomeScreenState extends State<HomeScreen> {

  String selectedFilter = 'All';

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      backgroundColor: const Color(0xFF060D24),
      body: Column(
        children: [
          // header
          // filter chips
          // list
        ],
      ),
      bottomNavigationBar: ...,
    );
  }
}

Plain English — section by section:

class _HomeScreenState — This is the state class that manages all the dynamic behaviour of the home screen. The underscore before the name means it is private — only accessible within this file.

String selectedFilter = 'All' — This is a state variable. It stores which filter chip is currently selected. When the user taps a different chip, this variable updates and the screen rebuilds to show the new selection. This is how Flutter manages changing data on a screen.

Widget build(BuildContext context) — The build function that Flutter calls to draw the screen. Every time the state changes — like when selectedFilter updates — Flutter calls this function again and rebuilds the screen with the new state.

backgroundColor: const Color(0xFF060D24) — Sets the screen background to your primary dark navy colour. The 0xFF prefix before the hex code is Flutter's way of specifying a fully opaque colour. 0xFF means 100% opacity. Your hex code #060D24 becomes 0xFF060D24 in Flutter code.

body: Column(children: [...]) — The body is the main content area of the screen. A Column widget stacks all content vertically. Inside the children list you will find the header, the filter chips and the list.

bottomNavigationBar: ... — The bottom navigation bar is placed here — as a separate property of the Scaffold, not inside the body. This is how the navigation bar stays fixed at the bottom while the body content scrolls.

Find the code that navigates from the Home Screen to the Detail Screen when a card is tapped. It will look something like this:

GestureDetector(
  onTap: () {
    Navigator.push(
      context,
      MaterialPageRoute(
        builder: (context) => const DetailScreen(),
      ),
    );
  },
  child: AnnouncementCard(),
)

Plain English — line by line:

GestureDetector — A widget that detects user gestures — taps, swipes, long presses. It wraps another widget and adds interaction to it. The AnnouncementCard itself does not know how to respond to taps — the GestureDetector wrapping it does.

onTap: () { — This property defines what happens when the user taps. The code inside the curly braces runs when the tap occurs.

Navigator.push( — Navigator is Flutter's built-in navigation system. Push means "add a new screen on top of the current one." The user can press back to pop it off and return to the previous screen. This is Navigate To in FlutterFlow's terms.

context — Context is information about where in the widget tree this code is running. Navigator needs context to know which app and which screen it is working with. You will see context passed to many functions in Flutter — it is always available inside a build function.

MaterialPageRoute(builder: (context) => const DetailScreen()) — This creates the route — the navigation path — to the DetailScreen. MaterialPageRoute gives the transition a standard slide animation. The builder creates an instance of DetailScreen to display when navigation occurs.

child: AnnouncementCard() — The widget that the GestureDetector wraps. The card is still the visual element the user sees — but now tapping it triggers the navigation defined above.

No matter how much you study — you will encounter code you do not understand. That is not a failure — it is the normal experience of every developer at every level of experience. The difference between a struggling developer and a progressing one is not the absence of confusion — it is having an effective system for resolving confusion quickly. AI is that system. And used correctly it is extraordinarily effective.

Here is the exact technique for using Gemini or ChatGPT to understand any code you encounter:

The Code Explanation Technique — Step by Step:

Step 1 — Find the code you do not understand. Select it in Acode or Cursor AI.

Step 2 — Copy the code. On Acode — long press to select, then tap Copy. On Cursor AI — Ctrl+C after selecting.

Step 3 — Open Gemini on your phone or in your browser.

Step 4 — Type this prompt — filling in the blank with what you know: "I am a beginner learning Flutter. I am reading my app's home screen code. Here is a section of code I do not understand: [paste your code here]. Can you explain in very simple plain English what each line does? Please avoid technical jargon and explain it as if I have never coded before."

Step 5 — Read Gemini's explanation carefully. If something in the explanation is still unclear — ask a follow-up question: "You mentioned [specific term]. Can you explain what that means in even simpler terms with a real-world analogy?"

Step 6 — After reading the explanation — go back to the code. Read it again. Does it make more sense now? Write a one-line plain English summary of what that section of code does in your notes.

Step 7 — Move to the next section of code you do not understand and repeat. Over time the sections you need to ask about become shorter and fewer — because your vocabulary and pattern recognition grow with every explanation.

One important note about this technique: Do not ask Gemini to explain your entire file at once. Ask about specific sections — five to fifteen lines at a time. Smaller sections produce clearer, more useful explanations. And understanding builds faster when you process small pieces deliberately rather than large chunks quickly. Quality of understanding over speed of coverage — every time.

Exercise Steps — Complete All Before Moving to Section 5.4:

Step 1 — Open main.dart in your editor. Find the home: line inside MaterialApp. Confirm it points to LoginScreen. Write in your notes: "main.dart home property currently points to: LoginScreen. To change the starting screen I would change this to: [screen name]."

Step 2 — In main.dart find the ThemeData section. Find the primaryColor value. Confirm it matches your Design Specification primary colour. Find the fontFamily value. Confirm it matches your heading font. If either does not match — note the discrepancy. We fix discrepancies in section 5.4.

Step 3 — Open home_screen.dart. Find the class declaration at the top. Does it say StatelessWidget or StatefulWidget? Write in your notes why the home screen needs to be Stateful — what changes on this screen that requires state?

Step 4 — In home_screen.dart find the navigation code that connects a card tap to the Detail Screen. Copy the entire GestureDetector or InkWell or onTap section. Paste it into Gemini and ask it to explain every line in plain English. Write a one-paragraph summary in your notes of how navigation works in Flutter based on Gemini's explanation.

Step 5 — Find the colour value for the card background in home_screen.dart. It will be something like Color(0xFF0D1B3E). Convert 0xFF0D1B3E to a hex code by removing the 0xFF prefix — giving you #0D1B3E. Does that match your Design Specification card background colour? Write the answer in your notes.

Step 6 — Find one section of code in home_screen.dart that you still do not fully understand after reading sections 5.2 and 5.3. Use the Code Explanation Technique from section 5.3.4 to get a clear plain English explanation from Gemini. Write the explanation in your notes in your own words — not copied from Gemini but rewritten in the way that makes most sense to you personally.

Step 7 — Open profile_screen.dart. Without using Gemini — try to read through the file and identify: the Scaffold widget, the Column or main layout widget, the Text widget showing the user name, and the logout button widget. Write down what you found. This tests whether the pattern recognition from this section is building correctly. If you found all four — your code reading skill is developing excellently.

You can now navigate your project structure confidently, recognise widgets on sight, and read entire files with understanding. The next step turns that understanding into action — making real, targeted edits directly in your code, with confidence, without fear of breaking anything.

Many beginners avoid touching code directly — relying entirely on AI to make every single change, even tiny ones like fixing a typo or adjusting a font size by two pixels. This is slow and unnecessary. Small, simple edits are often faster to make directly than to write a prompt for. A developer who can make small edits confidently works significantly faster than one who reprompts AI for every minor change.

This section builds that confidence through deliberate, guided practice — making real edits to your real project, one small change at a time.

Before making any manual edit — follow these three rules every single time. They protect you from the most common mistakes beginners make when editing code directly.

Rule One — Always commit to GitHub before editing. Before you change anything manually, save and commit your current working version to GitHub. This creates a safety checkpoint. If your edit goes wrong and you cannot figure out how to fix it — you can always return to this checkpoint and your app will work exactly as it did before you started editing.

Rule Two — Change one thing at a time. Do not make five edits and then test. Make one edit. Save. Test. Confirm it works. Then make the next edit. This way if something breaks — you know exactly which edit caused it, because it is the only thing you changed since the last successful test.

Rule Three — Match existing patterns exactly. When editing a value — like a colour, a font size, or a piece of text — copy the exact formatting style already used in that file. If colours are written as Color(0xFF060D24) — write your new colour the same way. If padding values use EdgeInsets.all(16) — follow that same pattern. Consistency in formatting prevents errors and keeps your code readable.

The simplest and most common manual edit is changing displayed text — fixing a typo, updating a label, or changing placeholder content to something more accurate.

Step by Step — Editing Text:

Step 1 — Open profile_screen.dart in Acode or Cursor AI.

Step 2 — Find the Text widget showing the placeholder name "Atake Favor Felix" from Module 4. It will look like: Text("Atake Favor Felix")

Step 3 — Tap or click directly between the quotation marks. Select the existing text. Type your replacement text — keeping the quotation marks exactly as they are. Only the text inside the quotes changes.

Step 4 — Save the file. In Acode tap the save icon in the bottom toolbar. In Cursor AI press Ctrl+S.

Step 5 — Open FlutterFlow or your preview tool and confirm the text updated correctly on the Profile Screen.

Important: Never delete the quotation marks themselves — only change what is between them. The quotation marks tell Flutter "this is a string of text" — removing them causes an error because Flutter no longer understands what you are giving it.

Changing a colour is one of the most frequent edits you will make as your app evolves and your design preferences are refined.

Step by Step — Editing a Colour:

Step 1 — Open home_screen.dart. Find a colour value — for example the card background: color: Color(0xFF0D1B3E)

Step 2 — Understand the format. 0xFF is the opacity prefix — always keep this exactly as is for a fully visible colour. The six characters after it are your hex code — 0D1B3E corresponds to #0D1B3E.

Step 3 — To change this colour — select only the six characters after 0xFF. Replace them with your new hex code without the # symbol. For example to change to gold #D4AF37 — the line becomes: color: Color(0xFFD4AF37)

Step 4 — Save the file and preview to confirm the colour updated correctly.

Important: Always keep exactly six characters after 0xFF — never more, never fewer. Hex colour codes are always six characters representing red, green and blue values. If your hex code looks shorter, like #FFF, expand it to its full six-character form before using it in Flutter — #FFF becomes #FFFFFF.

Adjusting how large or bold text appears is another extremely common manual edit — often done after seeing your design on a real device and realising something needs to be slightly bigger or smaller for comfortable reading.

Step by Step — Editing Font Size and Weight:

Step 1 — Find a TextStyle in your code: style: TextStyle(
  fontSize: 18,
  fontWeight: FontWeight.bold,
  color: Color(0xFFFFFFFF),
)

Step 2 — To change the size — select the number after fontSize: and replace it with your new value. Font sizes in Flutter are simple numbers — no px or units needed. Changing 18 to 22 makes the text noticeably larger.

Step 3 — To change the weight — fontWeight accepts specific values: FontWeight.w300 (light), FontWeight.normal (regular), FontWeight.w500 (medium), FontWeight.w600 (semibold), FontWeight.bold (bold). Replace the existing value with your desired weight exactly as written above — including the FontWeight. prefix.

Step 4 — Save and preview to confirm the change looks correct and readable.

Spacing edits adjust how much breathing room exists between or around elements — one of the most impactful types of edits for making a screen feel polished rather than cramped or sparse.

Step by Step — Editing Spacing:

Step 1 — Find a SizedBox controlling vertical spacing: SizedBox(height: 8)

Step 2 — Change the number to increase or decrease the gap. Increasing 8 to 16 doubles the space. Decreasing to 4 tightens it. Small adjustments of 4 to 8 pixels usually make a noticeable visual difference without being drastic.

Step 3 — Find a Padding or EdgeInsets value: padding: EdgeInsets.all(16)
This adds 16px of space on all four sides equally. To change spacing on specific sides only — use EdgeInsets.symmetric or EdgeInsets.only:
padding: EdgeInsets.symmetric(
  horizontal: 20,
  vertical: 12,
)
This applies 20px left and right, 12px top and bottom — useful when horizontal and vertical spacing need to differ.

Step 4 — For one-sided spacing only: padding: EdgeInsets.only(
  left: 20,
  top: 8,
)
Only left and top spacing is applied — right and bottom remain at zero.

Step 5 — Save and preview after every spacing change. Spacing edits are highly visual — always confirm the result looks correct before moving to the next edit.

Beyond visual edits — you can also make simple edits to logic and data values directly in code. This is slightly more advanced but still very achievable with the pattern recognition you have built throughout Module 5.

Example — Changing a Default State Value:

In your home_screen.dart you may have: String selectedFilter = 'All';

This sets which filter chip is selected by default when the screen first opens. To make "Today" the default selection instead of "All" — change the text between the quotes: String selectedFilter = 'Today';

Example — Changing a Sample Data Value:

In your sample announcement card you may have: title: "School Reopening Date",

To change the sample content — replace the text between the quotes following the same pattern used for text edits in section 5.4.2.

When an edit feels beyond simple text, colour or spacing changes — that is your signal to either ask Gemini for guidance using the Code Explanation Technique from section 5.3.4, or to write a precise refinement prompt and let AI make the change for you. Manual editing is for simple, well-understood changes. Complex logic changes are better handled by AI — with you reviewing and understanding the result. Knowing which approach to use for which type of change is itself a professional skill.

This exercise has you make five real, deliberate edits to your own project — one of each type covered in this section. Follow Rule One from section 5.4.1 first.

Exercise Steps — Complete All Before Moving to Section 5.5:

Step 1 — Commit your current project to GitHub with the message: "Checkpoint before manual editing practice" This is your safety net for the exercise.

Step 2 — Edit 1, Text: Open profile_screen.dart and change the placeholder user name to your real name. Save and preview.

Step 3 — Edit 2, Colour: Open home_screen.dart and change the selected filter chip colour to a different colour from your palette — for example switch from gold to mint if you have one in your palette. Save and preview.

Step 4 — Edit 3, Font Size: Open detail_screen.dart and increase the content title font size by 4 — from 24 to 28 for example. Save and preview. Does it look better, worse, or the same? Note your observation.

Step 5 — Edit 4, Spacing: Open login_screen.dart and increase the SizedBox gap between the app icon and the app name by 8 pixels. Save and preview.

Step 6 — Edit 5, Simple Value: Open home_screen.dart and change one sample announcement's title text to something new and relevant to your app. Save and preview.

Step 7 — After all five edits — review your complete app. Does everything still work correctly? Does navigation still function? If any edit caused an unexpected problem — use the Code Explanation Technique to understand the error, or revert that specific edit back to its original value.

Step 8 — Commit your changes to GitHub with the message: "Completed manual editing practice — five successful edits across text, colour, font, spacing and data values"

Reflect on this exercise: You just made five real changes directly in your app's code — without writing a single AI prompt. That is a meaningful milestone. You are no longer entirely dependent on AI for every change, no matter how small. You can act directly and confidently when the situation calls for it.

Every developer encounters errors. Not occasionally — constantly. Errors are not a sign that something is wrong with you as a developer. They are simply part of the process of building anything real. What separates a confident developer from a frustrated one is not the absence of errors — it is the ability to read an error message, understand what it is telling you, and resolve it efficiently.

This final section of Module 5 teaches you exactly that — how Flutter error messages are structured, how to read them without panic, and how to combine your own understanding with AI assistance to resolve problems quickly and confidently. By the end of this section seeing a red error screen will no longer feel like a crisis — it will feel like a clue.

Flutter reports problems in your code in a few different ways, depending on when the problem occurs and how serious it is.

Build-Time Errors — These occur when Flutter cannot even compile your app — meaning it cannot turn your code into a running application at all. These are usually caused by typos, missing punctuation, or incorrect syntax. When this happens you will typically see a red error message in your terminal or build output, before the app even attempts to run.

Runtime Errors — These occur after your app has successfully started running, but something goes wrong while it is actually being used — for example, trying to display data that does not exist yet, or tapping a button whose action was not configured correctly. Flutter displays these as a red error screen directly inside your running app, often called the "red screen of death" by developers — a memorable but harmless name for a very common and very fixable situation.

Warnings — These are not errors that stop your app from running — they are suggestions or notices about code that works but could be written better, or about features that are deprecated and should be updated. Warnings appear in yellow or orange rather than red, and your app continues to function normally even with warnings present.

Flutter error messages look intimidating at first glance — long blocks of red text filled with unfamiliar terms. But every error message follows a predictable structure. Once you know what to look for, you can extract the useful information quickly, even from a long and complex-looking error.

════════ Exception caught by widgets library ════════════════════════
The following _TypeError was thrown building HomeScreen(dirty, state:
_HomeScreenState#a3f2):
type 'Null' is not a subtype of type 'String'

The relevant error-causing widget was:
HomeScreen
lib/screens/home_screen.dart:12

When the exception was thrown, this was the stack:
#0 _HomeScreenState.build
(package:schoolnote/screens/home_screen.dart:45:23)

Do not be intimidated by the length of this. Here is exactly what to focus on:

The Error Type — Look for the word right before "was thrown" — in this example "_TypeError." This tells you the general category of the problem. A TypeError usually means you are trying to use one kind of data where Flutter expected a different kind — for example trying to display text where Flutter expected a number, or trying to use empty data where Flutter expected something to actually be there.

The Specific Message — The line directly describing the problem in more detail. In this example: "type 'Null' is not a subtype of type 'String'" — this means somewhere in your code, something that was expected to be text (a String) turned out to be nothing at all (Null). This usually happens when data has not loaded yet, or a value was never set.

The File and Line Number — This is the single most useful piece of information in any error message. In the example: lib/screens/home_screen.dart:12 tells you the exact file and exact line where the problem originates. Always look for this — it tells you precisely where to go in your project to investigate further.

The Stack Trace — The list of lines starting with #0, #1, #2 and so on shows the sequence of function calls that led to the error — like a trail of breadcrumbs showing exactly how Flutter arrived at the problem. As a beginner you do not need to read the entire stack trace — focus on the first one or two lines, which are usually closest to where the actual problem is.

Here are the errors you are most likely to encounter as a beginner — what each one means in plain English, and the general direction to look for a fix.

"The following _TypeError was thrown" — Null is not a subtype of type String/int/etc.
Meaning: Something expected to have a value is empty or missing. This often happens when data has not finished loading from a database, or when you reference a value that was never properly set. Where to look: The file and line number given in the error — check whether the variable being used actually has a value at that point in the code.

"RenderFlex overflowed by [X] pixels"
Meaning: Content is too large to fit in the available space — usually text, a row, or a column trying to take up more room than the screen allows. Where to look: The widget mentioned will usually need either a smaller font size, max lines with overflow ellipsis (as covered in section 5.2.2), or to be wrapped in an Expanded or Flexible widget.

"The method '...' was called on null"
Meaning: Your code tried to use a function or property on something that does not exist — similar to the TypeError above but specifically about calling an action on missing data. Where to look: Check whether the object being used has been properly initialised before this line runs.

"A RenderFlex overflowed" alongside yellow and black striped patterns on screen.
Meaning: Same as the overflow error above — this is the visual indicator Flutter shows directly on the screen where content does not fit. The striped pattern marks exactly where the overflow is happening.

"Target of URI doesn't exist" or "Error: Couldn't resolve the package"
Meaning: An import statement at the top of your file is pointing to a file or package that cannot be found — usually because of a typo in the file path, a missing package in pubspec.yaml, or a package that has not been installed. Where to look: Check the exact spelling of the import path, and confirm the package is listed correctly in pubspec.yaml.

"setState() called after dispose()"
Meaning: Your code is trying to update a screen that the user has already navigated away from. This usually happens with data loading or timers that take longer than expected. Where to look: This is a slightly more advanced error — best handled by describing it precisely to Gemini along with the relevant code section.

Now that you understand how to read an error — here is the complete, repeatable process for resolving any error you encounter, combining your own reading skills with AI assistance for maximum speed and accuracy.

The Five-Step Error Resolution Process:

Step 1 — Read the error yourself first.
Before going to AI — apply what you learned in section 5.5.2. Identify the error type, the specific message, and the file and line number. Even a partial understanding helps you ask AI a better, more specific question.

Step 2 — Open the file and line mentioned.
Navigate to the exact file and line number given in the error. Look at the code around it — the line itself and a few lines before and after. This gives you context for what you are about to ask AI about.

Step 3 — Copy the full error message and the relevant code.
Select and copy the complete error message — not just one line, the whole thing. Then also copy the section of code around the line number mentioned — about 10 to 15 lines for context.

Step 4 — Ask AI with full context.
Open Gemini or ChatGPT. Use this exact prompt structure: "I am building a Flutter app and got this error: [paste full error message]. Here is the relevant code from the file and line mentioned in the error: [paste your code section]. Can you explain in plain English what caused this error and give me the exact fix?"

Step 5 — Apply the fix, test, and confirm.
Make the exact change AI recommends. Save the file. Run or refresh your app preview. Confirm the error is gone and the screen behaves correctly. If a new error appears — repeat this process for the new error. Errors sometimes occur in sequence — fixing one reveals the next. This is normal and expected.

An important habit to build — after AI gives you a fix, do not just paste it in blindly. Read the explanation first. Understand why the error happened before applying the solution. This single habit is what transforms error fixing from a repetitive chore into genuine learning. Every error you understand is one you will recognise instantly the next time it happens — and eventually prevent from happening at all.

The best way to build confidence resolving errors is to deliberately create one in a safe, controlled way — and then fix it using the process from this section. This removes the fear factor because you know exactly what caused it and you control the situation completely.

Exercise Steps — Complete All to Finish Module 5:

Step 1 — Commit your current project to GitHub first with the message: "Checkpoint before error resolution practice"

Step 2 — Open home_screen.dart. Find a Text widget. Deliberately delete one of the closing parentheses ) at the end of that widget's code block.

Step 3 — Save the file and try to run or preview the app. You should see a build-time error — Flutter will refuse to compile because the code is now structurally incorrect.

Step 4 — Read the error message that appears. Apply section 5.5.2 — identify the error type, the message, and the file and line number it points to.

Step 5 — Follow the Five-Step Error Resolution Process from section 5.5.4. Even though you already know the cause — practise the complete process: copy the error, copy the code, ask Gemini, apply the fix.

Step 6 — Confirm the app runs correctly again after restoring the missing parenthesis.

Step 7 — Write in your notes: "Today I deliberately created and fixed my first Flutter error. The error type was: [type]. The cause was: [cause]. The fix was: [fix]." This written reflection cements the experience into genuine, lasting understanding.

Step 8 — Commit your restored, working project to GitHub with the message: "Completed Module 5 — error resolution practice successful"