4th semester

Hvad er et React hook?

En funktion, der giver komponenter adgang til React-funktionalitet som state, lifecycle og memoization uden klasser.

Hvad er et state-hook (useState)?

Et hook der gør det muligt at gemme og opdatere lokal komponentstate, som udløser re-render ved ændringer.

Hvad er et effect-hook (useEffect)?

Et hook til at køre sideeffekter som datafetching, eventlisteners eller timers, baseret på specifikke dependencies.

Hvad er useMemo?

Et hook der gemmer et beregnet resultat og kun genberegner det, når dependencies ændrer sig, for at undgå unødigt arbejde.

Hvad er useCallback?

Et hook der memoiserer en funktion, så dens reference kun ændrer sig, når dependencies ændrer sig.

Hvornår vælger man RESTful API frem for GraphQL?

REST vælges når data er ressourcebaseret, endpoints er stabile, og klienterne ikke kræver fleksible forespørgsler. GraphQL bruges når klienten har behov for at forme egne queries og reducere over/underfetching.

Hvorfor passer REST bedst til jeres projekt?

Domænet består af klare ressourcer som rapporter og scans, appen henter faste datastrukturer, behovene er simple, og caching pr. endpoint fungerer perfekt med React Query.

Hvorfor ikke GraphQL?

GraphQL giver fleksible queries, men tilføjer kompleksitet i server, schema og caching. Projektet har faste ressourcer og simple databehov, så REST er lettere, hurtigere at bygge og nemmere at cache.

Hvordan er arkitekturen i jeres React Native-app (navigation, komponenter, state og serverdata), og hvorfor har I valgt netop den struktur?

Navigation: Expo Router med filbaseret routing. Screens ejer flow og lokal UI-state.

Genbrugelige komponenter er præsentationslag uden navigation eller API.

Serverdata håndteres via React Query med caching, stale-strategi, refetch og mutationer.

Arkitekturen giver klar separation, bedre overblik og reduceret kompleksitet.

Hvordan arbejder I med genbrugelige UI-komponenter, og hvilket komponentmønster bruger I for at forbedre vedligeholdelse og performance?

Vi bruger container + præsentationskomponenter.

Screens ejer logik og state, mens UI-komponenter er rene og får alt via props.

De er lette at genbruge og teste, og giver ensartet UI og færre re-renders.

Hvordan håndterer I asynkrone processer på tværs af screens, fx scanning og upload af køretøjer?

OCR loader asynkront ved mount, scanning kører som async-flow og gemmer midlertidig data i lokal state.

Upload håndteres via mutationer, ofte i batch.

Fejl opsnappes med try/catch og vises i dialoger. Data der skal overleve flows ligger på serveren og i React Query-cachen.

Hvor ligger form- og dialogstate i scanningsflowet, og hvorfor?

Form- og dialogstate ligger som lokal state i VehicleCaptureScreen, fordi den kun giver mening i dette flow, ikke skal deles globalt, og gør komponenten nemmere at forstå og ændre.

Hvordan håndterer I stale data og caching af serverdata?

React Query cacher data pr. reportId, styrer stale-logik og refetch. Komponenten læser blot data, isLoading og isError, mens synkronisering sker automatisk i baggrunden.

Hvad gør I, når et API-kald fejler (både fetch og mutation)?

Fetch-fejl vises via isError og en refetch-knap. Mutation-fejl fanges i try/catch, dialoger lukkes, og en ErrorDialog vises med en tydelig fejlbesked.

Hvordan ville I ændre arkitekturen, hvis appen skulle være offline-first?

Tilføje lokal persistence (fx SQLite), indføre sync-lag, gemme pending-scans offline og synkronisere når netværk er tilgængeligt.

Hooks ville læse lokalt først og derefter sync'e og invalidere caches.

Hvordan vurderer du jeres separation mellem UI, state og API-kald?

UI-komponenter er rene, screens håndterer flow, og API-kald ligger i isolerede hooks.

En yderligere forbedring ville være at flytte store handler-funktioner til dedikerede custom hooks for øget testbarhed og tydeligere separation.

Hvordan er Onion Architecture struktureret i jeres backend, og hvilke lag har I?

