Mobile App Development & AI

Up to this point your app looks complete — four professionally designed screens, smooth navigation, your confirmed colours and fonts applied throughout. But there is one thing missing — your app currently runs entirely on sample data. The announcements on your Home Screen are the same three hardcoded cards every time. There is no real login. There is no real user account. Nothing is actually saved or retrieved from anywhere.

Module 6 changes everything. In this module we connect your app to Firebase — the backend you set up in Module 2 — and transform your app from a beautiful prototype into a genuinely functional product. Real user accounts. Real data storage. Real content that updates dynamically. By the end of this module, when a teacher posts a new announcement, every student using your app will see it appear automatically — without you writing a single line of sample data ever again.

This is the module where your app stops being a design exercise and becomes a real software product. The screens you built in Module 4 and the understanding you gained in Module 5 are about to come together — giving you the confidence to direct AI precisely as we wire up the systems that make an app genuinely useful.

By the end of Module 6 your app will have all of the following fully functional:

✅ Real User Registration and Login — using Firebase Authentication. Users create real accounts with their email and password, and log in securely. No more placeholder login that goes anywhere regardless of what is typed.

✅ A Real Database Connection — using Cloud Firestore. Your Home Screen list will display real data stored in the cloud — not hardcoded sample cards.

✅ Live Data Updates — when new content is added to the database, it appears in your app automatically, without the user needing to reinstall or manually refresh in unusual ways.

✅ Dynamic Detail Screens — tapping a specific item on the Home Screen will show that item's actual content on the Detail Screen — not the same static sample text every time.

✅ Real User Profiles — the Profile Screen will display the actual logged-in user's real information, retrieved from the database, instead of a placeholder name.

✅ Working Logout — a logout button that genuinely signs the user out of Firebase, not just navigates to a screen.

✅ Everything committed to GitHub — your fully functional app, safely backed up at every milestone.

Section 6.1 — Understanding APIs and Databases. Before connecting anything we build a clear conceptual foundation — what an API is, what a database is, and how your app, Firebase and the internet work together to deliver real functionality.

Section 6.2 — Connecting Firebase Authentication. Step by step — wiring up real user registration and login, replacing the placeholder navigation from Module 4 with genuine, secure authentication.

Section 6.3 — Setting Up Cloud Firestore and Your Data Structure. Designing how your data is organised in the database, and adding your first real data entries that your app will retrieve and display.

Section 6.4 — Connecting Your Home Screen to Live Data. Replacing your sample announcement cards with a real, live-updating list pulled directly from Firestore.

Section 6.5 — Connecting Detail and Profile Screens to Real Data. Making the Detail Screen show the actual tapped item's content, and the Profile Screen show the actual logged-in user's real information — completing the full data connection across your entire app.

Every module before this one prepared you for this exact moment. Module 1 gave you the mindset. Module 2 gave you the tools. Module 3 gave you the design. Module 4 gave you the screens. Module 5 gave you the understanding. Module 6 gives your app a heartbeat.

This is the difference between a portfolio piece and a real product. A beautifully designed app with no real data is impressive to look at but cannot actually be used by real people for real purposes. An app with real authentication and real data — even with a simple design — can be deployed, used, and genuinely valuable to a school, a church, a business, or any organisation that needs it. After Module 6, what you are building stops being a course exercise. It becomes something you could hand to a real client tomorrow.

There will be moments in this module where things feel more technical than previous modules. That is expected — connecting real systems involves more moving parts than designing a static screen. Trust the process. Follow each step precisely. Use Gemini whenever something is unclear. Every student who has come before you has felt exactly what you may feel in this module — and every one of them came out the other side with a real, functioning app. You will too.

Before we connect a single piece of real functionality to your app — you need a clear, practical understanding of two concepts that sit at the heart of every modern application: APIs and databases. These are not abstract computer science terms reserved for advanced developers. They are simple, logical concepts that — once understood properly — make everything in this module click into place.

