Mobile App Development & AI

Your app works. You have personally tested every navigation path, every screen, every data connection — and everything functions correctly on your device, with your test accounts, under conditions you control. But "it works for me" and "it works for everyone" are two very different standards — and the gap between them is exactly what Module 7 closes.

Real users will use your app differently than you do. They will have slower internet connections. Smaller or larger phone screens. They will tap things in an order you never anticipated. They will type unexpected characters into your input fields. They will lose connection mid-action. None of these are unusual or rare events — they are the normal, everyday reality of how real software gets used in the real world. A professional developer does not hope their app survives these situations — they deliberately test for them, in advance.

This module teaches you exactly how to do that — systematically, efficiently, and with AI as a powerful partner throughout the entire process. Testing is not a sign that something is wrong with your work. Testing is what separates a hobby project from a professional product.

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

✅ Understand the different types of testing — manual, automated and AI-assisted — and know when to use each approach for maximum effectiveness with minimum wasted time.

✅ Test your app systematically across different scenarios — different devices, different network conditions, different user behaviours — using a structured testing framework rather than random, hopeful clicking.

✅ Use AI to find bugs faster — describing your app's behaviour to AI and getting suggestions for edge cases and scenarios you might not have considered testing yourself.

✅ Test your app on real devices and emulators — moving beyond the FlutterFlow preview to see how your app genuinely performs on actual phone hardware.

✅ Improve your app's performance — identifying and fixing slow loading, unnecessary delays, and anything that makes your app feel less smooth than it should.

✅ Build a habit of continuous testing — not as a one-time event before publishing, but as an ongoing practice that protects every future feature you add to this app and any app you build afterward.

Section 7.1 — Understanding Why Testing is Critical Before Publishing. The mindset and the stakes — why skipping proper testing is the single most common reason published apps fail or get uninstalled within their first use.

Section 7.2 — Types of Testing — Manual, Automated and AI-Assisted. A complete breakdown of every testing approach available to you, with clear guidance on which to use when, and how they work together.

Section 7.3 — Using AI to Find and Fix Bugs Faster. Practical techniques for using Gemini and ChatGPT not just to fix errors you already found — as covered in Module 5 — but to proactively discover bugs before users ever encounter them.

Section 7.4 — Testing Your App on Real Devices and Emulators. Step by step instructions for testing your app beyond the FlutterFlow preview — on your actual phone and on emulated devices representing different screen sizes and operating system versions.

Section 7.5 — Improving App Performance with AI Suggestions. Identifying what makes an app feel slow or clunky, and using AI-guided optimisation to make your app feel fast, smooth and genuinely professional.

Imagine you publish your app to the Google Play Store without thorough testing. A new user downloads it, opens it for the first time, and the app crashes on a screen size you never personally tested. That user does not file a bug report or give you a second chance. They simply uninstall it — and that first impression is permanently gone.

Now multiply that scenario across every potential user, every device type, every network condition you never tested. Each untested scenario represents a real risk to your app's reputation, your client's trust, and ultimately your own growth as a developer. The few hours spent on proper testing in Module 7 protect everything you have built in every module before this one.

This is also true financially if you are building apps professionally. A client who experiences a bug in front of their own customers loses confidence in your work — regardless of how well-designed or feature-rich the app is. Thorough testing is not extra effort — it is the difference between being seen as a hobbyist and being seen as a professional.

Before we test a single screen — it is worth slowing down and understanding deeply why this module exists, and why it deserves your full attention rather than being rushed through. Testing is not a checkbox to tick before publishing. It is a mindset — a way of thinking about your app that fundamentally separates amateur work from professional work.

In this section we explore exactly what is at stake, who is affected when testing is skipped, and how to build the right mental approach before moving into the practical testing techniques covered in the rest of Module 7.

It is easy to think of testing as something that protects you, the developer, from embarrassment. But the reality is much bigger than that — poor testing affects several different people in several different ways.

The End User — A real person, perhaps a student trying to check tomorrow's homework, or a parent trying to see a school announcement, encounters a crash or a confusing error. Their immediate experience is frustration — and often they do not have the patience or technical understanding to figure out what went wrong. They simply stop using the app.