Core indeholder domænemodeller, DTO’er og interfaces.

Application indeholder forretningslogik og services.

Infrastructure implementerer repositories og EF Core.

API indeholder controllers og mapping.

Afhængighederne går API → Application → Core og Infrastructure → Core, mens Core ikke afhænger af noget.

Kan du forklare flowet “tilføj scan til rapport” gennem Onion-lagene?

API-controlleren modtager ScanDto og kalder IReportService.

Application-laget henter rapporten via repository-interface, mapper DTO til entity, tilføjer scannet og gemmer via UnitOfWork.

Infrastructure-laget implementerer repository med EF Core og henter rapporten inkl. scans.

Controlleren rører aldrig databasen direkte, Application kender kun interfaces, og Infrastructure indeholder EF-logikken.

Hvad er forskellen på entities og DTO’er i jeres backend, og hvordan mapper I mellem dem?

Entities er domænemodeller brugt i Application og Infrastructure og repræsenterer forretningsdata.

DTO’er er API-kontrakter og bruges til ind/udgående HTTP-data.

Mapping sker i API-laget via AutoMapper-profiler, hvor Report og ReportDto mappes, og visse felter som Scans ignoreres ved DTO → entity.

Hvordan bruger I services og repositories til at følge Onion-principperne i jeres backend?

Services i Application-laget udfører forretningslogik og kalder repository-interfacer fra Core.

Repositories implementeres i Infrastructure og indeholder EF-detaljer.

Controlleren kalder kun services og indeholder ingen databasekode.

Strukturen sikrer testbarhed, lagdeling og klar separation: Controller → Service → Repository → DbContext.

Hvorfor giver Onion Architecture mening i jeres løsning, og hvordan ville du udvide den med et nyt domæneobjekt?

Onion giver ren domænekerne uden afhængigheder, central forretningslogik i Application, databasedetaljer isoleret i Infrastructure og API-lag adskilt fra hele domænet.

Udvidelse sker ved at definere nyt domæneobjekt og interfaces i Core, tilføje repository-implementation i Infrastructure, service i Application og controller + mapping i API.

Hvordan har I designet API-kald og dataflow mellem app og backend, og hvordan understøtter det performance og caching?

• Backend er den autoritative datakilde, og appen holder sig let: den viser data og sender ændringer tilbage.

• Data hentes med React Query (TanStack Query), som håndterer caching, stale/fresh-data og refetching.

• Appen får reportId fra navigation og kalder useReportDetails(reportId) for at hente rapportdata fra backend.

• Nye køretøjer under scanning gemmes kun midlertidigt i lokal state (scannedVehicles).

• Ved afslutning sendes alle scans samlet i én mutation (addScan), så der kun laves få serverkald.

• API’et er simpel REST (GET /reports/:id, POST /reports/:id/scans).

• En fælles Axios-instans håndterer base-URL, timeout og interceptors.

• Frontend bruger domæne-hooks oven på Axios + React Query, med tydelige query keys og invalidation efter mutation, så data altid opdateres korrekt.

• Payloads holdes små, og batch-kald forbedrer performance.

• En oplagt forbedring er et endpoint, der accepterer flere scans i ét kald.

Hvordan sikrer I, at API-kald er robuste over for netværksfejl, timeouts og evt. rate limits – både teknisk og ift. brugeroplevelsen?

Vi bruger en fælles Axios-instans med fast timeout, så alle kald fejler kontrolleret og rammer samme fejl-håndtering.

React Query står for retry og backoff via retry og retryDelay, så midlertidige net- eller serverfejl genforsøges automatisk.

Ved fetch-fejl viser vi en venlig fejl-UI med besked som “Kunne ikke indlæse rapporten” og en Prøv igen-knap, der kalder refetch.

Ved mutation-fejl (fx gemning af scans) fanges fejlen i try/catch, vi lukker relevante dialoger, logger tekniske detaljer og viser en ErrorDialog med en klar fejltekst til brugeren.

Vi skelner mellem tekniske fejl (timeout, 5xx, netværk) som håndteres med retry og “Prøv igen”-flows, og domæne-/valideringsfejl, som forklaret direkte for brugeren.