Every app you have ever used depends on both of these working together. When you send a WhatsApp message, check your bank balance, or scroll through a social media feed — APIs and databases are working behind the scenes, invisible to you but essential to everything happening on your screen.

A database is simply an organised place to store information so it can be found, used, and updated later. Think of a database like a very large, very well-organised filing cabinet. Every drawer in the cabinet holds a specific type of document. Every document inside a drawer follows the same format — so finding what you need is fast and predictable.

Without a database, your app has no memory. Every time a user closes the app, everything they did disappears. Every time they open it again, it starts fresh — exactly like your sample data has been doing throughout Module 4 and Module 5. With a database, information persists — it stays saved, exactly where you left it, ready to be retrieved whenever it is needed.

Cloud Firestore — the database you set up in Module 2 — organises data using two key concepts: Collections and Documents.

A Collection is like a drawer in the filing cabinet — a group of similar items. In your app you might have a collection called "announcements" or a collection called "users."

A Document is like one individual file inside that drawer — one specific item. Inside the "announcements" collection, each individual announcement is one document. Inside the "users" collection, each individual user's profile is one document.

Each document contains fields — the specific pieces of information about that item. For an announcement document, the fields might be: title, content, author, date. For a user document, the fields might be: name, email, role, joinDate. This structure — Collections containing Documents containing Fields — is the foundation of everything we build in this module.

API stands for Application Programming Interface — but the name itself is not very helpful for understanding what it actually does. Think of an API like a waiter in a restaurant.

You — sitting at the table — are the app's user interface. You do not walk into the kitchen and cook your own food. You tell the waiter what you want. The waiter takes your order to the kitchen — the database — where the food — your data — is prepared. The waiter then brings the finished dish back to your table. You never directly touch the kitchen. The waiter is the messenger that connects what you want to where it actually lives.

That is exactly what an API does for your app. Your Home Screen does not directly reach into Firestore and grab data itself. Instead, your app sends a request through an API — "give me all the announcements" — Firestore processes that request and sends back the data, and your Home Screen displays it.

The good news is — when using Firebase with FlutterFlow, you rarely write raw API code yourself. FlutterFlow provides built-in tools that handle the API communication between your app and Firebase automatically. You configure what data you want and where it should appear — and FlutterFlow generates and manages the API calls behind the scenes. This is one of the most powerful advantages of building with FlutterFlow rather than writing raw Flutter code from scratch.

Now let us put it all together using a real example from your own app — what happens when a student opens the Home Screen of SchoolNote.

Step One — The Home Screen loads. FlutterFlow's built-in Firebase connection automatically sends a request — through the API — asking Firestore for every document in the "announcements" collection.

Step Two — Firestore receives this request, looks through the "announcements" collection, and gathers every document inside it.

Step Three — Firestore sends all of that data back through the API — to your app.

Step Four — Your Home Screen receives the data and displays it — generating one card for every document it received, using the layout you built in Module 4.

Step Five — If a teacher posts a new announcement using a different device at any point, that new document is added to the "announcements" collection in Firestore. The next time any student's app requests the announcements — or if you set up live updates, which we cover in section 6.4 — the new announcement appears automatically.

This entire process — request, retrieve, return, display — happens in a fraction of a second. Users never see the technical steps. They just see their app working — showing them current, real, up-to-date information every time they open it. That seamless experience is exactly what you are about to build.

Authentication is the process of verifying who a user is before letting them access your app's content. It answers one essential question — is this person who they claim to be?

When a user registers in your app with an email and password, Firebase Authentication securely stores that information — using industry-standard encryption that even you, the developer, cannot see in plain readable form. When that user later tries to log in, Firebase Authentication checks the email and password they entered against what was securely stored during registration. If they match — access is granted. If they do not — access is denied.

