My progress
Menu

Mobile App Developer · Capstone

MA10: Capstone: offline, usable and ready to release for KhetNote

Goal: bring the whole path together by completing, testing and presenting the three path projects: offline-first saving and sync, fast and accessible screens, and a release that's ready for the stores, all in the KhetNote practice kit, plus design notes on the platform approach, the app's architecture, native features and background work, and releasing and running the app.

You'll need: everything from MA1–MA9, the KhetNote practice kit (download it from this path's Projects page), and Node.js 22 or later. No phone, Expo account, store account or payment account is needed for the tests, and no real farmer's data is used.

Where this is used: this mirrors real mobile work: making an app keep working where the signal drops, making it fast and usable on the phones people actually own, and preparing a release that the stores accept and that reaches users safely. A portfolio with these three, backed by passing checks and honest notes, shows employers more than a screenshot of an app.

How it differs: each earlier module taught one skill. The capstone tests whether you can combine them: the offline work uses the storage and sync patterns from MA4 and MA5, the screens need the React Native basics, accessibility and performance from MA2, MA6 and MA7, and the release uses the permissions, privacy and store steps from MA8 and MA9.

Time: reading about 2 hours · practice (the Try it tasks) about 2 hours · projects and capstone about 40 to 50 hours in all.

Lessons

  1. 1Planning the capstoneReading 15–25 minutes, plus practice✓
  2. 2Project 1: offline-first saving and syncReading 15–25 minutes, plus practice✓
  3. 3Project 2: fast and accessible screensReading 15–25 minutes, plus practice✓
  4. 4Project 3: ready to releaseReading 15–25 minutes, plus practice✓
  5. 5Demo, self-review and case studiesReading 15–25 minutes, plus practice✓

🛠️Assignment: Finish and present KhetNote

  1. Complete Projects 1 to 3 so that npm test passes 28 of 28 in one run.
  2. Write the design notes from the template: the platform approach, the architecture, one native feature and background work, and the release plan.
  3. Record a 10 to 15 minute demo following the script.
  4. Write three case studies, one per project, with every figure labelled.
  5. Write a self-review against the marking guides, marking anything untried "not verified".

Self-check before you finish:

✅Module check

Explain in a few sentences, in your own words:

What did the three KhetNote projects and the capstone show you can do?

Show a good answer

A good answer mentions: visits saved on the phone first, an outbox that survives restarts and syncs on reconnect, idempotency keys, backoff and a timeout, a cursor for pulling, and merges that keep the adviser's change and flag clashes; a virtualised list with memoised, keyed rows of known height, 48-point targets, roles and names, a swipe with an accessibility action and Undo, dark mode with readable contrast, and helpful form errors; a release with correct versions, only the permissions used, no secrets, an automated build, a bundle under budget, plain notes and a matching listing; design notes on the platform, architecture, features and release; and a demo, case studies and self-review with every figure labelled and untried things marked not verified.

📚Official references

Official documentation and guidance for this module's topics, chosen on 2 November 2026. Tools, laws and standards change, so check the current version before you rely on a detail. If a link has moved, search the same site.

📝Module quiz

10 questions · 10 marks each · 100 marks in all · pass mark 70% · retry as often as you like ·

1. A learner's plan gives Project 3 five weeks and Project 1 one week. What's the main problem with it?

Why each option is right or wrong

  • “Project 3 should come first, since store review takes the longest to finish” (Incorrect): The release project follows MA8 and MA9, after the app works.
  • “The plan should give every project exactly the same number of weeks to be fair” (Incorrect): Time should follow the work, not a rule of equal shares.
  • “One week is too long for Project 1, since its tests run in a few seconds” (Incorrect): Fast tests don't mean fast work.
  • “Project 1 has the most cases to get right, so it needs the most time” is correct.

    Storage, outbox, keys, backoff, timeouts, cursors and merging are ten tests' worth of logic.

    • Order: Project 1, then 2, then 3.

📖 Revise: Lesson 1: Planning the capstone

Question ID sp-mobile-10-q1 · Report a mistake in this question
2. Test 01 fails: a saved visit is gone after the app is closed and opened again. What's the most likely cause?

Why each option is right or wrong

  • “The phone has run out of storage space for the visits” (Incorrect): The kit's tests use a mocked storage with room to spare.
  • “The sync server deleted the visit while the app was closed” (Incorrect): The test checks the phone's copy, not the server.
  • “The visit list doesn't redraw after the app opens again” (Incorrect): The test reads the store directly, not the screen.
  • “The store keeps visits only in memory, not in AsyncStorage” is correct.

    Memory is cleared when the app closes.

    • Fix: save under one key and load it when the app opens.

📖 Revise: Lesson 2: Project 1: offline-first saving and sync

Question ID sp-mobile-10-q2 · Report a mistake in this question
3. With two changes waiting and no connection, a learner's banner says "Synced". What should it say, following the kit's formats?

Why each option is right or wrong

  • “"Error: no internet", in red, so the adviser knows something is wrong” (Incorrect): Nothing is wrong: the visits are safe on the phone.
  • “Nothing at all, since the adviser can't do anything until the signal returns” (Incorrect): The adviser needs to know whether their work is saved.
  • “"Synced", since the visits will be sent to the office sooner or later anyway, once there's signal” (Incorrect): It tells the adviser something untrue.
  • “"Offline · 2 changes waiting", so the adviser knows the work is saved and pending” is correct.

    The banner says honestly what's happening.

    • Kit: syncMessage in docs/FORMATS.md.

