Loading the lesson
Loading the lesson
Search AllRounder.ai
Search the courses, subjects, tracks, games and features, or jump straight to a page.
Search the courses, subjects, tracks, games and features, or jump straight to a page.
Learn it your way
A short class with Sarah and her students. The other ways are under More.
Sign up free to listen. Transcripts are free to read.
Our quiz app's screen is ready, with a question label, an answer box and a Check button. But if we tap Check now, what happens?
Nothing, because we have not told the button what to do yet.
Exactly. That is the job of the development step. In App Inventor, where do we add that behaviour?
In the Blocks view. The Designer view is only for placing components and setting their properties.
Right. Which block would you start with?
The 'when CheckButton.Click do' block, because it runs when the user taps the button.
When Check is tapped, the app must decide whether the answer is right. Which block helps it decide?
The 'if then else' block.
What goes in the 'if' part?
A comparison: is AnswerBox.Text equal to 'New Delhi'?
Good. And the two branches?
Then set ResultLabel.Text to 'Correct! Well done.', else set it to 'Try again.'
Perfect. In Python, the same logic is an if statement with an else. Blocks and code say the same thing in different ways.
Arjun built ten features at once, and now his app crashes. What would have helped?
Building one feature, testing it, and only then adding the next one.
Yes. What else makes a big project easier to manage?
Giving components clear names, like btnCheck instead of Button1, so the blocks make sense.
And if a change goes badly wrong?
If we saved a checkpoint first, we can go back to the version that worked.
turning the planned features and designed screens into a working app.
components and their properties are set in one view, and the logic is built in the other.
blocks inside an event, such as "when Button1.Click", run only when that event happens.
the if–then–else block lets the app choose between actions, such as showing "Correct!" or "Try again".
variables remember values, such as a score, from one event to the next.
building and testing one feature at a time makes bugs easy to find.
The quiz-checking logic written in Python, as it would work behind a Check button:
def check_answer(answer):
if answer == "New Delhi":
return "Correct! Well done."
else:
return "Try again."
print(check_answer("New Delhi"))
print(check_answer("Kolkata"))A "Like" counter: each tap adds 1 to a variable and shows the new total; this Python version imitates three taps:
count = 0
for tap in range(3):
count = count + 1
print("Likes:", count)In a greeting app, "when btnHello.Click do set lblMessage.Text to join 'Hello, ' TextBox1.Text" shows Hello followed by the name the user typed.
In a game, "when Screen1.Initialize do set global score to 0" makes sure every new game starts with a score of zero.
Place it, block it, test a bit; one more feature, then repeat it.
Meera built her quiz app in one go and nothing worked. Her teacher showed her how to add just the Check button, test it, then add the score, then the next question. Feature by feature, the app came to life, and every bug was easy to find.
E.V.I.: Events start it, Variables remember it, If-then-else decides it.
B.U.I.L.D. - Blocks for logic, Useful names, Increment one feature at a time, Leave comments, Do save checkpoints.
Term
Where is an app's logic built in MIT App Inventor?
Click to flip
Term
What is an event?
Click to flip
Term
When do the blocks inside "when Button1.Click do" run?
Click to flip
Term
Which block lets an app choose between two actions?
Click to flip
Term
Why build an app one feature at a time?
Click to flip
The step of app making in which the planned and designed app is built using blocks or code.
An item placed on an app's screen, such as a Button, Label, TextBox or Image.
A setting of a component, such as its text, colour, size or whether it is visible.
Something that happens while an app runs, such as a button being tapped or a screen opening.
A block or piece of code, such as "when Button1.Click do", that runs when a particular event happens.
A named store for a value, such as a score, that the app can change and remember.
A yes-or-no test, such as "is the answer correct?", that decides which action the app takes.
A mistake in an app's logic or code that makes it behave wrongly.
Development is the step where the planned and designed app is actually built, by joining blocks or writing code that tells the app what to do when the user taps, types or opens a screen.
In this step the wireframes and feature list from the earlier steps become a working app. With beginner tools such as MIT App Inventor, Thunkable or Kodular, building has two parts: arranging components such as buttons, labels and text boxes on the screen, and joining blocks that hold the app's logic. This lesson explains event-driven programming, the main kinds of blocks (events, variables, conditions, maths and text), how if–then–else lets an app make decisions, how the same logic looks in Python code, and the good habits that keep development on track: building one feature at a time, using clear names, adding comments and saving often.
By Step 5 you know what the app is for, which features it needs, what its screens look like and which platform you will use. Development turns all of that into an app that works. It is often the longest step, and it is closely tied to the next one, testing, because each feature should be tried out as soon as it is built.
In MIT App Inventor, building happens in two views:
Thunkable and Kodular work in a similar way, with a design area and a blocks area.
Most apps are event-driven: they sit and wait until something happens, and then they respond. An event can be a tap on a button, text being typed, or a screen opening. In App Inventor an event block looks like "when Button1.Click do": the blocks placed inside it run only when Button1 is tapped. The block "when Screen1.Initialize do" runs once when the app starts, which is useful for setting a score to 0 or showing a welcome message.
Logic decides how the app behaves in different situations. In a quiz app, the blocks for the Check button could say: when CheckButton is clicked, if the text in AnswerBox equals "New Delhi", set ResultLabel to "Correct! Well done.", and otherwise set it to "Try again." The same logic written in Python, the language used in the programming chapter, looks like this:
def check_answer(answer):
if answer == "New Delhi":
return "Correct! Well done."
else:
return "Try again."
print(check_answer("New Delhi"))
print(check_answer("Mumbai"))It prints "Correct! Well done." for the right answer and "Try again." for a wrong one. Blocks and text code express the same ideas; blocks simply let you build them by dragging instead of typing.
Block-based tools are ideal for beginners: blocks only fit together in allowed ways, so typing and spelling errors in code are avoided, and you can see the structure of the logic. Professional developers usually write apps in text languages, such as Kotlin or Java for Android and Swift for iPhones, which give more control. The thinking, however, is the same: events, variables, conditions and step-by-step instructions.