Why this matters for your app: Without real authentication, anyone could pretend to be anyone. A student could log in claiming to be a teacher and post fake announcements. With Firebase Authentication properly connected — every user's identity is verified, and you can control exactly what different types of users — students, teachers, admins — are allowed to see and do within your app.

In section 6.2 we connect this exact system to your Login Screen — replacing the placeholder navigation from Module 4 with genuine, secure user verification.

Before we start connecting Firebase in section 6.2 — let us plan exactly what collections and fields your app will need. This planning step mirrors the wireframing you did in Module 3 — plan first, build second.

Exercise Steps — Complete Before Moving to Section 6.2:

Step 1 — Open a note on your phone called "My Data Structure."

Step 2 — Write down the name of your first collection — most apps need a "users" collection. List the fields each user document will need: name, email, role, joinDate — adapt this to your specific app.

Step 3 — Write down the name of your second collection — the main content collection for your app — "announcements" for a school app, "products" for a marketplace app, "posts" for a social app. List every field each document will need — look back at your Detail Screen from Module 4 to identify exactly what content fields you designed for.

Step 4 — Open Gemini and ask: "I am building a [describe your app] in FlutterFlow with Firebase. I am planning two collections — [list your collections and fields]. Does this structure make sense for my app? Is anything important missing?" Read the feedback and update your structure if needed.

Step 5 — Save your "My Data Structure" note. This is your blueprint for section 6.3 where we build this exact structure inside Firestore.

In Module 4 your Login Screen looked complete — but it was not functional. Tapping Sign In simply navigated to the Home Screen regardless of what was typed into the email and password fields. In this section we fix that — connecting real Firebase Authentication so users genuinely register, genuinely log in, and genuinely have their identity verified.

This is one of the most important connections in your entire app. Authentication is the gateway that protects everything else — your database, your user data, your app's content. Getting it right here means everything that follows in Module 6 builds on a solid, secure foundation.

📱 Phone and 💻 Laptop Users — Follow These Steps:

Step 1 — Open your project in FlutterFlow.

Step 2 — In the left panel or Settings menu look for Firebase or Integrations. Tap or click it.

Step 3 — You will see an option to connect an existing Firebase project. Select Connect Existing Project.

Step 4 — FlutterFlow will ask you to sign in with the same Google account you used to create your Firebase project in Module 2. Sign in and grant FlutterFlow permission to access your Firebase projects.

Step 5 — From the list of your Firebase projects, select the one you created in Module 2 — it-academy-app-project.

Step 6 — FlutterFlow will automatically detect your Firebase services — Authentication, Firestore Database, and Storage — that you already enabled in Module 2. Confirm all three show as connected.

Step 7 — Click Connect or Finish. FlutterFlow now generates the connection code automatically — linking your app project to your Firebase backend. This process replaces what used to take hours of manual configuration with a guided setup that takes minutes.

Step 8 — Write in your "My Dev Tools" note: Firebase connected to FlutterFlow project — Authentication, Firestore and Storage all linked.

Step by Step — Enable Email Authentication:

Step 1 — Open your Firebase Console — the URL you saved in Module 2.

Step 2 — In the left menu tap Authentication.

Step 3 — Tap the Sign-in method tab.

Step 4 — Find Email/Password in the list of providers. Tap it.

Step 5 — Toggle Enable to on. Tap Save. Email and password authentication is now active for your project.

Step 6 — Go back to FlutterFlow. The Authentication settings should now reflect that Email/Password sign-in is available for your app to use.

Step by Step — Connect the Sign In Button:

Step 1 — Open your LoginScreen page in FlutterFlow.

Step 2 — First, give your Email TextField and Password TextField each a Controller — this allows FlutterFlow to capture what the user types. Tap the email field, find the controller setting in the right panel, and confirm it has a name like emailController. Do the same for the password field — passwordController. FlutterFlow usually creates these automatically when fields are generated — confirm they exist.

