Spring 2011

One of the distinguishing principles of computer science is its use
of various kinds of **abstraction**. Abstraction is the ability
to **filter out** information that is not necessary to a problem
and to **generalize** those details that are significant. For
example, if you are designing a kitchen, then a floor plan would be a
useful abstraction. It would focus on the dimensions of the appliances
(essential information) while filtering out their make and model.

One important form of abstraction is **procedural abstraction**.
We've already used procedures in App Inventor to break a problem into
parts and to **encapsulate** certain tasks that need to be
repeated. We will want to make more use of procedures now that our
apps are getting more complicated.

We have already used the following block to define procedures that
perform a sequence of actions but do not return a result:

We now want to learn to define and use procedures that do return
results. These are typically called **functions**. A function
is procedure that takes 0 or more arguments and returns a value.

The *sqrt* function takes one argument (here 100) and returns
the square root of its argument.
In this example, we are **calling** the *sqrt* function
and **passing** it the value 100. It will **return** the value
10, which we can then plug in to any slot that takes a value -- e.g.,
into a text box or into a math expression.

App Inventor gives us the ability to write our own functions using the **procedureWithResult**
block. Note that it has an open slot for an **argument** and an open slot for a **result**
and a **body** where we can **do** a sequence of operations:

Here's an example in which we define a function that calculates the *square* of any number
and then we call the function and pass it the argument 10.

Note that calling our *square* function looks just the same (except for the colors) as
calling the *sqrt* function.

In this case the function is so simple that there is nothing to "do" other than perform the calculation and return the result. So we can just put our calculation in the return slot.

Of course, we wouldn't typically define a procedure for such a simple calculation. So let's look at a more likely example.

Suppose your app needs to caluculate the hypotenuse of a right triangle. You probably remember the Pythagorean Theorem from high school geometry -- i.e., the formula for calculating the length of the hypotenuse of a right triangle based on the lengths of its other two sides. The length of the hypotenuse is equal to the square root of the sum of the squares of the other two sides:

c = √a2+b2

Here's a function that will perform this calculation in App Inventor.

Here again, there is nothing to "do" besides perform the calculation so
we just return the result of calculating √
*a*2+
*b*2 .

Before you use your function in your app, you should test if. If
you **right-click** on a call to the function, you can test it using
App Inventor's **Do-it** option, as shown here:

When the *CalculateHypotenuse* button is clicked, the values
in the *aInput* and *bInput* text boxes are passed to
our *hypotenuse* function and its result is put in
the *Result* text box.

Then create a page on your portfolio, with commentary, to show your work.

- Calculate the conversion from temperature in fahrenheit to temperature in celsius using the formula: C = 5⁄9(F-32).
- Calculate the conversion from kilometers to miles using the formula: M = K × 0.62.
- (
**Challenging**) Write a function named*isOdd*that will return true if its argument is odd and false if it is even. HINT: A number is odd if it leaves a remainder of 1 after you divide it by 2. Even though it is not absolutely necessary to do so, you might want to use the**body**on this function to "do" an if-else. In that case you will need a global variable to temporarily store result that you want to return.