På serveren understøttes robusthed med meningsfulde statuskoder, validering af DTO’er og evt. rate limiting og central error-middleware.

Hvordan har I løst autentifikation og autorisation mellem app og backend, og hvordan forholder det sig til projektets fokus?

I dette projekt er sikkerhed ikke mit hovedfokus, så autentifikation er bevidst nedprioriteret eller mock’et, for at vi kan fokusere på domænelogik, API-design og samspil mellem app og backend.

I en fuld løsning ville vi bruge token-baseret auth, typisk et login-endpoint der returnerer et accessToken (og evt. refreshToken), som appen gemmer sikkert og sender med som Authorization: Bearer token via en Axios-interceptor.

På backend ville middleware/guards validere JWT’en og tjekke roller/rettigheder, så kun autoriserede brugere kan oprette rapporter og scans.

Hvorfor valgte I React Native fremfor en ren webapp?

Appen kræver stabil kameraadgang til OCR og billedtagning, hvilket er ustabilt i browseren.

Brugsscenariet er feltarbejde, ikke desktop, og React Native giver bedre performance til billeder, native navigation og adgang til lokale ressourcer som GPS og offline.

Web egner sig dårligt til tunge billeder og mobil-UX, så en installeret mobilapp passer bedre til domænet.

Hvorfor valgte I React Native fremfor fuld native (Swift/Kotlin) eller .NET MAUI?

Appen er UI- og API-tung, ikke CPU-tung, så RN er tilstrækkeligt performant.

Pure Native giver kun reel værdi ved avanceret kamera- eller GPU-processing eller tung OS-integration.

RN giver hurtigere udvikling og én kodebase, mens pure native ville være dyrere uden at tilføje værdi i denne use case.

Hvor er React Native stærkere end web – og omvendt?

React Native er stærkere til kamera og OCR, feltbrug med dårligt netværk og native UX som gestures og keyboard-håndtering.

Web er stærkere til desktop-admin, hurtig adgang uden installation og SEO.

Derfor er RN rigtigt valg til feltarbejde, mens web ville egne sig til et senere desktop-adminpanel.

Hvordan passer React Native ind i jeres drift, build-pipelines og backend-setup?

Én kodebase bygges til Android og iOS via EAS/CI, og OTA-opdateringer kan pushes uden app-store review.

Appen kalder backendens REST API via Axios og React Query, mens backend deployes uafhængigt i .NET/Onion Architecture.

Web ville lette drift men miste native-fordele, mens fuld native ville kræve to kodebaser og mere opsætning.

Hvad er dit samlede argument for, at React Native er det rigtige valg i dette projekt?

Use caset kræver kamera, OCR og feltarbejde med behov for stabil device-adgang og mobil-UX.

React Native giver native funktionalitet med én TypeScript-kodebase, hurtig udvikling, passende performance og god integration med navigation og REST-API.

Web er for svagt til kamera/OCR, og fuld native giver for lidt værdi ift. højere udviklingsomkostning.

Hvad er argmax?

Modellen kører én gang og returnerer en matrix med flere plade-forslag og hver sin sandsynlighed - argmax finder positionen med højeste sandsynlighed i den matrix og vælger den.

Hvad er letterbox?

En billedteknik hvor et billede skaleres til et bestemt format uden at ændre proportioner, og tom plads udfyldes med padding.

Hvad er ONNX?

Et åbent model-format, der gør det muligt at køre den samme ML-model på forskellige platforme og runtimes, fx Python, mobil og browser.

Hvad er overfitting?

Når en model lærer træningsdata for præcist, inklusiv støj, og derfor performer dårligt på nye data.

Hvad er underfitting?

Når en model er for simpel til at lære mønstrene i data og derfor performer dårligt både på træning og nye data.

Kan du forklare hele pipeline’n fra kamera til output i mobilappen?

Kameraet tager et billede, som køres gennem runLocalOcr, hvorefter resultatet vises og kan rettes, og data sendes til backend.

Første trin er preload af modeller for at undgå koldstart.

