Food Donation Pickup Android App for Restaurants and NGOs

Restaurants, hotels, caterers and event kitchens throw away edible surplus food daily, while NGOs running community kitchens and shelters nearby struggle to source affordable meals. The gap is coordination, not supply: surplus is perishable, time-boxed to a few hours and scattered across dozens of small donors, so phone-call and WhatsApp coordination collapses exactly when speed matters. A food-donation pickup app closes this gap. The moment surplus appears, the donor posts a listing — what the food is, how many servings or kilograms, vegetarian or not, how it is packed, and the pickup window. NGO volunteers see live listings on a map, claim a pickup so nobody double-books it, get an optimized multi-stop route, and confirm handover only after a food-safety checklist. Every completed pickup feeds a monthly impact report counting meals saved — the auditable numbers NGOs need for CSR partners. The project demonstrates two-sided marketplace design, role-based authentication, real-time sync, location services and push notifications in one Android build.

The app runs as a donor-to-volunteer pipeline on Firebase. A restaurant staff member signs in and receives the donor role; an NGO volunteer signs in and receives the NGO role — roles are Firebase custom claims assigned by a Cloud Function and enforced by Firestore security rules on every read and write. The donor posts a surplus listing with food details, quantity, veg/non-veg tag, packaging, photos and a pickup window; the write lands in Cloud Firestore with a GeoPoint and a server timestamp. A Cloud Function fans out FCM data messages to volunteers inside the notification radius while snapshot listeners render the listing live on their map. Claiming runs in a Firestore transaction that locks the listing to one volunteer and notifies the donor. The app sorts the volunteer's claims into a nearest-neighbor route, and at each stop the volunteer clears the five-point food-safety checklist, photographs the handover and marks it collected — feeding the monthly impact report.

1. Sign-in and role assignment: Firebase Authentication (phone or email); a Cloud Function sets the donor or NGO custom claim, and the client refreshes its ID token so the security rules take effect.
2. The donor posts a listing — food details, quantity, veg/non-veg tag, packaging state, photos compressed to 1 MB or less, and a pickup window — written to Firestore with a GeoPoint and server timestamp, queued offline if there is no connectivity.
3. Fan-out: a Cloud Function finds verified volunteers inside the notification radius and sends FCM data messages; snapshot listeners render the new listing live on the volunteer map within seconds.
4. Claim: the volunteer taps claim; a Firestore transaction locks the listing to that volunteer so concurrent claims cannot double-book it, and the donor receives an acceptance notification.
5. Route: the app orders the volunteer's claimed stops nearest-neighbor into one run, shows the approximate total distance, and hands each stop to navigation.
6. Handover: the volunteer works through the five-point food-safety checklist with the donor present — the confirm button stays disabled until every check passes — then photographs the handover and marks it collected.
7. Report: the completed handover moves to history and increments the meals-saved counters that aggregate into the monthly impact dashboard.

Tech stack:

• Kotlin · Android SDK
• Firebase Authentication
• Cloud Firestore
• Firebase Cloud Messaging
• Google Maps SDK
• Material 3 · Jetpack Compose
• Glide image loading
• Cloud Functions for Firebase

Three capabilities carry this project. First, true two-sided flows: a donor flow for posting and managing surplus listings and an NGO flow for browsing, claiming and collecting, separated by Firebase custom-claim roles assigned at sign-in — not two apps, but one codebase with role-gated screens. Second, a live pickup pipeline: Firestore snapshot listeners push new listings to nearby volunteers within seconds, FCM data messages drive claim-accepted and pickup-reminder notifications, and a nearest-neighbor route turns scattered claims into one efficient run. Third, a trust layer built for perishable food: a mandatory pre-handover safety checklist plus photo confirmation, addressing the real reason donation logistics fail. Around these sit monthly impact reports with meals-saved, diverted-kg and estimated-CO2e figures, full pickup history, and offline-tolerant caching so a volunteer in a basement kitchen still sees cached listings.

• [Donor listing flow] Post a surplus listing in under a minute: food description, category, veg/non-veg tag, quantity in servings, kg or pieces, packaging state, photos and a pickup window — written to Firestore with a GeoPoint and server timestamp.
• [NGO browse, map and claim] Volunteers browse live listings on a map or list inside a 10 km radius (configurable); one-tap claim runs in a Firestore transaction so two volunteers can never take the same food, and the donor is notified instantly.
• [Optimized multi-stop route] Claimed pickups are ordered nearest-neighbor into a single run with per-stop navigation handoff and an approximate total-distance readout.
• [FCM push notifications] Data-only FCM messages for new nearby listings, claim acceptance and pickup-window reminders, with a locally scheduled fallback for devices where background delivery is delayed.
• [Food-safety checklist at handover] Five checks — cooking recency under a 4-hour policy, packaging integrity, veg/non-veg match, spoilage signs, temperature cue — all must pass before the handover confirms, with photo confirmation.
• [Monthly impact reports] Meals saved, food diverted in kg (approximate) and estimated CO2e avoided, aggregated from completed handovers, with a handover history log and CSV export.
• [Offline-tolerant caching] Firestore persistence keeps cached listings browsable without connectivity; new listings and handover confirmations queue and sync on reconnect.
• [Admin moderation queue] Future scope, not in the base build: donor verification badges and a listing-approval queue for city coordinators.

• Complete Kotlin source code for both roles (one codebase, role-gated screens)
• Firebase configuration: Authentication setup, Firestore security rules and indexes, FCM setup, Cloud Functions source
• Data-model documentation for listings, claims and handovers
• Setup guide covering google-services.json, the Maps API key and keystore signing
• Project report PDF, PPT presentation and viva Q&A document
• Project abstract PDF