Step 3 — Tap your Sign In button. In the right panel find the Actions section. You will see the current Navigate Replace action from Module 4. Do not delete it yet — we are adding an authentication action before it.

Step 4 — Tap Add Action and look for an action called Sign In with Email/Password or similar under the Authentication category. Select it. Place it as the first action — before the Navigate Replace action.

Step 5 — Configure the Sign In action: Set the Email field to reference your emailController's value. Set the Password field to reference your passwordController's value. This tells Firebase exactly what the user typed into each field.

Step 6 — Now configure what happens on success and on failure. Find the Success Action setting — this should be your existing Navigate Replace to HomeScreen action. Find the Failure Action setting — add a Show Snackbar or Show Dialog action with the message: "Incorrect email or password. Please try again." This ensures users get clear feedback if their login attempt fails — rather than nothing happening or a confusing silent error.

Step 7 — Save your project.

In Module 4 you created a placeholder RegisterScreen with just a text label. Now we build it properly and connect it to real account creation.

Step by Step — Build and Connect the Register Screen:

Step 1 — Open your RegisterScreen page. Delete the placeholder text.

Step 2 — Use AI generation with this prompt — adapted from your Login Screen prompt in section 4.1: "Generate a registration screen matching the same design as my login screen — dark navy background #060D24, gold accent #D4AF37. Include fields for Full Name, Email Address, Password, and Confirm Password. Include a Create Account button styled the same as my login button. Include a text link at the bottom saying 'Already have an account? Sign In' that returns to the login screen."

Step 3 — Review the generated screen against the same design checklist from section 3.1.7. Refine colours, fonts and spacing to match your Login Screen exactly — consistency between these two screens is essential since users move between them directly.

Step 4 — Add Controllers to all four fields — nameController, emailController, passwordController, confirmPasswordController.

Step 5 — Tap the Create Account button. Add Action → look for Create Account with Email/Password under Authentication. Set the Email and Password fields to reference your controllers.

Step 6 — After the Create Account action, add a second action — Update User Document or Create Firestore Document in the "users" collection, saving the Full Name field value alongside the new account. This connects your authentication record with your Firestore user profile data — tying together the two systems from section 6.1.

Step 7 — Set the Success Action to Navigate Replace to HomeScreen. Set the Failure Action to a Snackbar showing: "Could not create account. Please check your details and try again."

Step 8 — Save your project.

Testing Checklist — Test Every Item:

✅ Open the app preview. Navigate to Register. Create a new account with a real test email and password.

✅ After registering — confirm you land on the Home Screen automatically.

✅ Open your Firebase Console → Authentication. Confirm the new user appears in the Users list.

✅ Open your Firebase Console → Firestore Database → users collection. Confirm a new document was created with the correct name.

✅ Log out using your Profile Screen logout button (we connect real sign-out in section 6.5).

✅ On the Login Screen, log in using the same test email and password. Confirm you reach the Home Screen successfully.

✅ Try logging in with an incorrect password. Confirm the failure message appears and you remain on the Login Screen.

✅ Try registering with an email already used. Confirm an appropriate failure message appears.

If any test fails — open Gemini and describe exactly what happened versus what you expected, using the Error Resolution Process from section 5.5.4. Authentication issues are almost always resolved by checking that controllers are correctly linked to their fields and that the success and failure actions are configured correctly.

With authentication connected, users can now genuinely register and log in. The next step is building the actual data your app displays — creating your collections in Firestore exactly as you planned in section 6.1.5, and populating them with real content.

This section is where your "My Data Structure" note becomes reality — transforming a plan on paper into actual organised data in the cloud that your app will retrieve and display in section 6.4.

Your "users" collection was actually already started automatically in section 6.2.4 — every time someone registers, FlutterFlow creates a new document for them in this collection. Let us review it now and confirm the structure is exactly right.

Step by Step — Review Your Users Collection:

Step 1 — Open your Firebase Console → Firestore Database.