The Client or Organisation — If you built this app for IT International Academy, a school, a church, or a business — every bug a user encounters reflects directly on that organisation's reputation, not just yours. A school that proudly announces a new app to parents, only for it to crash on half the phones in the room, suffers real embarrassment that is difficult to recover from quickly.

You, the Developer — Beyond the immediate embarrassment, poor testing damages something more lasting — your reputation and your confidence. Every poorly tested app that fails publicly makes the next client harder to win, and makes you doubt your own abilities even when the underlying skill was genuinely strong. Thorough testing protects all three — the user, the client, and you.

Throughout Modules 4, 5 and 6, you tested your app under ideal conditions — your specific phone, your stable internet, your own thoughtful, predictable usage patterns. Real users introduce conditions you have likely never personally experienced while testing.

Different Screen Sizes — Your app may look perfect on your specific phone but break or look awkward on a much smaller or much larger screen. Text might overflow. Buttons might become too small to tap comfortably. Layouts designed around one screen size do not automatically work everywhere.

Slow or Unstable Internet — You likely tested on reliable WiFi. Real users in many areas have inconsistent mobile data. What happens to your Home Screen if the Firestore data takes ten seconds to load instead of one? Does the user see a blank screen, a loading indicator, or worse, the app appearing to be frozen?

Unexpected User Behaviour — You tested by tapping things in the order you expected them to be tapped. Real users tap faster than expected, tap the same button multiple times rapidly, navigate backward and forward in unusual sequences, or type unexpected characters and emoji into text fields. Does your app handle a user double-tapping the Sign In button — potentially triggering two simultaneous login attempts?

Empty or Extreme Data — What happens the very first time a brand new user opens the app, before they have any data of their own? What happens if a single announcement has an extremely long title that was never anticipated during design? Your design specification assumed reasonable content — real content is not always reasonable. Testing for these conditions deliberately is exactly what Module 7 teaches you to do.

The single biggest shift required for effective testing is a change in mindset — from trying to confirm your app works, to actively trying to prove that it does not. This sounds counterintuitive but it is the foundation of all professional quality assurance.

When you test hoping to confirm success, you unconsciously test gently — you tap things carefully, you use realistic data, you follow the path you expect users to follow. This kind of testing rarely finds real problems, because you are essentially testing your own assumptions rather than testing reality.

When you test trying to break your app — tapping aggressively, entering unusual data, deliberately trying unexpected sequences of actions — you find the genuine weaknesses before a real user ever encounters them. This is not pessimism. It is professional rigour. A bridge engineer does not test a bridge by driving across it once gently — they calculate and test against forces far beyond normal use, because the cost of being wrong is too high. Your app deserves the same standard of care.

Hold this mindset throughout every section of Module 7: you are not testing to prove your app is good — you are testing to find every way it could fail, so you can fix each one before any real user ever encounters it.

Before learning structured testing techniques in the sections ahead, do this short exercise right now — applying the mindset from section 7.1.3 immediately, without any formal framework yet. This builds the instinct before the structure.

Exercise Steps — Complete Before Moving to Section 7.2:

Step 1 — Open your app preview. Set a timer for ten minutes.

Step 2 — For ten minutes, deliberately try to break your app. Tap buttons rapidly multiple times. Type unusual characters into the email field — symbols, very long text, emoji. Try logging in with an empty password field. Try the back button at unexpected moments. Try rotating your phone if your app does not specifically handle that. Try anything that a careful, "polite" tester would never normally attempt.

Step 3 — Write down every single thing that breaks, looks wrong, or behaves unexpectedly — no matter how small. Do not fix anything yet. Just observe and record.

Step 4 — Count how many issues you found in just ten minutes of deliberately "unkind" testing. Most students are surprised by how many issues appear once they stop testing gently.

Step 5 — Save this list. We will work through resolving these systematically using the techniques covered in the rest of Module 7.

