Mobile App Development

DASKEREL wrote this teaching and practice using Oak's sequence as a source. View the source lesson at Oak National Academy. Oak has not endorsed this material. Check Oak's terms and separate rights for third-party works.

Learning outcomes

Turn a user need into screens and observable criteria
Keep the first prototype small, accessible and privacy-safe

Vocabulary: user story · screen · prototype · navigation · acceptance criterion

Retrieve previous learning

Why does a website brief name audience and action before styling?

Check: Design choices can then be tested against what the intended user actually needs to do.

Learn the concept

An app is a set of interactions for a user task, not just a decorated screen. A fictional school book finder might let a learner view a short preloaded catalogue and filter by subject. Its first version does not need login, location or a live database. Write a user story: 'As a pupil, I want to find a study book by subject so I can plan a library visit.'

Sketch one home screen and one results screen with a clear route back. Label controls by action, such as 'Choose subject' and 'Show books', instead of vague icons. A finger-friendly layout also needs readable text, logical focus order and a non-touch alternative where the chosen tool supports one.

Define observable success: the user can choose a subject, see matching fictional titles and return home without losing control. Ask what personal data is truly required; for this prototype, none is. A teacher should check source assets, rights and usability before any sharing.

Worked model

Write the book-finder user story and list preloaded fictional data.
Sketch home, subject choice and result, with a visible back route.
Write three acceptance tasks for a test user.
Reject unnecessary login and location permissions for the prototype.

Guided practice

A draft book finder requests a pupil's home address before showing a preloaded list. Is it needed?

Hint: Compare the data request with the user story.

Check the guided answer

No. Finding books by subject in a preloaded list does not require a home address. Remove the request and test the task without personal data.

Independent practice

Write your own response to every question before viewing the model answers. Your writing stays in this page session; this activity does not submit, store or grade it. Avoid including private information.

Teacher observed practical evidence

A teacher must apply the school's risk assessment, allergy policy and any individual healthcare plan before the practical. Observe and record the criteria during supervised work. Written answers cannot certify practical safety or skill.

Teacher observes an original app prototype running in an approved development tool or simulator and checks the editable source.
Learner demonstrates two interaction paths, an invalid or missing input case, keyboard or accessible navigation where supported, and one corrected defect.
No real pupil account, contact, location or payment data is collected or transmitted by the classroom prototype.

Find and correct a misconception

“Every app needs user registration to be useful.”

Correction: A small local prototype can solve a task with preloaded data and no personal account.

Extend and reflect

Plan a text-only version of the book finder.

Guidance: Preserve subject selection, result label and a back action without depending on icons.

Where this lesson could lead · Computer Science GCSE → Daskerel Computing and AI

This lesson practises: Turn a user need into screens and observable criteria. Algorithms, digital systems and safe practice support later software and technology work.

Next school subject: Computer Science GCSE. Check the subject and examination board that fit your school.
Later DASKEREL learning: Daskerel Computing and AI. Explore further study and build evidence from practical work.
Later credential exploration: AWS Certified Developer - Associate is an example in this later specialism. Check current awarding-body requirements before planning an exam.
Example career direction: Software Engineer. Explore organisations and local support.

This is an exploratory route, not a promise of admission, a qualification, certification eligibility or employment. Years 7–9 learning is an early foundation; any later credential may require substantial study, experience or local approval.

Year 8 · Creative digital projects · original lesson pack

DASKEREL beta · internal AI review pending

Make controls respond to named events

DASKEREL wrote this teaching and practice using Oak's sequence as a source. View the source lesson at Oak National Academy. Oak has not endorsed this material. Check Oak's terms and separate rights for third-party works.

Learning outcomes

Explain event-handler behaviour
Test two controls and a repeated action

Vocabulary: event · handler · button · state · feedback

Retrieve previous learning

What does a good app acceptance criterion describe?

Check: An observable user task and expected outcome, not only an attractive appearance.

Learn the concept