Step 2 — Tap the users collection in the left panel. You should see the document created when you tested registration in section 6.2.5.

Step 3 — Tap that document. Confirm it has the fields from your "My Data Structure" plan — name, email, role, joinDate. If any fields are missing — note this down, we will add them using FlutterFlow's field configuration in Step 4.

Step 4 — Go back to FlutterFlow. In the left panel find Firestore Collections or Data Schema. Find the users collection schema. Confirm every field from your plan is defined here with the correct data type — name as a String, email as a String, role as a String, joinDate as a Timestamp or DateTime. Add any missing fields directly in this schema editor.

Step by Step — Create Your Content Collection in FlutterFlow:

Step 1 — In FlutterFlow open the Firestore Collections or Data Schema panel.

Step 2 — Tap Add Collection or Create New Collection. Name it exactly as planned in your "My Data Structure" note — for example announcements — lowercase, no spaces.

Step 3 — Add the fields for this collection, matching your plan. For an announcement collection, typical fields would be:

title — String
content — String
author — String
datePosted — Timestamp
category — String

For each field — tap Add Field, type the field name exactly, and select the correct data type from the dropdown. Getting the data type correct matters — a date field set as String instead of Timestamp will cause display and sorting problems later.

Step 4 — Save the collection schema. FlutterFlow now knows the exact structure of your content collection and will use this knowledge to help configure the connections in section 6.4.

Now we populate your collection with real content — replacing the sample cards you hardcoded directly into your Home Screen code back in Module 4. Adding data here in Firestore means it lives in the cloud and can be updated anytime, by anyone with the right permissions, without ever touching your app's code again.

Step by Step — Add Data Directly in Firebase Console:

Step 1 — Open your Firebase Console → Firestore Database.

Step 2 — Tap Start Collection if this is the collection's first entry, or find your existing announcements collection and tap Add Document.

Step 3 — For Document ID — select Auto-ID. This lets Firestore generate a unique identifier for each document automatically, rather than you needing to invent unique IDs yourself.

Step 4 — Add each field and its value matching your schema from section 6.3.2:

title (string): "School Reopening Date"
content (string): "The school will reopen on Monday following the public holiday. All students are expected to be in full uniform and on time. Please ensure all holiday assignments are completed and ready for submission on the first day back."
author (string): "Mr. Banda"
datePosted (timestamp): select today's date
category (string): "Important"

Step 5 — Tap Save. Your first real document now exists in your database.

Step 6 — Repeat Steps 2 to 5 to add at least four more documents — using realistic content relevant to your specific app. Vary the categories and dates so you have good test data for the filter chips you built in Module 4.

Step 7 — Open Gemini and ask: "Write five realistic sample announcements for a secondary school app, each with a title and a 3 to 4 sentence content body, varying between categories: Today, This Week, and Important." Use Gemini's suggestions to quickly populate additional realistic entries if you want more test data.

In Module 2 you set up Firestore in test mode — which allows anyone to read and write data freely. This is fine for development and testing, but it is not safe for a real, published app. Before your app goes live, security rules must be configured to control exactly who can read and write what data.

Here is the core principle of Firestore security rules: by default, assume nothing is allowed, then explicitly grant the specific permissions your app needs. For example — any logged-in user should be able to read announcements, but only users with the "teacher" or "admin" role should be able to create new ones.

We will configure production-ready security rules in Module 8 when preparing your app for publishing — for now, continue developing in test mode so nothing blocks your progress. Just remember — test mode must never remain active on an app you publish to real users. We will fix this together before launch.

Verification Checklist — Complete Before Moving to Section 6.4:

✅ Your "users" collection exists with at least one real document from a test registration.

✅ Your main content collection exists — named exactly as planned.

✅ At least five real documents exist in your content collection with realistic, varied data.

✅ Every document has all required fields filled in correctly with the right data types.