Do not feel discouraged by what you found. Every issue on that list is a future user who will never experience a broken app — because you found it first. That is exactly the value of this exercise, and exactly the mindset Module 7 is built around.

Now that you have the right mindset — actively trying to find problems rather than confirm success — let us build a structured understanding of the different testing approaches available to you, and exactly when each one is most useful. Testing is not one single activity. It is a toolkit of different techniques, each suited to different situations.

Understanding all three types — and how they complement each other — means you never waste time using the wrong tool for the job, and you never leave gaps that a single testing approach alone would miss.

Manual testing is exactly what it sounds like — a real person, using the app directly, tapping through screens and observing the results with their own eyes. This is the type of testing you have already been doing throughout this course, and the exercise you completed in section 7.1.4.

Strengths of manual testing — It catches visual problems that automated tools cannot detect, like a colour that looks slightly wrong, text that feels cramped, or an interaction that technically works but feels awkward to use. It also allows genuine creativity — a human tester can think of unusual scenarios that a script never would.

Limitations of manual testing — It is slow. It is inconsistent — a human tester might test thoroughly one day and skip steps when rushed another day. And it does not scale — testing every single screen manually after every small change becomes exhausting and impractical as your app grows.

Manual testing is best used for — visual review, usability assessment, and creative, exploratory testing like the break-it exercise from section 7.1.4. It is the foundation every other type of testing builds upon.

Automated testing means writing code whose entire job is to test other code — running a set of checks automatically, without a human needing to manually tap through anything. You may recall the test/ folder from your project structure in section 5.1.2 — this is exactly where automated tests live.

How it works in practice — An automated test describes an expected outcome — for example, "when the app loads the Home Screen, exactly one announcement card should appear for every document in the announcements collection." The test then runs this check automatically and reports whether it passed or failed — instantly, every single time, without a human needing to manually count cards on screen.

Strengths of automated testing — It is fast, consistent, and repeatable. Once written, an automated test can run hundreds of times without becoming tired or skipping steps. It is especially valuable for catching when a new change accidentally breaks something that used to work — a problem called a regression.

Limitations of automated testing — It only tests what it was specifically written to check. It cannot judge whether something looks visually wrong, or whether an interaction feels awkward to use. Writing comprehensive automated tests also takes real time and skill.

For this course — we focus primarily on manual and AI-assisted testing, since automated test writing is a more advanced skill. However, it is important you understand this exists, since many professional teams rely heavily on it, and you may encounter it in future client projects or jobs.

AI-assisted testing is where your advantage as a modern, AI-powered developer truly shines — it combines the creativity of manual testing with the speed and structure of automated approaches, using AI as a thinking partner throughout the entire process.

Generating test scenarios — Rather than relying only on your own imagination to think of edge cases, you describe your screen or feature to AI and ask it to suggest scenarios you might not have considered. AI has effectively "seen" patterns from countless applications and can suggest realistic edge cases efficiently.

Reviewing code for potential issues — You can paste a section of your code to Gemini or ChatGPT and ask it to review for potential problems — missing error handling, unhandled empty states, or logic that might behave unexpectedly under certain conditions — before you even begin manually testing that section.

Explaining and prioritising found issues — When your manual testing uncovers a long list of issues, AI can help you understand which ones are most critical to fix first, based on their potential impact on real users.

This module teaches you to weave AI-assisted testing throughout your manual testing process — not as a replacement for using your own judgement, but as a powerful multiplier of it.

Exercise Steps — Complete Before Moving to Section 7.3:

Step 1 — Open Gemini. Describe your Login Screen in detail — every field, every button, every validation behaviour you have built so far.

Step 2 — Ask: "Based on this screen description, suggest fifteen specific test scenarios I should try — including edge cases and unusual user behaviour I might not have thought of myself."

Step 3 — Read through the suggestions. Compare them to the issues list you created in section 7.1.4. How many scenarios did AI suggest that you had not already tried yourself?

Step 4 — Try at least five of the new AI-suggested scenarios on your real app. Add any new issues found to your running "Issues Found" note.

Step 5 — Repeat this same process for your Home Screen and your Detail Screen — using AI to generate scenarios specific to each screen's functionality.