A mobile app responds to events such as a button tap. In a fictional study-timer prototype, tapping Start begins a countdown only when a valid duration has been selected; tapping Pause stops it temporarily. The screen must show feedback so the user knows whether the action was accepted.

An event handler describes what runs after a specific event. If both Start and Pause use the same handler by mistake, the interface may look correct but behave incorrectly. Keep state such as running or paused explicit, then trace before and after each tap. Rapid repeated taps need a defined response so two timers are not accidentally started.

Test on the approved simulator or device with normal, repeated and unexpected actions. Do not imply touch is the only access method: check labels, focus and alternatives supported by the tool. A teacher should observe the actual interaction and compare it with the saved event logic.

Worked model

Define timer states idle, running and paused.
Map Start and Pause to separate handlers and expected state changes.
Trace Start, Pause, Start and a repeated Start tap.
Run the prototype and record whether feedback matches each predicted state.

Guided practice

A second Start tap launches a second countdown. What should the handler check?

Hint: Read the current running state.

Check the guided answer

The handler should avoid starting another timer when already running, or define a clear restart action. Test the repeated tap and display an understandable state.

Independent practice

Write your own response to every question before viewing the model answers. Your writing stays in this page session; this activity does not submit, store or grade it. Avoid including private information.

Teacher observed practical evidence

A teacher must apply the school's risk assessment, allergy policy and any individual healthcare plan before the practical. Observe and record the criteria during supervised work. Written answers cannot certify practical safety or skill.

Teacher observes an original app prototype running in an approved development tool or simulator and checks the editable source.
Learner demonstrates two interaction paths, an invalid or missing input case, keyboard or accessible navigation where supported, and one corrected defect.
No real pupil account, contact, location or payment data is collected or transmitted by the classroom prototype.

Find and correct a misconception

“A visible button automatically performs an action.”

Correction: It needs a correctly connected event handler and a tested state transition.

Extend and reflect

Specify what Cancel does from running and paused states.

Guidance: Make both transitions explicit and test the display returns to a safe idle state.

Where this lesson could lead · Computer Science GCSE → Daskerel Computing and AI

This lesson practises: Explain event-handler behaviour. Algorithms, digital systems and safe practice support later software and technology work.

Next school subject: Computer Science GCSE. Check the subject and examination board that fit your school.
Later DASKEREL learning: Daskerel Computing and AI. Explore further study and build evidence from practical work.
Later credential exploration: AWS Certified Developer - Associate is an example in this later specialism. Check current awarding-body requirements before planning an exam.
Example career direction: Software Engineer. Explore organisations and local support.

This is an exploratory route, not a promise of admission, a qualification, certification eligibility or employment. Years 7–9 learning is an early foundation; any later credential may require substantial study, experience or local approval.

Year 8 · Creative digital projects · original lesson pack

DASKEREL beta · internal AI review pending

Validate app input before storing and using it

DASKEREL wrote this teaching and practice using Oak's sequence as a source. View the source lesson at Oak National Academy. Oak has not endorsed this material. Check Oak's terms and separate rights for third-party works.

Learning outcomes

Store a bounded input in a variable
Handle blank and invalid values without misleading output

Vocabulary: input · variable · validation · range · error message

Retrieve previous learning

What is app state?

Check: The values, such as running or paused, that determine how an event should behave at a given moment.

Learn the concept

A timer app may ask for whole minutes. The input arrives as text, so a program must check that it represents an allowed number before using it in arithmetic. For a classroom prototype, define a range such as 1–60 minutes; this is a design constraint, not a rule for all users.

Store a valid value in a duration variable and display it with units. If the field is blank or says 'five', show an error without starting the timer or overwriting the last valid value unexpectedly. Test 0, 1, 60 and 61 to check the boundary. A variable should name its purpose, such as durationMinutes.

Do not ask for names, contacts or location to run a local timer. Accessible error messages should explain how to correct the input and be available through the chosen tool's supported controls. A teacher should observe actual invalid-input behaviour, not only read the validation rule.