📖 Revise: Lesson 2: Project 1: offline-first saving and sync

Question ID sp-mobile-10-q3 · Report a mistake in this question
4. During a conflict, the server's copy has a new crop, and the adviser changed the advice. What should the merge do?

Why each option is right or wrong

  • “Keep the server's copy whole, since it arrived later than the adviser's” (Incorrect): The adviser's advice would be lost.
  • “Keep the adviser's copy whole and send it over the server's again” (Incorrect): The new crop would be lost.
  • “Stop syncing until someone at the office decides by hand” (Incorrect): The outbox would stall for every visit.
  • “Keep the adviser's advice, take the server's crop, and flag any field both changed” is correct.

    Each side's change is kept where they don't clash.

    • Kit: test 09 checks this.

📖 Revise: Lesson 2: Project 1: offline-first saving and sync

Question ID sp-mobile-10-q4 · Report a mistake in this question
5. The visit list uses a ScrollView with 520 rows and random keys. What's the best change?

Why each option is right or wrong

  • “Load only the first 50 visits and hide the rest of them from the adviser” (Incorrect): Advisers need their older visits too.
  • “Keep the ScrollView and add a loading spinner while all the rows are drawn” (Incorrect): The phone still draws all 520 rows.
  • “Ask advisers to archive old visits so the list stays short” (Incorrect): The list should cope with the data people have.
  • “A FlatList with memoised rows, keys from the visit ID, and getItemLayout” is correct.

    Only nearby rows are drawn, and rows don't redraw needlessly.

    • Kit: tests 01 to 03 check these.

📖 Revise: Lesson 3: Project 2: fast and accessible screens

Question ID sp-mobile-10-q5 · Report a mistake in this question
6. Archiving works only by swiping a row. Which addition matters most for screen reader users?

Why each option is right or wrong

  • “A coloured hint on each row that suggests swiping left” (Incorrect): Screen reader users may not see the colour.
  • “A faster swipe so it's easier to trigger by mistake” (Incorrect): Easier mistakes make it worse.
  • “A tutorial screen explaining the swipe gesture when the app first opens, with a short animation” (Incorrect): The gesture is still hard with a screen reader.
  • “An accessibility action that archives the row, with the same Undo bar” is correct.

    It gives a non-gesture way to do the same thing.

    • Kit: test 06 checks the action and Undo.

📖 Revise: Lesson 3: Project 2: fast and accessible screens

Question ID sp-mobile-10-q6 · Report a mistake in this question
7. The muted text colour #A0A8A0 on white has a contrast of about 2.4:1. What should change?

Why each option is right or wrong

  • “Make the muted text bold and keep the same colour” (Incorrect): Bold helps a little but doesn't fix the contrast.
  • “Remove dark mode so only the light theme needs checking” (Incorrect): The phone's setting is part of the brief.
  • “Use the muted colour only for less important text, such as dates and status messages” (Incorrect): People still need to read it.
  • “A darker muted colour in the light theme, and a checked one in the dark theme” is correct.

    Both themes need 4.5:1 or more.

    • Kit: test 08 checks both.

📖 Revise: Lesson 3: Project 2: fast and accessible screens

Question ID sp-mobile-10-q7 · Report a mistake in this question
8. Test 08 fails: the listing says "Permissions: none", but app.json asks for one the app doesn't use. What's the best fix?

Why each option is right or wrong

  • “Add the permission to the listing so the answers and app.json agree” (Incorrect): The app still asks for something it doesn't need.
  • “Remove the data safety section so there's nothing for the test to compare” (Incorrect): The stores require it.
  • “Rename the permission in app.json so the test doesn't recognise it” (Incorrect): The built app would still ask for it.
  • “Remove the permission from app.json, and block it if a library adds it” is correct.

    The app then asks only for what it uses, and the answers are true.

    • Kit: tests 02 and 08.

📖 Revise: Lesson 4: Project 3: ready to release

Question ID sp-mobile-10-q8 · Report a mistake in this question
9. Test 06 fails: the code bundle is 4.2 MB against a 2 MB budget. What's the right approach?

Why each option is right or wrong

  • “Change the test's budget to 5 MB, since 4.2 MB is close enough” (Incorrect): The tests are the brief; the phones are the same.
  • “Split the app into two smaller apps in the store” (Incorrect): Advisers would need both, and the total is the same.
  • “Skip the export step in CI so the size isn't measured” (Incorrect): The bundle stays large on the phones.
  • “Find what's large and unneeded, here the demo photos import, and remove it” is correct.

    The bundle falls to about 1.6 MB.

    • Then: run npm run test:release again.

📖 Revise: Lesson 4: Project 3: ready to release

Question ID sp-mobile-10-q9 · Report a mistake in this question
10. A case study says "KhetNote works on every phone and is 60% faster". What's the best rewrite?

Why each option is right or wrong

  • “Keep it, since bold claims stand out to hiring managers more than careful ones” (Incorrect): Unchecked claims lose trust in interviews.
  • “Remove all figures so nothing can be questioned” (Incorrect): Labelled figures make the work credible.
  • “Change it to "works on most phones and is about 50% faster"” (Incorrect): It's still unmeasured.
  • “Say what the tests checked, label figures as practice-kit data, and mark phones not verified” is correct.

    Every claim then says where it comes from.

    • Measured: the bundle fell from 4.2 MB to about 1.6 MB.

📖 Revise: Lesson 5: Demo, self-review and case studies

Question ID sp-mobile-10-q10 · Report a mistake in this question

ProLearners Assist