A mobile restaurant administration prototype that lets diners order from their table while staff manage the menu and orders in real time.
| Field | Details |
|---|---|
| Type | Android mobile app prototype |
| Context | University software design lab |
| Role | Solo developer |
| Year | 2019 |
| Status | Academic prototype |
| Main focus | Table-side ordering, live menu inventory, role-based admin flows, and Firebase-backed sync |
The Hungry App is an Android prototype for small restaurants that still rely on paper menus, manual order taking, and handwritten bills. I built it to explore how a single mobile client could serve both diners and staff: customers pick a table, browse a categorized menu, build an order, and review a bill; administrators sign in separately to inspect inventory and incoming orders.
The project was developed as coursework in software design laboratory, with formal requirements, use cases, and domain modeling alongside the implementation. It is a working prototype, not a production deployment, and it stays in my portfolio as an early example of end-to-end mobile product thinking backed by a real-time backend.
Many small food businesses still run service with static menus and manual coordination between the floor and the kitchen. That creates friction for customers who wait for staff to take orders, and for owners who struggle to keep menu data and sales records consistent.
I owned the project end to end: problem framing, requirements alignment, Android UI flows, Kotlin and Java application logic, Firebase Authentication and Realtime Database integration, and the documentation that accompanied the prototype. I modeled the domain, planned the client journeys, and wired each screen to shared data under a single restaurant tree in Firebase.
The app replaces part of the paper workflow with a connected mobile experience. After sign-up or login, customers reserve a table in the UI, browse dishes by category, add items with quantities, review totals with tax, and follow a simple checkout sequence. Administrators use a separate entry point to browse the full menu catalog and access order-related views intended for operational oversight.
New users register with name, contact details, and birth date. Firebase Auth creates the account, sends an email verification message, and writes profile fields under restaurant/users/{uid}.
auth.createUserWithEmailAndPassword(email, password)
.addOnCompleteListener(this) { task ->
if (task.isComplete) {
val user: FirebaseUser? = auth.currentUser
verifyEmail(user)
val userBD = dbReference.child(user?.uid!!)
userBD.child("name").setValue(name)
userBD.child("lastname").setValue(lastname)
// ...
}
}I kept authentication in Firebase Auth and profile details in Realtime Database so the app could evolve roles without mixing credentials with menu data.
After login, the app routes users by account. A dedicated admin email opens the administration activity; everyone else continues to table selection.
if (task.isSuccessful) {
val userid = FirebaseAuth.getInstance().currentUser?.uid as String
saveUserID(userid)
if (user == "support@thehungryapp.com") {
admin()
} else {
action()
}
}This is a simple prototype gate, not a full RBAC system, but it kept the two experiences separate without building a complex permissions layer for a classroom scope.
Menu fragments listen to restaurant/platillos and filter dishes by category so every client sees the same catalog as soon as data changes.
database.reference.child("restaurant").child("platillos")
.addValueEventListener(object : ValueEventListener {
override fun onDataChange(dataSnapshot: DataSnapshot) {
Food.removeAll(Food)
for (snapshot in dataSnapshot.children) {
val piece = snapshot.getValue(Classplatillo::class.java)
if (piece != null && piece.category == "entrada") {
Food.add(piece)
}
}
adapter.notifyDataSetChanged()
}
})I used ValueEventListener so the UI stayed reactive during demos when menu entries were added or edited in Firebase.
Each visit gets a generated order id stored in SharedPreferences. Items are written under restaurant/ordens/{ordenId}/platillos, and review screens aggregate quantity, prep time, subtotal, and tax.
val userBD = dbReference.child(ordenr)
userBD.child("id").setValue(ordenr)
userBD.child("userID").setValue(userID)
userBD.child("table").setValue(table)
val userBDF = userBD.child("platillos")
userBDF.child(idPlatillo).child("quantity").setValue(x)
userBDF.child(idPlatillo).child("name").setValue(textView.text)
userBDF.child(idPlatillo).child("cost").setValue(costi)The order model is flat and JSON-friendly, which matched Firebase Realtime Database strengths for a short academic timeline.
Administrators land in a drawer-based activity with sections for viewing platillos, reviewing orders, and adding dishes. The inventory list is fully wired to Firebase; some admin forms are layout-first placeholders that show where CRUD would continue.
The client targets Android API 28 with Kotlin activities and fragments, Java POJOs for Firebase deserialization, Android Support Library components, and Picasso for menu images. All remote state flows through Firebase Authentication and Firebase Realtime Database under a restaurant root with users, platillos, and ordens children.
Session context (user id, table number, active order id, estimated wait time) lives in SharedPreferences so screens can stay loosely coupled. The customer path moves from login to SelectActivity, into a tabbed menu with ViewPager fragments, through Platillo detail and OrdenRecycler review, then postOrden wait timing and closing screens. I added a debounced click helper to reduce double-submits on fast taps during demos.
fun View.setSafeOnClickListener(onSafeClick: (View) -> Unit) {
val safeClickListener = SafeClickListener { onSafeClick(it) }
setOnClickListener(safeClickListener)
}Non-functional goals from the design phase included fast registration, near-real-time data refresh, and a small install footprint on mid-range Android devices. The prototype includes default Espresso and JUnit scaffolding but does not implement a meaningful automated test suite. Backend deployment was limited to configuring Firebase for the app; there is no separate custom server.
I prioritized clarity for two distinct personas instead of one dense interface. Customers see table context at the top of the menu and a floating action button to jump to their order. Administrators get a navigation drawer that mirrors operational tasks: see the menu, inspect orders, add platillos.
Building The Hungry App taught me how product requirements translate into concrete mobile flows when the backend is a managed service instead of a custom API. I learned to keep session state explicit, to model restaurant data as a small set of Firebase trees, and to accept where prototypes should stop short of production payment and permissions.
restaurant/users/platillos/ordens tree that I could reason about during demos.This project is no longer maintained and should be understood as an academic prototype from 2019. I keep it in my portfolio because it shows how I approached a full mobile service design: from problem justification and use cases to a working Android client with live data. It was not released to app stores and was not validated with real restaurant operations.