Worked model

Define 1–60 whole minutes as the fictional app's accepted range.
Read input text, parse an integer only if valid, and store durationMinutes.
Show a helpful error for blank, nonnumeric, 0 and 61.
Test 1 and 60 successfully and verify no countdown starts on invalid input.

Guided practice

A user enters 0 in a 1–60-minute timer. What should happen?

Hint: Zero is below the stated range.

Check the guided answer

Do not start a zero-minute countdown. Show an accessible message such as 'Enter a whole number from 1 to 60 minutes' and keep the field available for correction.

Independent practice

Write your own response to every question before viewing the model answers. Your writing stays in this page session; this activity does not submit, store or grade it. Avoid including private information.

Teacher observed practical evidence

A teacher must apply the school's risk assessment, allergy policy and any individual healthcare plan before the practical. Observe and record the criteria during supervised work. Written answers cannot certify practical safety or skill.

Teacher observes an original app prototype running in an approved development tool or simulator and checks the editable source.
Learner demonstrates two interaction paths, an invalid or missing input case, keyboard or accessible navigation where supported, and one corrected defect.
No real pupil account, contact, location or payment data is collected or transmitted by the classroom prototype.

Find and correct a misconception

“A numeric-looking text field always provides a number to the program.”

Correction: User input may be text or invalid; validation and conversion are needed before arithmetic.

Extend and reflect

Plan how a screen reader would receive the error.

Guidance: Use the app tool's supported labelled error mechanism and verify it on the target access method.

Where this lesson could lead · Computer Science GCSE → Daskerel Computing and AI

This lesson practises: Store a bounded input in a variable. Algorithms, digital systems and safe practice support later software and technology work.

Next school subject: Computer Science GCSE. Check the subject and examination board that fit your school.
Later DASKEREL learning: Daskerel Computing and AI. Explore further study and build evidence from practical work.
Later credential exploration: AWS Certified Developer - Associate is an example in this later specialism. Check current awarding-body requirements before planning an exam.
Example career direction: Software Engineer. Explore organisations and local support.

This is an exploratory route, not a promise of admission, a qualification, certification eligibility or employment. Years 7–9 learning is an early foundation; any later credential may require substantial study, experience or local approval.

Year 8 · Creative digital projects · original lesson pack

DASKEREL beta · internal AI review pending

Keep app navigation and state predictable

DASKEREL wrote this teaching and practice using Oak's sequence as a source. View the source lesson at Oak National Academy. Oak has not endorsed this material. Check Oak's terms and separate rights for third-party works.

Learning outcomes

Map a route between two screens
Explain what state should persist or reset on return

Vocabulary: navigation · screen · back action · state · focus

Retrieve previous learning

Why validate a duration input before starting a timer?

Check: Blank, nonnumeric or out-of-range text could produce wrong or confusing behaviour.

Learn the concept

An app with multiple screens needs a map of where each control leads. A fictional book finder may move from Home to Results, then to Book detail and back. The back route should be visible and labelled. A user should not lose a valid subject choice merely because they inspect one result unless that reset is an explicit design decision.

State can persist or reset. Returning from detail to Results might retain the chosen subject; returning to Home might clear the search after a new-session action. Write those rules in a transition table. If the app recreates a screen unexpectedly, a test may reveal lost input or duplicate actions.

Check focus order, readable headings and support for the device's back action where relevant. Do not rely only on swipes or tiny unlabeled icons. A teacher should observe a learner navigate using the supported input methods and inspect the actual screens, not just a flowchart.

Worked model

Draw Home → Results → Detail and reverse routes for the fictional finder.
Specify that subject selection persists when returning from Detail to Results.
Test both back actions and a new-search reset.
Check labels and focus after each screen change in the approved prototype.

Guided practice

Returning from Book detail always clears the selected subject. What should be tested?

Hint: Compare this with the written navigation rule.

Check the guided answer

