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

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.

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

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

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

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

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

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

Tracing Execution – an example

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

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.

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

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). 

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?

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.

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

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.