AuctionApp

AuctionApp lar folk legge ut brukte ting til auksjon på mobilen, og se andres bud oppdatere seg i sanntid. Det var mobilutviklings-emnet vårt (MOB3000), og vi fikk A på det.

Problem

Caset var privatpersoner og organisasjoner som vil selge eller by på brukte ting fra telefonen, slik at de slipper å samle alle på ett fysisk sted. Det gir flere budgivere og høyere sluttpris, og krever sanntidsoppdatering og rollebasert tilgang i appen. Vi var fire på teamet og bygde det som Android-app i Java.

Løsning

Admin lister ut produkter med bilder, startbud og deadline. Vanlige brukere blar gjennom listen og legger inn bud, og budene oppdateres på tvers av enheter via Firebase Realtime Database som pusher endringer rett til klientene. Når deadlinen passerer, flytter ProductManager auksjonen fra products til sold_products, og høyeste bud vinner. Admin har et dashboard med fanene "Current Bidding" og "Purchased" og kan laste ned budhistorikk som CSV. Firebase Authentication håndterer login og rollesjekk.

Min rolle var Database Engineer og Full Stack-utvikler. Jeg jobbet i grensesnittet mellom backend og frontend, designet databasestrukturen i Realtime Database (User Profiles, Auction Items, Bids, Admin Data) og jobbet på CRUD-operasjonene på tvers av aktivitetene. Jeg ledet testingen av brukerinteraksjon og sanntids-budoppdateringer, og sto for kodegjennomgang på GitHub.

Beslutninger og refleksjon

Beslutninger jeg tok

Firebase Realtime Database fremfor Firestore. Begge lå inne i build.gradle. Realtime Database pusher endringer direkte til alle klienter uten polling-kode, mens Firestore har sterkere spørringer. For en budliste som må oppdatere seg umiddelbart, var det pushen som telte.

Strammet inn passord- og e-postkrav. Firebase tillater seks tegn og hvilken som helst e-postdomene. Vi krevde Gmail og passord på mer enn åtte tegn etter en sikkerhetsgjennomgang. Det betydde at testpassordet "pass123" sluttet å fungere, så vi byttet til "pass12345" og dokumenterte det i rapporten.

Når en auksjon utløper, flytter ProductManager den fra products over til en egen sold_products-node. Vi vurderte en boolean på samme rad og filtrering i listingen, men det ville bare gjort hovedlista lengre for ingenting. Med en egen node er admin sin "Purchased"-fane bare en lesning av sold_products.

Da jeg skulle publisere repoet til porteføljen, vurderte jeg å rydde duplikasjonen mellom BuyProductsActivity og BuyProductsActivityUser, flytte logikk ut av Activity-klassene og legge på tester. Jeg landet på at det var ærligere å la koden stå slik den ble levert, og heller skrive et avsnitt i README om hva jeg ville endret nå.

La til .gitignore og google-services.json.example før publisering. Originalt lå ekte google-services.json med Firebase API-nøkkel inne i prosjektet, slik kurset ba om. I et offentlig repo går det ikke. Eksempel-malen viser formatet uten at credentials lekker.

Hva jeg lærte

Arkitekturen ville jeg gjort annerledes i dag. Hele logikken lever i Activity-klassene, uten ViewModel eller Repository-lag, så Firebase-kall, validering og UI-oppdatering ender opp i samme fil. BuyProductsActivity og BuyProductsActivityUser deler omtrent 80 prosent kode. Et tynt repository-lag mellom Firebase og Activity hadde løst mye, og de to Buy-skjermene kunne vært slått sammen til én Activity med rollesjekk.

ProductActivity.uploadFile() fyller en vanlig ArrayList fra Firebase Storage-callbacks. Callbackene kan fyre i annen rekkefølge enn opplastingen startet, så bilderekkefølgen i databasen er ikke garantert. Det merkes på dårlig nett, og det er en bug jeg ikke fanget før innlevering.

google-services.json med API-nøkkelen lå inne i repoet ved innlevering, slik kurset ba om. Det fungerte under sensur. I dag setter jeg opp .gitignore før jeg gjør første commit på et nytt repo.