If the design says the result filter persists, test the back transition and state storage. Correct the reset or explicitly revise the brief if clearing is intended, then retest both routes.

Independent practice

Write your own response to every question before viewing the model answers. Your writing stays in this page session; this activity does not submit, store or grade it. Avoid including private information.

Teacher observed practical evidence

A teacher must apply the school's risk assessment, allergy policy and any individual healthcare plan before the practical. Observe and record the criteria during supervised work. Written answers cannot certify practical safety or skill.

Teacher observes an original app prototype running in an approved development tool or simulator and checks the editable source.
Learner demonstrates two interaction paths, an invalid or missing input case, keyboard or accessible navigation where supported, and one corrected defect.
No real pupil account, contact, location or payment data is collected or transmitted by the classroom prototype.

Find and correct a misconception

“Navigation is complete once links move forward.”

Correction: Users need predictable return routes, state handling and accessible control labels.

Extend and reflect

Plan how to preserve a partly completed form when a user views Help.

Guidance: Define whether input persists and test return from Help without unintended submission.

Where this lesson could lead · Computer Science GCSE → Daskerel Computing and AI

This lesson practises: Map a route between two screens. Algorithms, digital systems and safe practice support later software and technology work.

Next school subject: Computer Science GCSE. Check the subject and examination board that fit your school.
Later DASKEREL learning: Daskerel Computing and AI. Explore further study and build evidence from practical work.
Later credential exploration: AWS Certified Developer - Associate is an example in this later specialism. Check current awarding-body requirements before planning an exam.
Example career direction: Software Engineer. Explore organisations and local support.

This is an exploratory route, not a promise of admission, a qualification, certification eligibility or employment. Years 7–9 learning is an early foundation; any later credential may require substantial study, experience or local approval.

Year 8 · Creative digital projects · original lesson pack

DASKEREL beta · internal AI review pending

Build the first tested app prototype

DASKEREL wrote this teaching and practice using Oak's sequence as a source. View the source lesson at Oak National Academy. Oak has not endorsed this material. Check Oak's terms and separate rights for third-party works.

Learning outcomes

Implement a small brief in stages
Record tests before adding extra features

Vocabulary: minimum viable prototype · version · event · test log · defect

Retrieve previous learning

What should happen to a subject filter when returning from book detail if the brief says it persists?

Check: The prior choice should still be available on the results screen.

Learn the concept

Part one of a project turns a bounded brief into a working minimum prototype. For the fictional book finder, implement Home, a subject choice and a Results screen with preloaded invented titles. The user should be able to return home. Do not add login, live messaging or a database before the core task works.

Build one interaction at a time: first navigation, then subject selection, then matching results. For each, write a test input and expected output. If a selected 'Science' subject shows a History title, inspect the stored subject value and filter condition. Keep versions so a correction can be explained.

Use original or licensed assets, no real pupil records and school-approved tools. Check a narrow screen and supported accessible navigation. A teacher should observe the prototype run and see the source and test log; a polished screenshot is not sufficient practical evidence.

Worked model

Create Home and Results screens with labelled forward and back actions.
Add an invented list of two Science and two History titles.
Bind subject selection to a variable and display matching titles only.
Test both subjects, no selection and return navigation; record one revision.

Guided practice

Science is selected but all titles appear. What logic should be checked?

Hint: The results should use the selected subject value.

Check the guided answer

Check whether the result filter compares each item's subject with the stored selection and whether the selection was saved before navigation. Retest Science and History after correction.

Independent practice

Write your own response to every question before viewing the model answers. Your writing stays in this page session; this activity does not submit, store or grade it. Avoid including private information.

Teacher observed practical evidence

A teacher must apply the school's risk assessment, allergy policy and any individual healthcare plan before the practical. Observe and record the criteria during supervised work. Written answers cannot certify practical safety or skill.

Teacher observes an original app prototype running in an approved development tool or simulator and checks the editable source.
Learner demonstrates two interaction paths, an invalid or missing input case, keyboard or accessible navigation where supported, and one corrected defect.
No real pupil account, contact, location or payment data is collected or transmitted by the classroom prototype.