Derefter preprocesses billedet med letterbox og lysnormalisering, bilen detekteres og croppes, farve estimeres, pladen detekteres evt. via double-pass, plade-croppet lys- og kontrastjusteres, og OCR køres med efterfølgende regler.

UI håndterer redigering, fejl og manuel indtastning.

Hvad sker der i preprocess-steppet (letterbox + lysnormalisering), og hvorfor er det vigtigt?

Billedet decodes, resizes til 640×640 med letterbox for at bevare aspect ratio og passe til modellens input, og der beregnes brightnessFactor til lysnormalisering.

Letterbox undgår forvrængning af bil og plade, og lysnormalisering gør modellen mere robust mod mørke, skygger og overeksponering.

Hvordan finder I bil, farve og plade (inkl. double-pass)?

Bil-detektionen finder bounding box og et crop.

Farvedetektion bruger et centralt område og heuristik til sort/grå/hvid eller dominerende farve med mulighed for unknown.

Pladedetektion kører først på hele billedet og derefter på bil-croppet, hvis bilen er lille, for at forbedre chancen for at finde pladen uden altid at betale fuld dobbeltpris.

Hvordan forbereder I plade-croppet til OCR, og hvordan fungerer selve OCR-delen?

Plade-croppet lys- og kontrastjusteres med brightnessFactor og lokal kontrastforbedring.

OCR input resizes til modelens format, laves til tensor i BGR/CHW, og ONNX-modellen køres.

Output argmaxes, og resultatet postprocesses med regler for duplikater, typiske fejlkorrektioner og validering mod danske pladeformater.

Hvordan håndterer I dårlige eller ufuldstændige billeder (støj, mørke, små plader)?

Lys- og kontrastpreprocess forbedrer rå input, double-pass hjælper ved små biler, og regler filtrerer åbenlyse fejl.

Farvedetektion kan returnere unknown ved usikkerhed.

UX-fallback giver manuel indtastning eller rettelse, og OCR-score kan bruges til at styre autoudfyldning.

Hvordan har I testet og valideret, at jeres preprocessing og pipeline virker fornuftigt?

OcrTest-screen viser mellemresultater som vehicle crop, plate crop og brightness-info, så man kan evaluere effekten af preprocess.

Fejlanalyse fokuserer på mørke billeder, små biler og reflekser, og parametre justeres herefter.

En tidligere Python-POC bruges til paritetstest ved at køre samme billeder i begge pipelines og sammenligne tekst og scores.

Hvordan gik I fra en Python-prototype til en React Native-løsning med ONNX på mobilen?

Prototypen kørte i Python med cv2, NumPy og onnxruntime, men en Python-runtime kan ikke shippes fornuftigt på mobil.

Modellerne blev derfor eksporteret til ONNX, og hele preprocessing og postprocessing blev migreret til TypeScript, så pipen kunne køre på mobilens CPU via onnxruntime-react-native med samme logik som i Python.

Hvordan bruger I ONNX-modellerne i både Python og på mobilen?

Alle modeller (bil-detektor, plade-detektor og OCR) ligger som ONNX-filer.

Python loader dem via PyTorch til udvikling og debugging, mens mobilappen loader de samme filer via onnxruntime-react-native og preloader sessions.

Fordelen er én fælles model, der bruges både til POC i Python og produktion på device.

Hvordan har I spejlet preprocessing/postprocessing fra Python til TypeScript?

Python-versionen brugte cv2 og NumPy, mens TypeScript-versionen måtte implementeres med typed arrays og egne funktioner.

Resize blev omskrevet til en bilinear-implementering, argmax blev skrevet som manuelle loops, og letterbox, lysnormalisering og CLAHE-lignende kontrast blev spejlet.

Pipeline-logikken er identisk, blot i TS i stedet for Python.

Hvad er de vigtigste forskelle mellem Python-miljøet og mobilmiljøet, og hvordan påvirkede det jeres design?

Python har cv2, NumPy, høj CPU og meget RAM, og hurtig iteration. (kører på pc eller server)

Mobilmiljøet har begrænsede ressourcer, ingen NumPy/cv2 og kræver håndoptimerede loops og buffer-reuse.

Derfor blev inputstørrelser holdt små, logikken gjort deterministisk, allokering reduceret, og modeller og sessions preloaded for bedre performance.

