Solution architecture

For this list of features, we can have the following classes and relations between them to implement the requirements:

• AppAudio: Provides a simple interface for the audio functionality, consisting of the mute/unmute, Play/Pause, and volume up/down buttons. It initializes the audio sub-system and delivers audio events to its clients.
• AppButton: Handles user press events on the devkit buttons and notifies any client code via an event queue.
• AppNav: Keeps track of the animal list. It is the information source for the other components of the application, and it updates the current animal metadata when a user navigates by using the devkit buttons.
• AppUi: Encapsulates the generated UI files and manages the application flow for user interactions, by communicating with the other classes mentioned above.

The following class diagram roughly depicts how classes relate to each other:

Figure 5.4: Class diagram

The implementation will have more supporting fields and methods, for sure, but this diagram shows the classes, their main responsibilities, and the relationships between them. After the application starts and the initialization of the class instances is done, the AppUi instance takes control and begins to receive button events from the AppButton instance. According to the active functionality (playlist navigation or volume control), it commands the other class instances (AppNav or AppAudio). AppUi uses the generated UI elements to show the application state to the user. We will store the image files, sounds files, and a metadata file in the flash. AppNav will read the metadata file to populate the animal list and the multimedia files.

Now that we understand the solution architecture, we can implement the application.