Find and correct a misconception

“A project is better if every possible feature is added before the first test.”

Correction: A small tested core exposes logic and navigation defects early; add features only when they serve the brief.

Extend and reflect

Plan a 'No matches' result without collecting new data.

Guidance: Give a clear message, keep the chosen subject visible and allow the user to choose again.

Where this lesson could lead · Computer Science GCSE → Daskerel Computing and AI

This lesson practises: Implement a small brief in stages. Algorithms, digital systems and safe practice support later software and technology work.

Next school subject: Computer Science GCSE. Check the subject and examination board that fit your school.
Later DASKEREL learning: Daskerel Computing and AI. Explore further study and build evidence from practical work.
Later credential exploration: AWS Certified Developer - Associate is an example in this later specialism. Check current awarding-body requirements before planning an exam.
Example career direction: Software Engineer. Explore organisations and local support.

This is an exploratory route, not a promise of admission, a qualification, certification eligibility or employment. Years 7–9 learning is an early foundation; any later credential may require substantial study, experience or local approval.

Year 8 · Creative digital projects · original lesson pack

DASKEREL beta · internal AI review pending

Evaluate and improve the app prototype

DASKEREL wrote this teaching and practice using Oak's sequence as a source. View the source lesson at Oak National Academy. Oak has not endorsed this material. Check Oak's terms and separate rights for third-party works.

Learning outcomes

Use test evidence to revise a prototype
Report limitations and a safe release decision

Vocabulary: evaluation · accessibility · regression test · limitation · release

Retrieve previous learning

Why test the no-selection case in a subject filter?

Check: The app needs a defined response instead of showing unrelated or misleading results.

Learn the concept

Part two evaluates the prototype against the original user task. Give a peer a task to find one fictional Science book and return home without coaching. Record where they hesitate, whether the subject filter works and whether labels make sense. A small peer test provides specific feedback, not proof for all learners.

Revise a documented issue, then rerun earlier tests. If improving the Results layout breaks the History filter, a regression test catches it. Include invalid and empty states, keyboard or supported assistive navigation, and narrow-screen readability. Check the actual exported or installed preview, not only the editor canvas.

Report what is and is not ready. A classroom app with invented titles and no private data may be suitable for a supervised demonstration. A public service would need verified live content, privacy decisions, security, accessibility and maintenance ownership. Do not claim the prototype provides an official library catalogue.

Worked model

Run the Science-find-and-return task with a peer and record observed steps.
Choose one defect, such as an unlabeled return control, and revise it.
Rerun Science, History, no-selection and back-navigation tests.
Document evidence, remaining limits and supervised-demo-only status.

Guided practice

A revised Results screen looks better but History now shows Science titles. What should be done?

Hint: Earlier working behaviour needs retesting.

Check the guided answer

Treat it as a regression defect. Inspect the subject filter and stored selection, correct the logic, then rerun both subject tests and navigation tests before sharing.

Independent practice

Write your own response to every question before viewing the model answers. Your writing stays in this page session; this activity does not submit, store or grade it. Avoid including private information.

Teacher observed practical evidence

A teacher must apply the school's risk assessment, allergy policy and any individual healthcare plan before the practical. Observe and record the criteria during supervised work. Written answers cannot certify practical safety or skill.

Teacher observes an original app prototype running in an approved development tool or simulator and checks the editable source.
Learner demonstrates two interaction paths, an invalid or missing input case, keyboard or accessible navigation where supported, and one corrected defect.
No real pupil account, contact, location or payment data is collected or transmitted by the classroom prototype.

Find and correct a misconception

“Once a revised app passes one task, no old features need retesting.”

Correction: A revision can break earlier behaviour; rerun the relevant regression and access checks.

Extend and reflect

Draft a short change log for the revised back control.

Guidance: Record defect, change, date, tested input methods and any remaining limitation.