Notice how this combines all three testing types you just learned — you are manually executing the tests, using AI assistance to generate scenarios you might have missed, and building the foundation for structured, repeatable testing going forward. This is exactly the modern, efficient testing workflow professional AI-powered developers use today.

Now that you have the right mindset — actively trying to find problems rather than confirm success — let us build a structured understanding of the different testing approaches available to you, and exactly when each one is most useful. Testing is not one single activity. It is a toolkit of different techniques, each suited to different situations.

Understanding all three types — and how they complement each other — means you never waste time using the wrong tool for the job, and you never leave gaps that a single testing approach alone would miss.

Manual testing is exactly what it sounds like — a real person, using the app directly, tapping through screens and observing the results with their own eyes. This is the type of testing you have already been doing throughout this course, and the exercise you completed in section 7.1.4.

Strengths of manual testing — It catches visual problems that automated tools cannot detect, like a colour that looks slightly wrong, text that feels cramped, or an interaction that technically works but feels awkward to use. It also allows genuine creativity — a human tester can think of unusual scenarios that a script never would.

Limitations of manual testing — It is slow. It is inconsistent — a human tester might test thoroughly one day and skip steps when rushed another day. And it does not scale — testing every single screen manually after every small change becomes exhausting and impractical as your app grows.

Manual testing is best used for — visual review, usability assessment, and creative, exploratory testing like the break-it exercise from section 7.1.4. It is the foundation every other type of testing builds upon.

Automated testing means writing code whose entire job is to test other code — running a set of checks automatically, without a human needing to manually tap through anything. You may recall the test/ folder from your project structure in section 5.1.2 — this is exactly where automated tests live.

How it works in practice — An automated test describes an expected outcome — for example, "when the app loads the Home Screen, exactly one announcement card should appear for every document in the announcements collection." The test then runs this check automatically and reports whether it passed or failed — instantly, every single time, without a human needing to manually count cards on screen.

Strengths of automated testing — It is fast, consistent, and repeatable. Once written, an automated test can run hundreds of times without becoming tired or skipping steps. It is especially valuable for catching when a new change accidentally breaks something that used to work — a problem called a regression.

Limitations of automated testing — It only tests what it was specifically written to check. It cannot judge whether something looks visually wrong, or whether an interaction feels awkward to use. Writing comprehensive automated tests also takes real time and skill.

For this course — we focus primarily on manual and AI-assisted testing, since automated test writing is a more advanced skill. However, it is important you understand this exists, since many professional teams rely heavily on it, and you may encounter it in future client projects or jobs.

AI-assisted testing is where your advantage as a modern, AI-powered developer truly shines — it combines the creativity of manual testing with the speed and structure of automated approaches, using AI as a thinking partner throughout the entire process.

Generating test scenarios — Rather than relying only on your own imagination to think of edge cases, you describe your screen or feature to AI and ask it to suggest scenarios you might not have considered. AI has effectively "seen" patterns from countless applications and can suggest realistic edge cases efficiently.

Reviewing code for potential issues — You can paste a section of your code to Gemini or ChatGPT and ask it to review for potential problems — missing error handling, unhandled empty states, or logic that might behave unexpectedly under certain conditions — before you even begin manually testing that section.

Explaining and prioritising found issues — When your manual testing uncovers a long list of issues, AI can help you understand which ones are most critical to fix first, based on their potential impact on real users.

This module teaches you to weave AI-assisted testing throughout your manual testing process — not as a replacement for using your own judgement, but as a powerful multiplier of it.

Exercise Steps — Complete Before Moving to Section 7.3:

Step 1 — Open Gemini. Describe your Login Screen in detail — every field, every button, every validation behaviour you have built so far.

Step 2 — Ask: "Based on this screen description, suggest fifteen specific test scenarios I should try — including edge cases and unusual user behaviour I might not have thought of myself."

Step 3 — Read through the suggestions. Compare them to the issues list you created in section 7.1.4. How many scenarios did AI suggest that you had not already tried yourself?

