Chapter 5. Managing Interactions with Physical Components
Electronic devices have changed our life. We are surrounded by quite a few invisible objects that collect and eventually compute environment data. Like we saw in the previous chapter, these devices use sensors to retrieve information and we can find them in our everyday life, for example, in our car, when we're walking through supermarkets' sliding doors, and maybe when we're coming back to home.
We can inspire ourselves looking at these things and build amazing physical applications that are capable of reacting to the environment and, indirectly, to the people around. However, if our project expects a direct human interaction, we may need to manage this interaction with physical components.
The goal of this chapter is to build a web radio that uses built-in Android APIs to manage Internet streams, while all interactions are managed by physical components, such as in the old fashioned radios.
In this chapter, we will cover the following...
Managing user interactions
One aspect that distinguishes an interactive prototype is the capability to react to any action made by users. As we've seen in the previous chapter, sensors are one of the most important building blocks to achieve this important goal. However, sometimes, we want to provide a physical interaction where users are capable of altering the application's behavior with their hands, despite the presence of sensors. These parts that are still largely diffused, are simple mechanic or electronic components that convert analog movements into digital values that our microcontroller can use to alter the program flow. There are a lot of components that we may use to interact with our device: push buttons, switch buttons, joysticks, knobs, pedals, and levers, are just examples of these kind of components.
Knobs are components that we can use to alter some prototype configurations. Indeed, we may create a maintenance console that alters some device constants to prevent the recompilation...
Building a web radio with physical interaction
Microcontrollers aren't designed for complicated work, so we need to be careful to partition the needs of our project to the right environments. For a web radio, we can use the microcontroller to read the knobs and switches, and let the Android APIs and UDOO's powerful CPU do the rest. This will keep Android from getting distracted while reading the hardware, and will prevent the microcontroller from getting overloaded with the complications of network streaming and playback.
The first part of our prototype is to build a circuit and write a sketch that collects values from two potentiometers and a push button:
In this way, we're removing all interactions done through the Android user interface.
As the first step, grab two potentiometers and connect them to the board so that we can...
Streaming audio from Android applications
The Android operating system provides a great collection of UI components, an important building block for all physical applications. All of them are specific for phone or tablet interaction and this is an outstanding improvement because users already know how to use them. However, Android isn't just a collection of UI components because it allows many APIs to achieve recurring tasks. In our case, we want a physical application that is capable of interacting with a web service to open and reproduce an audio stream.
Without the i.MX6 processor and the Android operating system, this task will never be easy to implement, but in our case, UDOO board provides all that we need.
Designing the Android user interface
From Android Studio, start a new application called WebRadio with Android API 19. During the bootstrap process, choose a Blank Activity named Radio.
Our first goal is to change the default layout in favor of a simple but fancy interface. The main...
Before we go further with other prototypes, we should think about how we can improve our devices when some unexpected events occur. A good starting point is to think about error handling and, in particular, what happens if the Android application stops hearing incoming data from the accessory. There are many approaches to prevent wrong actions and a good solution is to include a default behavior in the Android application that the prototype should follow in these emergency cases.
We could have used another periodic timer that increases a variable every time it gets executed. When the InputThread instance completes a successful reading, it should reset the above variable. In this way, we can monitor for how much time we stop receiving user inputs and according to this time, we may decide to change the application's behavior. Through this variable, for example, we could stop the radio playback, or turn down the volume a little bit if the accessory stops providing user...
In this chapter, you learned how to improve the quality of our prototypes when human interaction is required. We explored some of the common physical components that can be used to alter or control Android applications. Through powerful Android APIs, we built a web radio capable of complex tasks like network streaming.
In the first part, we built the required circuit using two potentiometers and a push button. When we checked returned values through the serial monitor, we saw that they are not so useful in this format, so we wrote a mapping and a normalization functions.
We continued providing a new layout for the Android application, but we avoided adding any kind of interaction through the user interface. We wrote a class to abstract all possible interactions with the built-in media player, so that we can easily control this component in any part of our application. Indeed, we used it within the background task, and every time it read user inputs, it immediately changed the state...