Hvordan testede I, at overgangen fra Python til mobil ikke ødelagde kvaliteten (paritet)?

Funktioner blev migreret én ad gangen, og begge pipelines blev kørt på de samme testbilleder.

Crops, tensorer og output blev sammenlignet, og OcrTest-screen på device blev brugt til visuelt at tjekke vehicle/plate crops og reader-input.

Fejltyper blev analyseret og preprocess justeret, indtil resultaterne matchede Python-pipen, samtidig med at performance blev målt.

Hvordan vil du kort forklare overgangen fra Python-prototypen til mobil-ML, hvis du bliver presset til eksamen?

Python-prototypen kørte hele ANPR-pipen med cv2 og NumPy.

Vi eksporterede modellerne til ONNX og omskrev hele preprocess og postprocess til TypeScript, så vi kunne køre de samme ONNX-modeller på mobilen med onnxruntime-react-native.

Vi testede paritet løbende med fælles testbilleder og OcrTest-screen, indtil kvalitet og performance matchede Python-versionen.

Hvordan fungerer jeres on-device OCR-pipeline i mobilappen?

Hele ANPR-pipelinen kører lokalt via onnxruntime-react-native.

• Modeller preloads

• billedet preprocesses med letterbox og lys/kontrast-normalisering,

• bilen detekteres og croppes

• farven estimeres

• pladen detekteres med evt. ekstra pass,

• plade-croppet forbedres

• OCR-model + argmax

• regler genererer den endelige pladetekst. (postprocessing)

• UI viser resultatet, brugeren kan rette

• data sendes til backend.

Hvorfor valgte I on-device inferens i stedet for cloud-OCR?

On-device giver lav latency, offline-support og bedre privatliv, fordi billeder ikke sendes ud af enheden.

Det eliminerer behovet for ML-serverdrift og er bedre egnet til feltarbejde.

Cloud ville kræve upload af billeder, stabilt netværk og server-skalering, hvilket ikke passer til brugsscenariet.

Hvilke tekniske begrænsninger har I on-device, og hvordan løste I dem?

Mobilmiljøet mangler NumPy og OpenCV, og ONNX kører på CPU med begrænset performance.

Derfor er pipeline implementeret i TypeScript med egne funktioner som argmax og bilinear resize, små inputstørrelser, CPU-venlig BGR-flow, preload af modeller og selective double-pass for at spare tid og batteri.

Kan du give et eksempel på en TypeScript-optimering, I har lavet til ML-pipen?

Argmax er implementeret som et enkelt loop uden kopieringer eller ekstra allokeringer for maksimal hastighed, og resize bruger forudberegnede vægte og indeks for at minimere arbejde i de inderste loops.

Hele pipen holder data i BGR for at undgå dyre konverteringer.

Hvordan adskiller on-device ML sig fra cloud-ML teknisk og produktmæssigt?

On-device kører direkte på telefonens CPU med lave svartider, offline-funktionalitet og ingen dataafsendelse, hvilket reducerer drift og forbedrer privatliv.

Cloud-ML giver stærke værktøjer og central modelopdatering, men kræver upload, serverdrift, skalering og håndtering af netværksfejl og GDPR.

For dette projekt giver on-device bedst UX og mindst drift.

Hvordan forklarer du hele ML-designet kort, hvis eksaminator presser dig?

ANPR-pipelinen er flyttet fra Python til mobil ved at eksportere modeller til ONNX og omskrive hele preprocess og postprocess i TypeScript.

Modellerne kører lokalt via onnxruntime-react-native for at opnå offline-support, lav latency og god performance i felten.

Dette kræver optimerede loops og små tensorer, men giver en hurtig og robust scanner, der fungerer uden netværk.

Hvor i appen ligger ML-flowet, og hvordan bruges det af brugeren?

ML-flowet ligger i VehicleCaptureScreen, hvor et billede tages, køres gennem runLocalOcr, og resultatet udfylder formularfelter.

Brugeren kan rette, acceptere eller scanne igen, og godkendte data gemmes via addScan.mutateAsync.

Hvordan håndterer appen loading, errors og navigation omkring ML-kørslen?