Step 4 — Try at least five of the new AI-suggested scenarios on your real app. Add any new issues found to your running "Issues Found" note.

Step 5 — Repeat this same process for your Home Screen and your Detail Screen — using AI to generate scenarios specific to each screen's functionality.

Notice how this combines all three testing types you just learned — you are manually executing the tests, using AI assistance to generate scenarios you might have missed, and building the foundation for structured, repeatable testing going forward. This is exactly the modern, efficient testing workflow professional AI-powered developers use today.

In Module 5 you learned how to use AI to fix errors you had already found — the Five-Step Error Resolution Process from section 5.5.4. In this section we go further — using AI proactively to discover bugs that have not yet announced themselves with a visible error message. This is a more advanced and significantly more valuable skill, because the bugs that do not announce themselves are precisely the ones most likely to slip through to real users undetected.

Combined with the AI-assisted scenario generation from section 7.2.5, this section completes your toolkit for genuinely thorough, professional-grade bug discovery — using AI not just as a fixer, but as a proactive investigator working alongside you.

Every screen you have built so far technically "works" when tested under normal conditions. But code can contain issues that only reveal themselves under specific, less common conditions — and AI is remarkably good at spotting these patterns when you ask it to look specifically for them.

Step by Step — Proactive Code Review:

Step 1 — Open one of your screen files — for example login_screen.dart.

Step 2 — Copy the entire file, or the specific section handling your authentication logic from section 6.2.3.

Step 3 — Paste it into Gemini with this exact prompt: "I am a beginner Flutter developer. Please review this code specifically for potential bugs, edge cases, or unhandled situations — not for code style. Consider what happens with empty fields, very long input, special characters, rapid repeated taps, and slow network conditions. List each potential issue you find and explain why it could be a problem in plain English."

Step 4 — Read through the issues AI identifies. For each one — go test it directly in your app preview to confirm whether it is a genuine problem in your specific implementation.

Step 5 — Add any confirmed issues to your running "Issues Found" note from section 7.1.4, alongside AI's suggested explanation of the cause.

An important note — not every issue AI identifies will actually be a real problem in your specific app. Sometimes a theoretical edge case is already handled correctly by FlutterFlow's default behaviour, or simply is not realistic for your specific app's users. Use your own judgement, built throughout Module 5, to evaluate each suggestion — rather than blindly treating every AI suggestion as confirmed fact. AI generates strong leads. You confirm them.

One of the most common issues AI code review identifies — and one worth understanding specifically — is what happens when a user taps a button multiple times rapidly, particularly buttons that trigger network actions like your Sign In or Create Account buttons.

Why this matters — If a user taps Sign In, and the authentication request takes two seconds to complete, an impatient user might tap it three or four more times in those two seconds — not realising it is already processing. Without protection, this could trigger multiple simultaneous login attempts, potentially causing confusing errors or duplicate account creation attempts.

Step by Step — Test and Fix Rapid Tap Issues:

Step 1 — On your Login Screen, rapidly tap the Sign In button five or six times in quick succession. Observe what happens.

Step 2 — If you notice anything unusual — multiple error messages, a delay, or unexpected behaviour — this confirms the issue exists in your implementation.

Step 3 — In FlutterFlow, select your Sign In button. Look for a property called Disable While Loading or similar in the button's settings. Many button widgets in FlutterFlow have this built in — enable it. This automatically prevents the button from being tapped again while the first request is still processing.

Step 4 — If no such setting exists in your version, ask Gemini: "In FlutterFlow, how do I prevent a button from being tapped multiple times while its action is still processing?"

Step 5 — Apply the fix. Repeat the rapid tap test from Step 1 and confirm the issue no longer occurs.

Another extremely common gap AI code review identifies is missing or incomplete input validation — your app accepting and submitting data that should never have been allowed through in the first place.

Test this on your Register Screen from section 6.2.4: try submitting the registration form with the email field completely empty. Try entering text with no "@" symbol into the email field. Try a password that is only one character long. Try mismatched Password and Confirm Password fields.

Step by Step — Add Proper Validation:

