This chapter is from the book
This chapter is from the book
This chapter is from the book
Getting Inside an App
Apps have an internal design, the programming that works with the user interface. Effective programming entails knowing how to use the internal components to effectively implement what is visible to the user.
A good way to think about the internal pieces of an app is to focus on components and actions. The components are the various tools you find in App Inventor to create tasks. Think about the Design Editor and all the onscreen tools: buttons, images, drawings, and so on. In the Design Editor, you pull into your app all the pieces that make up the user interface, or what the users of your app will see on the device’s screen.
Event Handlers
All of your blocks, the pieces that make your app perform tasks, will be connected with an event handler. Events are created whenever something in the real world happens to the app, such as when the user clicks a button, the phone’s location changes, or the phone receives a text message. Blocks exist for just about everything you want to do in an app; taking a picture, checking the GPS location, displaying text, changing the color of a component, finding out what the user entered into a text box, and so on. You can add (or remove) these blocks from an event handler, allowing the programming to determine the precise set of actions to take when the user presses a button.
When any event happens, App Inventor runs whatever blocks are inside the event handler block for that event. For example, Figure 2.12 shows a button labeled Speak; the block when Speak.Click do is the event handler for when that button is clicked.
)
Figure 2.12 An event handler in the Blocks Editor.
Imagine that we wanted to write an app to speak written text. We would need a button to start the process. To do this, we would have to drag the action block into the event handler. Whenever the button is clicked, that block will be called, and the device will move to whatever blocks have been placed inside the event handler. The event handler will grow and shrink as needed to accommodate whatever blocks are placed inside it (in Figure 2.13, this involves speaking some text). The way it is right now, however, the app has a button and a text-to-speech component, but it won’t do anything because the event handler is empty. After we drag in some action blocks, it will do those actions whenever the button is clicked. Note that the component used to initiate the action (such as a button) is usually different than the component that does the requested action (such as taking a picture or sending a text message).
){kind=link}
Figure 2.13 An event handler.
Doing One Thing at a Time
Modern smartphone applications perform a large number of tasks simultaneously—or at least appear to do so. All computers, including smartphones, are so good at switching between different tasks so quickly that it appears they are doing two unrelated things simultaneously.
Many computers have multiple cores, or processing units. These computers really can do more than one thing because each core can work on a separate task. But those cores are also switching very quickly between many tasks that the system and user are trying to do. You might have two, or four, or even more separate cores in your computer or phone, but between the operating system and the apps, the processor has hundreds of small tasks to work on.
Most of the things you will do in App Inventor are single task, meaning that only one task is actually running at a time. However, they can happen quickly and get out of the way for other things to run. In the code blocks, only one event handler can run at a time. So when an event happens and the event handler begins executing the blocks you put in it, all other event handlers must wait until this one is done.
Events that take place while a handler is already running are put in a queue and will run when it is their turn. Most event handlers run much faster than events are generated, so this is often not an issue. The most common actions, such as updating the text in a label or looking at the state of a check box, occur nearly instantly. However, other actions, such as working through a large collection of data, might take a long time, and the app will appear frozen until the process finishes.
While an event handler is running, the display isn’t updated. Again, this isn’t an issue most of the time, but if you have an event handler that is taking long enough for a user to notice, the display will appear frozen until the event handler is complete.
You might notice that some features in App Inventor take time, such as playing sounds or music. Other features have to wait for something on the Internet to respond, which can cause an unpredictable amount of delay time. But the display doesn’t freeze when you play music, and the app continues to work while waiting for a web page to load. Android provides the means to allow some tasks, such as playing music, to run in the background without disrupting the normal actions your app performs. Android provides other means of dealing with actions that could take a long time, or that might never finish, such as loading a web page or waiting for the user to take a picture, without affecting the normal functioning of your app. The actions for music and sound are made possible by the Android system. Your app simply hands off the sound file to the phone’s operating system and tells the phone to handle it. The music plays while the app continues to work.
Later in the text, we provide more details on how App Inventor switches tasks. You can use that knowledge to make better apps.