Creating a Java-based Android Application for a Museum

Overview

While volunteering at the Revs Institute, (a noted collection of classic cars) museum in Naples, Florida, I developed an Android-based tablet application for fellow volunteers. The application is designed to present information about the Collier Collections of automobiles housed in the museum. There are over 120 vehicles in the collections and extensive documentation for each vehicle is presented in the application. Some of the details of the design of the application are documented here.

The objective of the project was to create a small, portable reference device that could be carried by volunteers while working in the galleries and discussing the collection with visitors.

While this particular implementation was specific to a car collection, the general idea could be extended to any organization that wants to have a portable, organized way of viewing its assets.

This photo represents the overall appearance of the application, which has been dubbed "CarPad" (apologies to iPad). The user can use gestures to navigate the screen. One gesture is to touch the screen and "fling" upwards, causing the list of cars to scroll up. The entire collection, consisting of over 150 items (cars and engines), can be scanned with one or two of these gestures.

Touching one of the large down arrows causes that particular car section to expand, revealing details about the car (or engine), along with additional buttons which will expose more resources for the item. These include links to a photo gallery, engine and dash pictures, articles about the car, and links to the car's pages on the Revs website and the Revs visitor's app.

Initially, the order in which the cars are listed follows the volunteers' station naming convention: the stations are numbered 1 through 10, with cars in the shop or out for long-term restoration designated as station 11. In addition, the cars are listed within a station according to "sight lines" within a gallery.

The sort order can be changed by touching the control at the upper right. This exposes a drop-down menu of sort choices such as cars by manufacturer, oldest to newest (and the reverse), and the ability to skip directly to any station. This will position the display so that the first car in a station appears at the top of the list.

At the upper left is another menu icon which when touched exposes a list of useful information which is not specific to any one vehicle. These are collections of documents such as People, Places, and Technology, as well as information the volunteers find useful for research such as our Tappet Clatter Archives and training materials.

Further details are mentioned in the following sections.

Background

I created an initial prototype using a display format with collapsible/expandable information "bars" for each vehicle, along with a thumbnail image of each car. As mentioned, the display was scrollable so that a summary of the entire collection could be viewed with a couple of up/down swipe gestures. Touching the down arrow next to any car's name expanded a section for that car, showing facts about the car, along with buttons linking to additional information such as pictures and documents about the car. Also, a menu was added with additional sections for general information in several categories. This concept resonated with people who saw the prototype, so I embarked on a full-blown development project. The intent of the initial display as a list of all the cars reflected our desire to make the application car-centric since that is the focus of the volunteer Station Guides within the galleries.

Development

We wanted to have a small tablet that was easily portable and able to fit in a pants pocket. We eventually chose a cost-effective (~$100) Samsung 7" device and I began the software creation, using the initial display concept as the starting point. I wrote the software in Java since that is the native programming language for Android. The primary coding tool used is Android Studio. The code eventually grew to 19 Java modules (or "classes" in programmer-speak) and several thousand lines of code. There are other frameworks available to make development easier, but they were too limited in flexibility to do what I wanted. I also avoided Kotlin (despite Google's efforts to convince developers to use it) due to the learning curve. I had some ancient Java knowledge that I dusted off and went to work.

The view of the modules in Android Studio looks like this. A detailed description of each of these is out of scope for this discussion, but several features should be noted. The module labeled MainActivity is the starting point of the app. This module presents the initial screen to the user and handles all events related to touches on that screen. During a cold start or boot of the device, MainActivity initializes the app by downloading the JSON file described below. Network communication is handled by an Android library known as Volley.

The RecyclerView Android library is what enables a scrolling display window of all cars.

Thumbnail images are pulled down gradually using a library called "Glide" to be network-friendly. From a cold start, thumbnails are pulled down as the user scrolls through the car list but are then cached for the lifetime of the app.

Formatting of the displays is handled by XML files within Android Studio using files in the "res" directory.

The details for each car are handled by the CarAdapter module which, when a user expands a car by touching the down arrow on the right side of the display list, displays car facts and buttons within the RecyclerView for a single car. This detailed display of a car's info is handled by a class within the CarApapter called CarViewHolder. Since the details for each car are already in memory, the expanded display happens very quickly, although a brief animation event gives the appearance of a slightly delayed smooth reveal.

Depending and what the user intends, other modules are invoked to display the desired information. Some utilities handle the initialization of the app, loading information and data, communications over WiFi (Volley), and image display (the "Gallery" modules). Also, we decided the app should run in "kiosk" mode, which means that it starts up automatically and cannot be exited easily. Several routines handle that functionality.

Many of these modules were adapted from open-source examples and modified for CarPad-specific functions.

Architecture