Step 1 — In FlutterFlow, select your email TextField. Look for a Validator property in the right panel. Many FlutterFlow versions offer a built-in Email validation option — enable it.

Step 2 — Select your Password TextField. Look for a minimum length validator option, or ask Gemini: "In FlutterFlow, how do I add a validator that requires a password field to be at least 6 characters long?"

Step 3 — For the Confirm Password field matching the Password field — ask Gemini: "In FlutterFlow, how do I validate that two text fields contain exactly the same value before allowing form submission?"

Step 4 — Apply the validators. Each one should display a clear error message directly below the relevant field when validation fails — for example "Please enter a valid email address" or "Passwords do not match."

Step 5 — Repeat your test scenarios from the start of this section. Confirm that the form now correctly blocks submission and shows clear, helpful error messages for each invalid case.

Exercise Steps — Complete Before Moving to Section 7.4:

Step 1 — Repeat the Step by Step Code Review process from section 7.3.1 for each of your four screens — login_screen.dart, home_screen.dart, detail_screen.dart, and profile_screen.dart.

Step 2 — For each screen, confirm and fix any genuine issues found, applying input validation and rapid-tap protection where relevant — following the patterns from sections 7.3.2 and 7.3.3.

Step 3 — Update your "Issues Found" note with every confirmed and fixed issue.

Step 4 — Save and preview your app. Repeat your original break-it testing from section 7.1.4 one more time, in full. Confirm the issues you originally found no longer occur.

Step 5 — Commit your project to GitHub with the message: "Applied AI-assisted code review fixes — validation and rapid-tap protection added across all screens"

Throughout this course you have tested your app using FlutterFlow's built-in preview — an excellent tool for fast iteration, but not a perfect substitute for how your app actually behaves on real, physical phone hardware. The preview simulates a phone screen inside your browser — but real devices introduce genuine differences that only direct device testing can reveal.

In this section we move beyond the preview — installing and testing your app on your own real phone, and exploring how to test across different screen sizes and operating system versions using emulators, even if you only own one type of device yourself.

The FlutterFlow preview is excellent for design and quick iteration — but several important things behave differently or are entirely absent in the preview compared to a real device.

Real Performance — The preview runs inside your browser, using your browser's processing power — not the actual processing power of a real, possibly older or lower-specification phone that real users may have. An app that feels instantly smooth in preview can feel noticeably slower on a budget Android device.

Real Network Conditions — Your laptop or phone's browser preview typically uses your strongest available connection. Installing the actual app lets you genuinely test on mobile data, in areas with weaker signal, or using your phone's specific data-saving settings.

Real Touch Interaction — Clicking with a mouse or tapping a browser preview is fundamentally different from a real finger on a real touchscreen. Button sizes that feel fine in preview may feel too small for a real thumb. Real device testing reveals this immediately.

Real Notifications, Permissions and Phone Behaviour — Features like push notifications, camera access, or how your app behaves when a phone call interrupts it, simply cannot be properly tested inside a browser preview at all. Real device testing is not optional polish — it is essential verification.

📱 Phone Users — Installing via FlutterFlow Test Mode:

Step 1 — Open your project in FlutterFlow on your phone browser.

Step 2 — Look for a Run or Test on Device option in the top toolbar. FlutterFlow typically offers a way to generate a direct testable build or a QR code link for installing a real test version of your app on a connected phone.

Step 3 — If a QR code option is offered, scan it with your phone's camera. Follow the prompts to install the test build directly. You may need to allow installation from unknown sources in your phone settings — the same setting covered in section 2.5.5 for Sketchware Pro installations.

Step 4 — Once installed, open the app directly from your home screen — exactly as a real user would, not from within FlutterFlow's preview environment.

💻 Laptop Users — Installing via Build Output:

Step 1 — In FlutterFlow on your laptop, find the Download Code or Build option, typically under the project menu.

Step 2 — Select an Android APK build — a file format that can be installed directly on Android phones. Wait for FlutterFlow to generate this build — it usually takes a few minutes.

Step 3 — Once the build completes, transfer the APK file to your phone — via USB cable, email to yourself, or any file transfer method available to you.