OCR kører asynkront, og appen viser loading-tilstand under processen.

Ved success udfyldes felter automatisk, og ved fejl gives enten dialog og retry eller en besked om manuel indtastning.

Brugeren kan altid redigere eller scanne igen.

Hvordan håndterer I dårlige eller tvivlsomme OCR-resultater?

Manglende plade efterlader feltet tomt med besked til brugeren.

Ved lav confidence markeres resultatet som usikkert, og brugeren kan rette.

Hvis flere mulige plader findes, vælges den bedste, men brugeren kan stadig ændre alt.

Preprocess forbedrer robustheden.

Hvordan har I testet ML-delen i selve appmiljøet?

Python-POC blev brugt til udvikling, hvorefter funktionerne blev portet trinvis til TypeScript.

OcrTest-screen viser crops, reader-input og debug-info, så mobiloutput kan sammenlignes med Python-output.

Gemte billeder og mockede modeller bruges til reproducerbare tests.

Hvordan sikrer I, at ML-resultatet passer ind i hele appens flow og backend?

OCR er kun et forslag til formularen, og det er brugerens godkendte data, der sendes til backend.

Formularens state og navigation styrer brugen af ML, så integrationen ikke skaber kompleksitet uden for scanningflowet.

Giv en kort, presset eksamensforklaring på, hvordan ML er integreret i UX’en.

ML kører på VehicleCapture-skærmen, hvor kameraet tager et billede, runLocalOcr giver et forslag, og brugeren kan rette alt.

Loading vises under OCR, fejl håndteres med klar UI, og output renses og valideres før visning.

ML er derfor en hjælp i et almindeligt formularflow, ikke en separat funktion.

Hvordan forklarer du ML-delen til ikke-tekniske uden at nævne ONNX, logits osv.?

Når brugeren tager et billede, kører en lille billedlæser på telefonen, som forbedrer billedet, finder bilen og pladen og foreslår tekst og farve.

Det er kun et forslag, som brugeren kan rette, og alt sker lokalt uden at sende billeder til en server.

Hvad er styrker og svagheder ved ML-flowet?

Styrkerne er hurtige scanninger, mindre tastearbejde og offline-funktionalitet.

Svaghederne er, at resultatet ikke altid er 100 procent korrekt og kræver, at brugeren tjekker og retter, samt at billedet skal være rimeligt tydeligt.

Hvordan undgår I, at ML-resultatet bliver misvisende for brugeren?

Resultatet vises i almindelige inputfelter, som kan redigeres, og det renses gennem regler før visning.

Ved dårlige input efterlades feltet tomt med en besked, og ved usikkerhed kan UI markere feltet.

Output præsenteres i domænesprog uden tekniske begreber.

Hvordan tester I, at pipeline og UX fungerer sammen i praksis?

OcrTest-screen viser crops og debuginfo, så fejl kan isoleres.

Gemte billeder og mocks giver reproducerbare tests, og resultater sammenlignes løbende med Python-output for at sikre ens kvalitet.

UI-test sikrer korrekt mapping til felter.

Kort, hvis du bliver presset: hvordan kommunikerer du ML-begrænsninger?

ML er en hjælper, der foreslår nummerpladen, men som kan tage fejl ved dårligt lys, stor afstand eller snavs, og at brugeren derfor altid kan rette.

Alt sker lokalt, og UI viser kun klare, forståelige felter.

Hvordan fungerer Postprocessing?

Når OCR har læst teksten, bliver resultatet renset og rettet, så det ligner en normal dansk nummerplade.

Det der sker er:

1. Teksten gøres store bogstaver og uden mellemrum.

2. Kun de sidste 7 tegn beholdes.

3. Hvis teksten har præcis 7 tegn, rettes de to første som bogstaver (fx 0 → O, 1 → I) og de fem sidste som tal (fx O → 0, I/L → 1).

4. Hvis resultatet matcher et normalt dansk format (to bogstaver + fem tal), bruges den rettede version.

5. Hvis ikke, bruges den urettede tekst.

Kort sagt:
Systemet prøver at rette almindelige OCR-fejl, men kun når resultatet ligner en standardplade. Ellers lader det teksten være, så specialplader ikke bliver forvansket.

