Building an Android App to Manage Your Parts Collection

by | Mar 22, 2018 | Android | 0 comments

If you are a Maker like me, you probably have a big pile of hardware somewhere in your workshop: screws, nuts, bearings, electrical components, maybe some development boards. With each new project, more parts are added to what is more than likely a fairly disorganized stash of metal and silicon. In my own workshop I had a giant cardboard box filled with bags of parts and components. Finding any specific part was a daunting task involving wading through the box and passing by hundreds of other parts until I found the part I was seeking.

[picture of parts box]Maybe your collection of hardware is more organized than mine was; but do you know how many of each part you have without having to count and recount your parts over and over? If you take on a new project and find out you will need 24 M3 x 12mm screws, how would you know if you had enough or needed to order more? How much money have you wasted over the years ordering parts you already had on hand only to end up with four times the quantity you needed in the first place?

I decided to create an Android app to help me keep track of all my parts. This way, when I take on a new project, I can simply search in the application to check what parts I already have, and how many of each part. The application is called Stacks and this post is about how the app is designed. I am by no means a professional programmer, but it is still my hope that this retrospective provides useful information for others designing similar, or not so similar, apps of their own.

Finished App Preview


Whenever I start any kind of project, whether it is a coding project, written project, or a build of some kind, I like to roughly plan out the project first. When designing an Android app specifically, I think it is very important to plan out the flow of the app before you ever open Android Studio, in terms of the way the user will navigate the app. Creating an intuitive organization for the app is critically important because if your information architecture confuses your users, you will not keep any users for long.

I don’t use any sophisticated tools when planning out my projects. I mostly work with pen and paper, sketching out layouts, activities, using arrows for navigation, and adding notes.

As you can see from the image, the planning process does not stop when the coding starts. I continue to take notes and modify my sketches throughout the project. The other thing about planning projects is that it needn’t take a long time. Planning is mostly about thinking through the high-level details of the project in order to get a basic road map to stay on task while working out all the fine details in code.


Stacks is ostensibly a database management app. All of the information about the user’s collection of parts in Stacks, and all the actions taken by the user while using the application are driven by two databases. The first database stores the part data. Every part in the user’s collection is a row in the parts database.

ID Name Category Quantity
 1  part name 1  category 1  12
 2  part name 2  category 1  45
 3  part name 3  category 3  6
 4  part name 4  category 2  34
 5  part name 5  category 2  16

So, any time the user is looking at a part, adding a part, looking at a category, doing a search, or really any other activity in the Stacks application, they are interacting with the parts database.

A second database is used to store information about the categories.

ID Name Image
1  category 1 imagename.png
2  category 2 imagename.png
3 category 3 imagename.png

The Database Handler Functions

If the databases themselves are a kind of skeleton for the Stacks application, then the app’s brain is a pair of Java classes for handling interactions between the user interface and the databases. None of the user-facing activities interact directly with the database, rather, the UI activities use methods from database handler classes, and the handler classes run queries on the databases. This pattern complies with the Model-View-Controller architecture and it allows the UI components of the app to be developed and modified without changing the databases themselves, by using the same set of methods from the handler classes.

The database handler classes both have a similar structure. Their first responsibility is to create the parts and categories tables when the app is initially installed and launched, or if the user chooses to delete all the parts from their collection and start again from scratch. Stacks uses SQLite databases. Therefore, the part database handler and the category database handler classes utilize SQLite queries to create the tables in the database.

After the database tables are created, following the structure outlined earlier in this post, the real work of the database handler classes begins. Each class contains a set of Create, Retreive, Update, Delete (CRUD) operation methods. It is these CRUD methods that allow the user-facing activities in the app to interact with the database. Some of these methods are very simple, for example, the parts database handler class contains a method to add a new part to the parts table.

There are methods for deleting a part, adding a category, updating a part or category, and retrieving parts and categories. These are straightforward CRUD methods used throughout the Stash app. There are also a few higher-level methods used for convenience. For example, the parts database handler class has a method for getting a list of parts in a given category. It would certainly be possible to use the basic CRUD methods to obtain this list, but it would require additional logic in the user interface activity. The higher-level CRUD methods are included for simplicity.

The Stacks application uses database handler functions for both the database containing the users parts collection and the database containing information about the part categories.

The Main Activity

So, two database handler classes and two databases run in the background of the Stacks application. Thanks to the database handler classes, the user-facing activities are relatively simple. The first of the app’s activities is the category view presented to the user when the application initially launches.

This activity uses fragments to create a flexible layout, a mechanism used by many of the activities in the Stacks application. The activity first checks how many categories exist. Depending upon how many categories are in the users’s collection, the activity will display different fragments. The activity can load special fragments for collections with zero or one categories, but these fragments are likely to be used only when a user runs the Stacks app for the first time, or is just beginning to use the app. Most of the time, the category will display a fragment that builds rows of category images.

The fragment itself consists of two image buttons in a horizontal row. As shown in the code above, the main activity will load multiple instances of the fragment depending upon how many categories exist in the user’s collection. The fragment itself takes two category names and two category names as parameters and uses this information to populate the image buttons.

Then, when a user clicks one of the category image button, the app starts an activity for displaying the parts in that category.

The Category Activity

When the user selects the name of a category from the main activity, the Stacks app will start an activity for displaying the parts in that category. First, the name of the category selected by the user is passed as an intent to the category activity. Second, the category activity uses a method in the parts database handler method to get a list of all the parts in the selected category. Third, to display the list of parts to the user, the activity uses a custom array adapter.

The custom array adapter is used several times throughout the app. It is the same array adapter used by the search activity. The custom list item created by the adapter consists of a Constraint Layout which includes a Text View for the name of a part, another Text View for the quantity of the part, and two buttons, one for increasing the quantity of the part and one for decreasing the quantity.

The category activity loops through the list of parts in the category selected by the user and passes each part into the array adapter to populate a List View that is the only element used in the layout file for the category activity.

Adding Parts

Of course, the Stacks application would do nothing if it did not have a way for users to enter parts into their collections. Because adding parts is an important function for the app, from any activity in the app, the activity for adding parts can be accessed from a plus icon in the Toolbar. The activity for adding parts consists of several Edit Text elements: one for the part name, one for the part category, and one for the initial part quantity. At the bottom of the activity is a button for saving the part, and the category, if it is a new one, to the databases using functions provided by the database handler classes.

Several actions occur when the user presses the save button. First, the activity checks to make sure a part with the same name is not already in the database. This check consists of simply calling a method from the parts database handler class that returns null if a result is not returned. Therefore, if the call does not return null, a part with the name entered already exists in the database so the app presents a dialog. The dialog gives the user the option to view the page for that part, or cancel adding the part.

After checking that the part entered does not already exist in the database, the next check is to see if the category exists. This is done similarly to checking the part, by simply using methods from the category database handler class. If the category exists, the activity simply proceeds to add the part to that category in the database. However, if the category does not exist, the user is presented with a dialog box asking if the category should be added or not.

If the user chooses to add the part to the database, the next prompt is to select an image for the category. It is this image that is used in the main activity.

Finally, when the part and/or category is added to the database, the action is confirmed with a Toast message.

Your doorbell will ring on your phone.

Introducing Wello, a connected doorbell that will send notifications to your phone so that, wherever you are in your house, or if you are wearing headphones, or if you are in the backyard, you will never miss your doorbell ringing.

Simply sign up below to find out when you can get Wello at a special discounted price on Kickstarter. For more information, check out Wello's Kickstarter preview page.