Step 4 — On your phone, locate the transferred APK file and tap it to install — enabling installation from unknown sources if prompted, the same as the phone instructions above.

Once your app is installed and running directly on your phone, repeat your full testing journey from Module 6, section 6.5.7 — but this time add these device-specific checks:

Real Device Testing Checklist:

✅ Every button and tappable element is large enough to comfortably tap with a real thumb.

✅ Text is genuinely readable at arm's length — not just on a zoomed-in preview.

✅ Turn off WiFi and test using mobile data only — confirm loading states appear correctly while data loads.

✅ Briefly switch your phone to airplane mode while using the app — confirm it fails gracefully with a clear message, rather than crashing or freezing silently.

✅ Test the app in both portrait orientation and, if you have not specifically restricted orientation, landscape orientation.

✅ Receive a phone call or notification while the app is open — confirm the app correctly resumes afterward without losing your place.

✅ Close the app completely and reopen it — confirm it returns you to the correct screen based on whether you were logged in.

If anything on this checklist reveals an issue — use the Five-Step Error Resolution Process from section 5.5.4, combined with the AI code review technique from section 7.3.1, to investigate and resolve it.

You may only own one specific phone — but real users will have many different screen sizes, from small budget phones to large modern flagships. FlutterFlow's preview lets you simulate multiple device sizes without needing to physically own each one.

Step by Step — Test Multiple Screen Sizes:

Step 1 — Open your project preview in FlutterFlow.

Step 2 — Look for a device selector — usually a dropdown showing different phone models or screen dimensions, near the preview window.

Step 3 — Select a smaller screen size option — for example a compact Android device. Go through every screen of your app. Check specifically for text overflow, cards that look cramped, or buttons that no longer fit comfortably — issues your design specification from Module 3 may not have explicitly anticipated.

Step 4 — Select a larger screen size option. Check that your layouts do not look awkwardly empty or stretched — particularly your card widths and any centred content.

Step 5 — For any issues found, ask Gemini: "How do I make this FlutterFlow layout responsive so it adapts correctly across different screen sizes, instead of using fixed pixel widths?" — paste the relevant widget settings for specific guidance.

Exercise Steps — Complete Before Moving to Section 7.5:

Step 1 — Install your app on your real phone following section 7.4.2.

Step 2 — Work through every item on the Real Device Testing Checklist from section 7.4.3.

Step 3 — Test at least two different simulated screen sizes in the FlutterFlow preview following section 7.4.4.

Step 4 — Record every issue found in your "Issues Found" note, fixing each one using the techniques learned across Module 5 and the earlier sections of Module 7.

Step 5 — Take a screenshot of your app running on your real phone — outside of any browser or preview window — and add it to your portfolio. This is a significant milestone — your app, genuinely installed and running independently on real hardware.

Step 6 — Commit your project to GitHub with the message: "Completed real device and multi-screen-size testing"

Your app now works correctly, handles errors gracefully, and has been tested across real devices and different screen sizes. There is one final dimension of quality to address before Module 7 is complete — how your app feels to actually use. An app can be completely bug-free and still feel sluggish, clunky, or unpolished if performance has not been deliberately considered.

This final section of Module 7 focuses on perceived performance — the difference between an app that technically works and one that genuinely feels fast, smooth and professional in the user's hands. We use AI throughout to identify specific opportunities for improvement, in the same collaborative way you have used it throughout this entire module.

When users describe an app as "slow," they are rarely talking about precise technical measurements — they are describing a feeling. Understanding the specific causes behind that feeling lets you address them deliberately rather than guessing.

Loading Without Feedback — The single biggest cause of an app feeling slow is not actual slowness — it is silence. When data is loading from Firestore and the screen simply shows nothing happening, users assume the app is frozen or broken, even if it would have loaded successfully one second later. A loading indicator transforms the exact same wait time from frustrating to acceptable.

Jerky or Inconsistent Animations — Screen transitions, scrolling, and any movement on screen should feel smooth and consistent. Stuttering or inconsistent motion — even briefly — registers immediately to users as low quality, even if they cannot articulate exactly why.