Hvordan fungerer double pass-detektionen?

1. Første pass: detektion på hele billedet
   Modellen kører på det fulde, letterboxed foto og finder en foreløbig nummerpladeboks.
   Ud fra den boks laves et plate crop (et udklip omkring pladen).

2. Vurdering af størrelse
   Systemet tjekker, om pladen fylder meget lidt i hele billedet. Hvis den er meget lille, kan modellen have svært ved at placere boksen præcist.

3. Andet pass: detektion på plate crop
   Kun hvis pladen var lille, kører vi det samme detektionsmodel igen, men denne gang på det lille udklip fra første pass.
   Det giver modellen et tættere og skarpere udsnit, så den kan finde en mere præcis boks.

4. Valg af det bedste resultat
   Systemet vælger den bedste af de to boksresultater (første eller andet pass) og bruger den til resten af OCR-flowet (lysjustering, CLAHE, OCR osv.).

Hvorfor kører vi ikke bare altid detektion direkte på plate crop?

Fordi “plate crop” ikke findes endnu.

1. Først kører vi pladedetektoren på hele billedet.

   • Her finder modellen, hvor nummerpladen cirka sidder, og giver en boks omkring den.

2. Ud fra den boks laver vi et udklip af billedet – det er det, vi kalder plate crop.

3. Kun hvis bilen/pladen er lille i hele billedet, kører vi en anden runde detektion på dette udklip for at få en mere præcis boks.

Så: vi kan ikke starte på plate crop, fordi vi først skal bruge første detektion til at finde, hvor vi skal klippe.

Hvad er CLAHE?

CLAHE er en metode, der øger lokal kontrast i et billede ved at justere lys og mørke område for område, så detaljer bliver tydeligere uden at skabe for meget støj.

Er CLAHE en form for lysnormalisering?

Nej. Det ændrer også intensiteter, men det gør det for at øge lokal kontrast, ikke for at opnå ensartet lysniveau. Det er en helt anden mekanisme end global lysnormalisering.

Hvad er React Query?

React Query er et bibliotek til React, der håndterer data, der kommer fra API’er.

• Caching af API-data

• Refetching når data kan være forældet

• isLoading / isError / isSuccess-states

• Automatisk synkronisering, fx ved fokus eller netværksændringer

• Styring af stale vs. fresh data

Det er derfor et komplet system til at hente, gemme og holde API-data opdateret i React.

Hvorfor React Native fram for andet Cross Platform-framework?

• Stort økosystem og mange færdige moduler

• Hurtig udvikling og nem onboarding (JavaScript/TypeScript)

• Høj performance tæt på native

• Stor community-støtte og lang levetid

• Bedre tredjepartsintegrationer end de fleste mindre udbredte frameworks

Kort sagt: mere modent, bredere support og hurtigere at bygge med.

Hvordan skelner I mellem client state og server state i appen, og hvilke retningslinjer bruger I for, hvor data skal ligge?

Client state er midlertidig UI- og flow-state, som kun giver mening på den aktuelle screen – fx åbne dialoger, formularfelter under scanning og lokale fejlbeskeder. Det håndteres med React hooks som useState.

Server state er domænedata, hvor backend er source of truth – fx rapporter, scans og køretøjer. Det hentes altid via API’et og styres af React Query med caching, staleTime og invalidation.

Hvis data skal deles på tværs af screens, overleve navigation og kunne synkroniseres med backend, er det server state; alt andet er lokal client state.

Hvordan ville du sammenligne React Native med andre cross-platform frameworks som .NET MAUI i forhold til jeres projekt?

.NET MAUI ville give tættere integration til .NET-backenden og C#, men er mere umodent til mobil og har mindre økosystem omkring kamera og ML for vores brug.

I vores case giver RN hurtigere udvikling, bedre kompetencematch og nok performance, så mer-kompleksiteten ved at skifte til Flutter/MAUI giver ikke ekstra værdi.

Hvordan bruger I interfaces og generiske basekomponenter i jeres Onion-arkitektur, og hvad er fordelen?

