1. Engineering and Debugging an App Chapter 15
AppInventor
Engineering and Debugging an App
Chapter 15

2. Adapted from intro to Chapter 15
Apps covered in this book’s early chapters are small software projects and don’t require much engineering.  As projects become more complicated, you’ll realize that the difficulty of building software increases rapidly for each bit of complexity you add--it is nowhere close to a linear relationship. To build even moderately complex software you need forethought, planning, blueprints, user and system testing, and, in general, techniques and skills that are more engineering than programming. For most of us, it takes a few hard knocks before we realize this fact. At that point, you’ll be ready to learn some software engineering principles and debugging techniques. If you’re already at that point, or if you’re one of those few people who want to learn a few techniques in the hope of avoiding some of those growing pains, this chapter is for you.

3. Software Engineering Principles
Involve end-users early and often
Build simple prototype early
Add incrementally to prototype
Code/test incrementally
Design logic for app BEFORE coding
Divide, layer, conquer
Comment as much as possible
Trace blocks with pencil/paper to understand program execution

4. Design for Real People with Real Problems
User-centered design
What percentage of programs see ‘light of day’?
A program often begins life as a solution to one person’s particular ‘pain point’ and then evolves to a larger, more general app

5. Build a Quick Prototype
Something that illustrates core functionality
Not refined, but gives rough idea
Listen, listen, listen!!!

6. Incremental Development
Big Bang: create 30 blocks of code, debug ‘em, run … not a good plan
Code a little, test a little, repeat … much better plan

7. Design Before Coding Understand the logic of the app FIRST
TRANSLATE into code SECOND
Get AWAY from the computer to think about your app
Document your design ideas
Write them into your code screen as comments
Importance of commenting code

8. Divide, Layer, Conquer Divide project into manageable chunks: A, B, C
Layer: break into simple to complex layers
Add blocks for simple behavior
Test
Add another layer of complexity
Understand what it is to WRITE a program; what it is to RUN a program
Read closely: First 3 paragraphs under ‘Understand Your Language: Tracking with Pen and Paper’
Tracing execution – example of p232

9. Tracing Execution – an example

10. Tracing execution, another example . . .
First, draw some memory cell boxes for all pertinent variables:
QuestionLabel.Text
currentQuestionIndex

11. Tracing execution, another example . . .
Next, think about what happens when the app begins, not from the end user’s perspective, but what happens internally in the program
All the component properties are set based on their initial values in the Component Designer.
All variable definitions and initializations are performed.
The blocks in the Screen.Initialize event handler are performed.

12. Tracing execution, another example . . .
As a result of the Screen1.Initialize here’s what the memory cells contain:
QuestionLabel.Text
currentQuestionIndex
Which president implemented the “New Deal” during the Great Depression? 1

13. Next, trace what happens when the user clicks the ‘Next’ button:
First, the currentQuestionIndex is incremented. At an even more detailed level, the current value of the variable (1) is added to 1, and the result (2) is placed in currentQuestionIndex. The if statement is false because the value of currentQuestionIndex (2) is less than the length of QuestionList (3). 

14. So, now the memory cells contain . . .
QuestionLabel.Text
currentQuestionIndex
Which president granted communist China formal recognition in 1979? 2
Trace the ‘Next’ button logic through a second time. What happens with the ‘if’ statement? Why?
We’ve uncovered a ‘bug’ in the program! The last question in the list never appears – it goes back to the first question after the second question is done. How can we fix it?

15. Tracing code . . . Adapted from Ch15
When you can trace an app to this level of detail, you become a programmer, an engineer. You begin to understand the mechanics of the programming language, absorbing sentences and words in the code instead of vaguely grasping paragraphs. Yes, the programming language is complex, but each “word” has a definite and straight-forward interpretation by the machine. If you understand how each block maps to some variable or property changing, you can figure out how to write or fix your app. You realize that you are in complete control.
Now if you tell your friends, “I’m learning how to let a user click a Next button to get to the next question; it’s really tough,” they’d think you were crazy. But such programming is very difficult, not because the concepts are so complex, but because you have to slow down your brain to figure out how it, or a computer, processes each and every step, including those things your brain does subconsciously.

16. Debugging an App
Trace
Watch variables – RC any variable def block – choose Watch
Test individual blocks – RC block, choose DoIt
Can be used not only to test individual blocks but also to do incremental development
Activate/deactivate blocks – RC block, choose Activate/Deactivate

17. Summary … adapted from Ch15
App Inventor’s visual nature gets you started building an app right away, and you don’t have to worry about a lot of low-level details. But App Inventor CANNOT figure out what your app should do for you, much less exactly how to do it. Though it’s tempting to just jump right into the Designer and Blocks Editor and start building an app, it’s important to spend some time thinking about and planning in detail what exactly your app will do. It sounds a bit painful, but if you listen to your users, prototype, test, and trace the logic of your app, you’ll be building better apps in no time.