The Hunt For Broken Arrow
As the end of our foundations year at Holberton approaches, we were given the task of completing an MVP. Our project aimed to replace the worksheets currently given to guests visiting The Museum Broken Arrow, with an Android application that would be loaded on several tablets the museum has recently acquired. Our team members are Ashley Price, Ben Dosch, Ryan Devlin, and Selidex Parnell. Our primary goals were to create a functional trivia application for guests to the museum, create a simple user interface for the museum administration to be able to update the content of the application, and maintain application security. I worked on the front-end of the application and landing page. Ben and Ryan worked on the back-end of the application, and Selidex worked on research and development.
Ryan Devlin initially connected with the museum, and learned that they wanted to replace their worksheets with an android application. The majority of my family has been in Northeastern Oklahoma since the 1830’s, and so I am very interested in local and tribal history, and have spent many hours in my personal time researching the history of Northeast Oklahoma, as well as my family history. So when Ryan suggested the project, I thought it would be a great way to combine my love for history with my interest in web development. Ryan shared the existing worksheets with us, and I was especially impressed that the museum included questions specific to the Muscogee Creek Nation. I am not Muscogee, but living the majority of my life within the (recently affirmed) tribal reservation and working for the Muscogee Creek Nation previously, I am familiar with some aspects. Also because of our shared history, things like the game of stickball, can also be appreciated by this Cherokee Nation citizen. It isn’t very often a non-Native organization will think to include information about tribal foods and culture, but this museum did.
One of our main goals, was to make all aspects of the application as user-friendly as possible. We wanted to make sure the museum staff was able to easily change and update the application whenever it was convenient for them. This meant creating a graphical user interface specifically for the museum staff to use. To achieve this, I ensured the font and buttons were large enough to read, and simple enough to understand what was needed. To make sure the staff was able to update all devices running the application, we used Firebase.
From the admin panel, the user can select either Trivia or Scavenger Hunt. In the Trivia screen, the user can select various icons to edit, delete, or create new questions. Once the change has been made and saved, the Firebase receives the new data, and sends it to the other devices running the application. The new data is reflected in realtime.
The majority of the application was built using Kotlin. This language was chosen because the application only needed to be run on Android devices, and Google has adopted Kotlin as the preferred language for Android development. We used XML to build the font-end because it is native to the Android Studio environment, and is very lightweight. We used Android Studio as our IDE, due to it’s native support of Kotlin and Firebase. And finally we used Firebase to support the back end of the application, because it is a Json tree NO-SQL database, has cloud storage, realtime update capabilities, and is cost effective for the museum’s purposes.
Some of the application’s key features include:
It is mobile responsive. Although the application was specifically designed for the tablets the museum currently owns, the application will work on Android devices of all sizes, including phones.
Question data updates in real time. This means the museum staff can update the trivia quickly and efficiently for museum visitors.
Admin features are locked behind a password. This prevents visitors from also accessing question data and corrupting the data.
One of the most important decisions we had to make early on in the project, was how the layout would be arranged in the application. It was easy to agree that using the Constraint layout would enable the application to be responsive to different sized devices. However, we still had to decide on the rest of the layout. We found that the RecyclerView would meet our needs, and was a new view to Android Studio, so it had current documentation available. RecyclerView is a ViewGroup in Android Studio that was implemented to replace the GridView and ListView.
Originally I had wanted to implement a flexbox in the scavenger hunt portion of the application. I thought it would be a great way to use the space available, since the pictures were all different sizes. I followed this tutorial, but unfortunately most of it is already deprecated and it became too much of a burden to update. Ultimately we pivoted to using a series of fragments and recyclerviews. This allowed us to have individual items to organize views like the trivia list. We also opted to organize the scavenger hunt into a table format, with the image, description, and a toggle switch in separate columns.
I learned so much in the course of this project. Before starting this project I had never seen or used Kotlin, Android Studio or Firebase. I had very minimal experience with XML, and ended up enjoying using it very much. While XML is a markup language like HTML and CSS, (which I have used quite a lot) that is where the similarities end. I found it to be very organized, and love how efficient it is to update your layouts. There is a learning curve with Android Studio of course, and I still do not enjoy WYSIWYG editors, (I also prefer driving a manual transmission, so there’s that) but having that feature available was definitely an asset to our team. The one thing I would change, is I would have a device available for testing. While Android Studio does have an emulator, we ultimately found that the sizing is a little different on the actual device than what it looks like on the emulator. For example, the text size on the emulator looks fine, but on the actual tablet it appears much bigger and is actually too big in my opinion. I would also like to make the application using React, instead of Kotlin. For the scope of the project it made sense to focus on building for Android, but in the long run it would be better if the application was also compatible with ios devices. On a more personal level, this project certainly confirmed for me that I prefer and enjoy front end development. I have enjoyed some back end development as well, but front end is more interesting to me. I am the person who enjoys getting the button in exactly the right position, with the perfect color and font. I think everyone on our team had similar affirming moments during this project, which is a really validating feeling. There were some people on our team who were undecided on their specialization prior to this project, and this definitely helped narrow down or confirm their choices. Another thing we all really enjoyed about this project, was being able to freely break and explore the code, and not be bound by the rules of The Checker. This was a project I think all teams thoroughly enjoyed, and think we all ended Foundations on a resoundingly positive note.
I am Ashley Price, a student at Holberton Tulsa. I will be entering the Full Stack Web Development specialization. Linkedin, The Hunt for Broken Arrow (landing page/Github).