I Core definerer vi interfaces som IReportRepository og generiske baserepositories som IRepository<T>, der beskriver CRUD-operationer uden at kende til EF Core.

Application-laget afhænger kun af de interfaces, ikke den konkrete database.

I Infrastructure implementerer vi de interfaces med generiske baseklasser, som indeholder den delte EF-logik.

Fordelen er, at domænelaget er rent og testbart, og at vi kan genbruge databasekode på tværs af entities, samtidig med at vi kan skifte database- eller ORM-teknologi uden at ændre Core og Application.

Hvilke performance-overvejelser har I gjort i backend for at understøtte mobilappen?

Vi holder payloads relativt små og designer endpoints til de konkrete use cases, fx GET /reports/:id med kun de data, appen faktisk bruger.

Vi undgår N+1-queries ved at inkludere relaterede entiteter, hvor det giver mening, og vi kan indføre pagination eller filtrering på lister.

Derudover kan vi cache tunge opslag, og vi bruger meningsfulde statuskoder så klienten kan optimere sine retries.

I en mere moden driftssituation ville vi kombinere det med metrics for svartider, error rates og eventuel rate limiting.

flere specialiserede modeller vs. én stor model til ANPR på mobilen?

Vi bruger flere specialiserede modeller: én til køretøjsdetektion, én til pladedetektion og én til OCR.

Fordelen er, at hver model kan holdes relativt lille og målrettet, hvilket er godt for mobilperformance, og at vi kan udskifte én del uden at påvirke resten.

En stor end-to-end-model kunne potentielt blive mere præcis, men ville typisk være tungere, sværere at debugge og mindre fleksibel i forhold til f.eks. at justere preprocessing eller regler.

Hvad mener du, når du siger, at I “batcher” scans i klienten?

Brugeren laver mange scans, som gemmes i lokal state. Når der trykkes “gem”, sender vi alle POST-kald i ét samlet flow. Det er stadig individuelle requests, men én logisk gem-operation i UI’et.

Hvordan kunne I forbedre batching i API-designet?

Ved at tilføje et bulk-endpoint, fx POST /reports/:id/scans/bulk, der accepterer en liste af scans. Så bliver det ét HTTP-kald, mindre overhead og nemmere fejlhåndtering på serversiden.

Hvorfor har I ikke implementeret rate limiting eller API-gateway?

Det er et bevidst fravalg. Vi har få, kendte brugere og begrænset trafik, så vi prioriterer tid på domænearkitektur og on-device ML. I en produktionsløsning ville vi lægge backenden bag en gateway med rate limiting og logging.

Hvordan understøtter Onion Architecture senere drift-forbedringer som gateway og rate limiting?

Alle endpoints ligger i API-laget, og al forretningslogik i Application. Det gør det nemt at lægge en gateway foran og tilføje rate limiting, uden at ændre domænekoden.

Hvordan balancerer jeres design robusthed, udviklingshastighed og drift?

Vi har valgt en simpel, monolitisk .NET-backend med Onion Architecture og en React Native-app med React Query. Det giver hurtig udvikling og klar struktur, og samtidig kan appen levere kernefunktioner offline, uden at vi skal drifte tung ML-infrastruktur.

Hvordan hjælper React Query og Axios jer i forhold til robusthed og drift?

De centraliserer timeouts, retries, caching og error-handling. Det gør klienten mere robust over for netværksfejl og gør det nemmere at tune driftsparametre ét sted i stedet for i hver komponent.

Hvad er en API gateway?

En API gateway er et centralt indgangspunkt til et system, som modtager alle eksterne requests og videresender dem til de rigtige interne services.

Den håndterer tekniske tværgående concerns som autentifikation, routing, logging og rate limiting.

Hvad er rate limiting?

Rate limiting er en mekanisme, der begrænser hvor mange requests en klient må sende inden for et givent tidsinterval, for at beskytte systemet og sikre fair brug.

Bruges til at undgå overbelastning, beskytte mod misbrug, sikre lige adgang for klienter og stabil drift af systemet.

Hvordan spiller API gateway og rate limiting sammen?

API gatewayens rolle er ofte at implementere rate limiting, så requests stoppes tidligt, før de rammer backend-services.