Since the idea of the app was to make it car-centric, we needed a way to organize the data for the cars in a logical fashion. A database was ruled out since it would require database-specific knowledge for maintenance. Instead, I settled on a text-based format in JSON (JavaScript Object Notation), now widely used in network applications. It consists of "tags" and data, or name-value pairs. We store this as one large file in GitHub. Some of the values are actual content, while others (such as photo data) are stored as URL links to other resources. When the application is started on a tablet, this file is downloaded to the device. Before the download, the app is essentially content-free, so the JSON file acts as a master configuration file.

Each section of name-value pairs within the JSON file is repeated for each car. As cars are added (or removed) from the collection, this file must be edited. GitHub supports online editing but this must be done carefully since an errant character could prevent the file from being parsed correctly by the app. The exact order of the car sections is unimportant since the app sorts the cars based on metadata, such as volunteer station, year, make, etc. The default sort (upon app startup) is to list the cars by station number in ascending order. In addition, the cars are listed in order of "sight lines" within a particular gallery.

In addition to the sorting options, users can scroll the display directly to any station such that the first car within that station appears at or near the top of the screen.

Some entries in the JSON file are URL links that point to external web resources, such as the car's corresponding web page on the Revs website or the embedded OnCell resources for images, video, and 3D content displayed in the Revs visitors' app, which is available for anyone to download.

Additional content pointed to by some URL links is housed on the Revs' Box.com repository, organized into folders. Since the institute already had an enterprise-level Box.com account, it was a logical place to store the working set of all this additional content.

There is a second level of redirection that occurs for some links. These second-level links point to additional small JSON files stored in Box (in the respective car folders) which the app can interpret as pointers to collections of images (for example pictures of a car's dash) which it will display in a "gallery" of small thumbnails. When a user touches one of these, it will expand to full screen and can be zoomed and panned with fingertip gestures.

}

The links to files within Box.com are generated by a Box command and can then be copied into the proper JSON file. These links are persistent.

Box.com Folder Structure

We wanted to create a taxonomy (that is, a logical structure) for organizing the information for the cars. We settled on a folder structure in Box.com to line up with this taxonomy. At the top level, each car has its own folder. Under those top-level folders are sub-folders (and sub-sub folders in some cases) with additional information about each car. This also allows the information to be browsed in a read-only fashion from the Box web interface (from a copy of the "working" folder structure) without the need to use the CarPad app, so volunteers can look at the CarPad data from home.

Here are a few car folders in the Box.com viewer. Note that Box keeps track of the last edits to a particular folder. This is handy for the rest of the team to see who has done something to the folder and when (not necessarily what).

Inside each car folder are sub-folders with content for that car. In addition, there is a thumbnail that the app displays in the main screen along with the car's metadata from the JSON file. The Dash and Engine folder has interior photos. The Photos folder is for exterior or in-period race photos. Currently, we have not implemented Videos. The Car Facts text file is included as a reference; it is simply a copy of the list of facts in the JSON file.

Within the Articles folder are additional sub-folders for Adopt a Car, History, Tappet Clatter articles and Training Materials. When new documents become available, they can be dropped into these folders and will be displayed by the app.

Auxiliary Menu

In addition to the sort/scroll-to menu at the top right of the display, I created an auxiliary menu (at the top left of the main screen) to provide access to additional information. In general, these are simply URL links to either Box folders, individual documents stored in Box, or external web links. These open in an Android browser and the contents are displayed as they would be in any other browser. The formatting of the display is up to the source website. For example, Box will display a list of folders or its preview function for files.

Adding content to any of the Box resources is simply a matter of adding files in the appropriate folder. For example, if a new Tappet Clatter is available, the file simply needs to be dropped into the "Tappet Clatter - Past Issues by Year" folder on Box and it will appear when a user selects that menu option. Note to coding critics: these links are hardwired into the app, which is a horrible coding practice. This was done strictly for expediency to get the app out the door and changing it at this point would be a major pain.

When the user exits out of one of these browser sessions, cached data is released so that other users of the CarPad do not see any history information stored in the Android browser, for example, login credentials for Volgistics.

Project Team

While I developed the software, I was supported by a team of folks who worked on content. Without them, the application would not have been useful.

Current and Future Work

A new tablet was phased in for replacement of the Samsungs. Samsung is no longer making a 7" tablet and the hardware is becoming obsolete. 10 new Lenovo Tab M7 Gen 3 tablets were purchased to replace the Samsungs in early 2022. These were numbered 1-10. In late 2023, Lenovo discontinued their 7" tablet so we are currently (Nov 2023) evaluating the 8" Lenovo Tab M8, Gen 4.

Page updated

Google Sites

Report abuse