✅ Your FlutterFlow Data Schema matches your actual Firestore structure exactly.

✅ You understand the difference between test mode and production security rules, and know this must be addressed before publishing.

Once every item is confirmed — commit your project to GitHub with the message: "Set up Firestore collections, schema and real test data" Your database is now real, structured, and populated. Section 6.4 connects it directly to your Home Screen.

This is the moment everything in Module 6 comes together. Your authentication works. Your database is structured and populated with real data. Now we replace the three hardcoded sample cards on your Home Screen — built back in section 4.3 — with a genuine, live connection to your Firestore announcements collection.

After this section, your Home Screen will display whatever is actually in your database — automatically. Add a new document in Firestore, and it appears in the app. Edit a document, and the change reflects. Delete a document, and it disappears from the list. This is the exact moment your app transforms from a static prototype into a genuinely dynamic, data-driven application.

FlutterFlow connects your ListView widget to a Firestore collection through a feature called a Backend Query. Instead of the ListView containing a fixed, hardcoded list of cards, it instead contains a single card template — and a query that tells FlutterFlow "fill this list using one card per document found in the announcements collection."

This is the single most important concept in this section — one template, automatically repeated for every matching document, instead of you manually duplicating cards as you did in Module 4. This is also dramatically more efficient — your Home Screen will work correctly whether your database has 3 announcements or 3,000.

Step by Step — Connect Your List to Real Data:

Step 1 — Open your HomeScreen page in FlutterFlow.

Step 2 — In your widget tree, select the ListView that currently contains your three sample card widgets from section 4.3.

Step 3 — Delete two of the three sample cards — keep exactly one. This single remaining card becomes your template — the design that FlutterFlow will repeat for every document it finds.

Step 4 — Select this remaining card. In the right panel find a property called Generate Dynamic Children or Generate Children from Variable. Enable it.

Step 5 — You will be asked to choose a data source. Select Backend Query then Firestore Query.

Step 6 — Configure the query:
Collection: select announcements
Query Type: select List of Documents — this retrieves every document in the collection.
Order By: select datePosted and set to Descending — this ensures the newest announcements always appear at the top of the list, which is what users expect from any feed-style screen.

Step 7 — Save the query configuration. FlutterFlow now knows to populate your list using real Firestore data, sorted with the newest first.

Connecting the list to the collection tells FlutterFlow how many cards to create — but each card's text widgets still need to know specifically which field's value to display. This process is called data binding.

Step by Step — Bind Each Field:

Step 1 — Select the title Text widget inside your card template.

Step 2 — In the right panel find the text content property. Instead of typing static text — tap the small lightning bolt or variable icon next to the text field. This opens a variable picker.

Step 3 — Select your announcements document variable — usually automatically named something like announcementsDoc — then select the title field from the list of available fields. The Text widget is now bound to display the title field of whichever document FlutterFlow is currently rendering for that specific card.

Step 4 — Repeat this exact process for every other text element in your card:
Author/Subtitle Text → bind to the author field.
Preview Text → bind to the content field — keep your max lines: 2 and overflow: ellipsis settings from Module 4, so long content still truncates correctly.
Date Text → bind to the datePosted field. FlutterFlow may offer a formatting option here — select a relative format like "2 hours ago" if available, or a simple date format otherwise.

Step 5 — Save your project. Click Preview.

What you should see now — instead of your three hardcoded sample announcements, your Home Screen displays the real documents you added in section 6.3.3 — sorted newest first, with the title, author, date and preview all pulled directly and automatically from your database. This is genuinely live, dynamic data — the heart of a real application.

Your category filter chips from Module 4 were visual only — tapping them changed appearance but did not actually filter anything. Now we connect them to genuinely filter your real data.

Step by Step — Connect Real Filtering:

Step 1 — Recall from section 5.3.2 that your state class has a variable: String selectedFilter = 'All'; In FlutterFlow this corresponds to a Page State variable. Confirm it exists in your page's state management settings.