Unnecessary Delays — Sometimes an app waits longer than necessary before showing content — for example, waiting for every single piece of data to load before displaying anything at all, rather than showing what is already available immediately while the rest continues loading.

The good news — most perceived performance issues are fixed not through complex technical optimisation, but through thoughtful loading states and sensible sequencing. This is exactly what the rest of this section addresses.

Recall from section 6.4 that your Home Screen waits for a Firestore query to return data before displaying your announcement cards. Let us confirm — and improve if needed — what happens to the user during that brief wait.

Step by Step — Add Loading States:

Step 1 — Open your HomeScreen page in FlutterFlow. Select your dynamic ListView connected to Firestore from section 6.4.2.

Step 2 — Look for a property related to the query's loading state — often called Loading Widget or Show While Loading. If this option exists, FlutterFlow handles much of this automatically.

Step 3 — Design a simple loading indicator — a centred circular progress spinner in your accent colour, with optional text below it reading "Loading announcements..." in your body font.

Step 4 — If your FlutterFlow version does not offer this directly, ask Gemini: "In FlutterFlow, how do I show a loading spinner while a Firestore query is still retrieving data, and then automatically replace it with the loaded content?"

Step 5 — Test this by temporarily switching your phone to a slower mobile data connection if possible, or by simulating slower conditions using your browser's developer tools network throttling option if testing on laptop. Confirm the loading indicator appears clearly during any delay, rather than a blank or frozen-looking screen.

Step 6 — Apply this same loading indicator pattern to your Detail Screen — confirm it shows a brief loading state while the specific document content from section 6.5.4 is being retrieved.

Recall from section 5.3.3 that MaterialPageRoute provides Flutter's standard slide transition animation between screens automatically. In most cases this default behaviour is already smooth — but it is worth deliberately confirming this across every navigation path in your app, since a single jarring transition stands out noticeably against an otherwise polished experience.

Step by Step — Test Every Transition:

Step 1 — On your real device from section 7.4.2, navigate slowly and deliberately through every single navigation path in your app, watching the transition animation carefully each time — Login to Home, Home to Detail, Detail back to Home, Home to Profile, Profile to Login on logout.

Step 2 — Note any transition that feels noticeably slower, faster, or visually different from the others.

Step 3 — For any inconsistent transition, check that screen's navigation action in FlutterFlow — confirm it uses the same Navigate To or Navigate Replace pattern consistently with your other screens, rather than a different transition type that may have been accidentally selected.

Sometimes an app waits longer than truly necessary before showing anything useful to the user. Let us use AI to specifically review your app's structure for this pattern.

Step by Step — Identify Unnecessary Delays:

Step 1 — Open Gemini and describe your app's loading sequence in detail — what loads first, second, and so on, from the moment the app opens to the moment the Home Screen is fully interactive.

Step 2 — Ask: "Based on this loading sequence, are there any steps that could happen in parallel instead of one after another, or any content that could be shown to the user before everything has finished loading?"

Step 3 — Review the suggestions. A common example — your app's theme and splash screen from section 3.5 do not need to wait for Firestore data to load before displaying — confirm this is already the case in your app, since splash screens should always appear instantly regardless of network conditions.

Step 4 — Apply any genuinely applicable suggestions, testing carefully after each change to confirm nothing else breaks as a result.

Exercise Steps — Final Polish Before Completing Module 7:

Step 1 — Confirm loading indicators are correctly in place on your Home Screen and Detail Screen, following section 7.5.2.

Step 2 — Test and confirm every navigation transition in your app feels consistent, following section 7.5.3.

Step 3 — Complete the AI sequencing review from section 7.5.4 and apply any genuine improvements found.

Step 4 — Go through your complete "Issues Found" note one final time. Confirm every single item across all of Module 7 has now either been fixed, or — if intentionally left for a future module — clearly marked as such with a reason why.

Step 5 — Commit your fully tested, polished project to GitHub with the message: "Completed Module 7 — full testing pass, bug fixes and performance polish applied"