AuctionApp

AuctionApp lets people post used items for auction from their phone and watch other people's bids update live. It was our mobile development course (MOB3000), and we got an A.

Problem

The case was individuals and organisations who want to sell or bid on used items from their phone, without having to gather in one physical place. That means more bidders and a higher closing price, and it needs real-time updates and role-based access in the app. We were four on the team and built it as an Android app in Java.

Solution

Admins post products with photos, a starting bid and a deadline. Regular users browse the list and place bids, and the bids update across devices through Firebase Realtime Database which pushes changes straight to clients. When the deadline passes, ProductManager moves the auction from products to sold_products, and the highest bid wins. Admins get a dashboard with a "Current Bidding" tab and a "Purchased" tab, plus a CSV export of bid history. Firebase Authentication handles login and role checks.

My role was Database Engineer and Full Stack developer. I worked between backend and frontend, designed the Realtime Database schema (User Profiles, Auction Items, Bids, Admin Data) and worked on the CRUD operations across the activities. I led testing of user interaction and real-time bid updates, and handled code review on GitHub.

Decisions and reflection

Decisions I made

Firebase Realtime Database over Firestore. Both were in build.gradle. Realtime Database pushes changes straight to every client with no polling code, while Firestore has stronger queries. For a bid list that has to update immediately, the push was what mattered.

Tightened password and email rules. Firebase allows six characters and any email domain. We required Gmail and a password longer than eight characters after a security review. That meant the original test password "pass123" stopped working, so we updated the demo accounts to "pass12345" and noted it in the report.

When an auction expires, ProductManager moves it out of products and into a separate sold_products node. We considered a boolean on the same row with filtering in the listing, but that would only have made the main list longer for nothing. With a separate node, the admin's "Purchased" tab is a plain read of sold_products.

When I went to publish the repo for the portfolio, I considered cleaning up the duplication between BuyProductsActivity and BuyProductsActivityUser, moving logic out of the Activity classes, and adding tests. I landed on the more honest choice of leaving the code as shipped and writing a short README section about what I would change today.

Added .gitignore and google-services.json.example before publishing. The real google-services.json with the Firebase API key was sitting in the project, which is what the course asked for. In a public repo it doesn't fly. The example file shows the format without leaking credentials.

What I learned

The architecture is something I would do differently today. All the logic lives inside the Activity classes, with no ViewModel or Repository layer, so Firebase calls, validation and UI updates end up in the same file. BuyProductsActivity and BuyProductsActivityUser are about 80 percent identical. A thin repository layer between Firebase and the Activity would have helped, and the two Buy screens could have been collapsed into one Activity with a role check.

ProductActivity.uploadFile() fills a plain ArrayList from Firebase Storage callbacks. The callbacks can fire in a different order than the uploads started, so the order of images saved to the database is not guaranteed. It shows up on a slow connection, and it is a bug I did not catch before submission.

The real google-services.json with the API key was sitting in the repo at submission, which is what the course asked for. That worked under grading. Today I set up .gitignore before I make the first commit on a new repo.