Step 2 — Select each filter chip widget. Add an Action: Set Page State → set selectedFilter to that chip's specific label — "Today", "This Week", "Important", or "All" for the first chip.

Step 3 — Go back to your Firestore Query configuration from section 6.4.2. Find the option to add a Filter or Where Clause. Add a conditional filter: where the category field equals the current value of selectedFilter — but only apply this filter when selectedFilter does not equal "All". FlutterFlow's query builder typically supports this kind of conditional logic directly in its interface — ask Gemini if you need guidance: "In FlutterFlow, how do I make a Firestore query conditionally filter by a field only when a specific page state value is not equal to 'All'?"

Step 4 — Save and preview. Tap each filter chip and confirm the list updates to show only matching announcements — and tapping "All" shows everything again.

What should your Home Screen show if a filter returns zero results — or if the entire collection is ever empty? Without handling this, users would simply see a blank space, which feels broken even though nothing is technically wrong. Professional apps always design for the empty state.

Step by Step — Add an Empty State:

Step 1 — In FlutterFlow, find the Empty State or Conditional Visibility setting on your dynamic list. Many FlutterFlow versions provide a built-in "Show this widget when query returns no results" option.

Step 2 — Design a simple empty state — a centred icon, with text below it saying: "No announcements yet. Check back soon." Style it using your body font, grey colour, centred on the screen.

Step 3 — Test this by selecting a filter chip for a category that has no matching documents in your test data. Confirm the empty state appears instead of a blank screen.

Testing Checklist — Complete Before Moving to Section 6.5:

✅ The Home Screen displays real data from Firestore — not the original sample cards.

✅ Announcements are sorted with the newest first.

✅ Every field — title, author, date, preview — displays correctly bound to real data.

✅ Tapping each filter chip correctly filters the visible list.

✅ The empty state appears correctly when a filter returns zero results.

✅ Adding a new document directly in Firebase Console and refreshing the app preview shows the new item appearing automatically.

✅ The preview text correctly truncates to two lines with ellipsis for longer content.

Once every item is confirmed working — take a screenshot of your live, data-connected Home Screen. Add it to your portfolio. Commit to GitHub with the message: "Connected Home Screen to live Firestore data with working filters and empty state"

Your Home Screen now displays real, live data from Firestore. But tapping any card still opens the same static Detail Screen with the same sample content from Module 4 — regardless of which card was tapped. And your Profile Screen still shows the placeholder name "Atake Favor Felix" instead of whichever user is actually logged in. This final section of Module 6 fixes both — completing the full data connection across your entire app.

By the end of this section, every screen in your app will reflect real, accurate, dynamic information — exactly as a genuinely functional product should. This is the finishing touch that completes your app's transformation from prototype to product.

When a user taps a specific announcement card on the Home Screen, your Detail Screen needs to know exactly which announcement was tapped — so it can display that specific document's content rather than generic sample text.

FlutterFlow handles this through Page Parameters. Think of a parameter like a small note passed along with the navigation instruction — "go to the Detail Screen, and here specifically is which document to show." The Detail Screen receives this parameter and uses it to know exactly which Firestore document to load and display.

Step by Step — Configure the Parameter:

Step 1 — Open your DetailScreen page in FlutterFlow.

Step 2 — In the page settings find Page Parameters. Add a new parameter. Name it announcementDoc. Set its type to Document Reference pointing to your announcements collection. This tells FlutterFlow: "this entire screen is built around displaying one specific announcement document."

Step 3 — Save this page parameter setting.

Step by Step — Update the Card Tap Action:

Step 1 — Open your HomeScreen page. Select the card template widget — the one with the Navigate To DetailScreen action from section 4.5.3.

Step 2 — Open the existing Navigate To action's settings. You will now see an option to pass Parameter Values along with the navigation — since DetailScreen now expects one.

Step 3 — For the announcementDoc parameter — set its value to reference the current document being rendered in this specific card. This is the same document variable you used for data binding in section 6.4.3 — the same announcementsDoc reference, just passed forward this time instead of displayed directly.

Step 4 — Save. Now every card tap sends along exactly which document was tapped.

Step by Step — Bind Every Detail Screen Element:

Step 1 — Open your DetailScreen page. Select your Content Title Text widget.

Step 2 — Tap the variable icon next to the text property. This time, instead of selecting a list item's document, select your announcementDoc page parameter, then select the title field from it.

Step 3 — Repeat the exact same process for every other element built in section 4.4.2:
Metadata author text → bind to announcementDoc.author
Metadata date text → bind to announcementDoc.datePosted
Content body text → bind to announcementDoc.content

Step 4 — Save and preview. Go to the Home Screen, tap two different announcement cards one after another, and confirm the Detail Screen shows genuinely different content matching whichever card you tapped each time. This is the proof that your data passing is working correctly.

Unlike the Detail Screen, the Profile Screen does not need a parameter passed to it — because it always shows the same thing: whoever is currently logged in. FlutterFlow makes this simpler through a built-in reference called the current user's document — automatically available on every page once a user is authenticated.

Step by Step — Connect the Profile Screen:

Step 1 — Open your ProfileScreen page in FlutterFlow.

Step 2 — Select your User Name Text widget from section 4.4.4. Tap the variable icon. Look for an option referencing the currently logged-in user — often shown as "App State → Current User" or similar. Select it, then select the name field.

Step 3 — Select your User Role Text widget. Bind it to the current user's role field the same way.

Step 4 — Select your Email information row's value text. Bind it to the current user's email field — note this comes directly from Firebase Authentication rather than your Firestore users collection, since email is the account identifier itself.

Step 5 — Update your Avatar initials Text widget from section 4.4.4 — instead of the hardcoded "FF" — bind it to a calculated value showing the first letter of the current user's name field. If FlutterFlow does not offer a direct "first letter" function, ask Gemini: "In FlutterFlow how do I display just the first letter of a text field bound to a Firestore document?"

Step 6 — Save and preview. Log in with one of your test accounts from section 6.2.5. Confirm the Profile Screen shows that specific account's real name, role and email — not placeholder text.

In Module 4, your Logout button simply navigated to the Login Screen — without genuinely ending the user's authenticated session. Let us fix that now.

Step by Step — Connect Real Sign Out:

Step 1 — Open your ProfileScreen page. Select the Log Out button widget.

Step 2 — In the Actions panel — before your existing Navigate Replace to LoginScreen action — add a new action: Sign Out or Firebase Sign Out from the Authentication action category.

Step 3 — Confirm this Sign Out action runs first, then the Navigate Replace to LoginScreen runs second. This order matters — sign out the user from Firebase, then send them to the Login Screen.

Step 4 — Save and preview. Log in, navigate to Profile, tap Log Out. Confirm you return to the Login Screen. Then try navigating directly to the Home Screen using your device's back button or any other means — confirm you are correctly redirected back to Login, since your session has genuinely ended.

Complete Module 6 Journey Test:

✅ Register a brand new test account.

✅ Confirm automatic navigation to Home Screen after registration.

✅ Confirm Home Screen shows real, live data from Firestore.

✅ Tap two different cards and confirm Detail Screen content genuinely differs between them.

✅ Tap back on the Detail Screen, confirm return to Home Screen with scroll position preserved.

✅ Navigate to Profile Screen and confirm it shows the real registered name, role and email.

✅ Tap Log Out, confirm genuine sign out and return to Login Screen.

✅ Log back in with the same test account and confirm everything still displays correctly.

Once every single item passes — your app is genuinely, fully functional. Commit to GitHub with the message: "Completed Module 6 — full data connection across Home, Detail and Profile screens with working authentication"