Die Umbenennung von Gruppen in "Kategorien" war falsch: Es sind zwei
verschiedene Dinge. Sie ist zurueckgenommen, Kategorien kommen als eigene Ebene
dazu.
GRUPPE zaehlt Bestaende mehrerer Marken zusammen - Mehl von Rewe, Aldi und
Migros ergeben "5 kg Mehl". Dafuer Mindestbestand mit Einheit und EAN-Codes.
KATEGORIE ordnet allein die Artikelliste ("zeig mir alle Suesswaren"), ist
verschachtelbar wie ein Lagerort und hat weder Bestand noch EAN-Codes. Ein
Artikel kann beides, eines oder keines haben.
Die Vermischung war aelter als die Umbenennung: guessGroup in offUtils.js hat
aus der Open-Food-Facts-KATEGORIE eine GRUPPE geraten. Das ist entfernt. Die
OFF-Einordnung steuert jetzt die Kategorie, wo sie hingehoert; eine Gruppe
entsteht nur ueber einen hinterlegten Gruppen-Code oder bewusste Auswahl.
EAN-Codes an der Gruppe: Das war kein Anzeigefehler. Beim Anlegen eines Artikels
wurde ausschliesslich group_id gesetzt - ein Gruppen-Code entstand nie, die
Liste war tatsaechlich leer. Die Meldung "bereits vergeben" kam daher, dass der
Code am Artikel hing. Jetzt pflegt services/group_codes.py den Code mit: beim
Zuordnen kommt er hinzu, beim Gruppenwechsel wandert er mit, beim Entfernen der
Gruppe oder Loeschen des Artikels verschwindet er. Beim Scannen aendert sich
nichts an der Reihenfolge - der Artikel wird weiterhin zuerst gefunden; der
Gruppen-Eintrag ist Beleg in der Verwaltung und Rueckfall. Traegt man denselben
Code von Hand nach, ist das kein Fehler mehr, sondern die Auskunft, dass er ueber
den Artikel bereits dort steht.
Kategorien im Backend: neue Tabelle mit parent_id (Muster von Location),
products.category_id per ADD COLUMN IF NOT EXISTS nachgezogen, deutsche
zweistufige Startliste analog zu den eingebauten Einheiten. Die Startliste wird
nur angelegt, wenn ueberhaupt noch keine Kategorie existiert - wer sie bewusst
leerraeumt, findet sie nicht wieder. Beim Setzen einer Oberkategorie wird
geprueft, dass keine Kategorie sich selbst oder einem eigenen Nachfahren
untergeordnet wird; sonst entstuende ein Ring und jede Baumdarstellung liefe
endlos. Der Produktfilter schliesst Unterkategorien ein, category_id=0 liefert
die Artikel ohne Kategorie. Export und Import fuehren die Kategorie als Pfad
("Suesswaren & Snacks > Schokolade") in einer Spalte, damit die CSV in Excel
bedienbar bleibt.
Web: neue Seite Kategorien mit Baumdarstellung, Filter ueber der Produktliste,
getrennte Auswahlfelder im Produktformular mit je einer Zeile Erklaerung, und
beim Einlagern laesst sich eine Gruppe samt Einheit und Mindestbestand direkt
anlegen, ohne den Vorgang zu verlassen.
iOS: Kategorie-Filter ueber der Produktliste, Unterkategorien eingerueckt. Die
Artikelzeile nennt jetzt das Gebinde und warnt, wenn der Mindestbestand
unterschritten ist (rot) oder weniger als ein Viertel Luft bleibt (orange).
Getrennte Auswahlfelder fuer Kategorie und Gruppe, Gruppe direkt anlegbar.
Ausserdem die Eingabefelder in der App: .textFieldStyle(.roundedBorder) zeichnet
in der dunklen Darstellung einen fast schwarzen Kasten. Ersetzt durch eine
Systemfuellung, die sich Hell und Dunkel anpasst und zurueckhaltend bleibt.
Getestet: 54 pytest-Tests gruen, 14 davon neu (Nachfahren-Sammler, OFF-Zuordnung
inklusive Vorrang der Unterkategorie, und die komplette Codepflege an der
Gruppe). Gegen die laufende API geprueft: Startliste ohne Dubletten, Filter auf
Ober- und Unterkategorie, Ringschutz, Loeschen einer Kategorie laesst Artikel
und Unterkategorien bestehen, Export/Import-Rundlauf mit Kategoriepfad, und der
Durchlauf aus der Meldung - Artikel mit Gruppe anlegen, Code steht danach in der
Gruppe. Web-Build und iOS-Geraetebuild fehler- und warnungsfrei.
Die Oberflaechen habe ich nicht selbst bedient.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
4.2 KiB
Project-Good – iOS-App
Native SwiftUI-App zum Ein- und Auslagern per Barcode-Scan. Sie spricht dieselbe REST-API wie die Web-Oberfläche.
Stand: Läuft auf dem Gerät. Login, Scanner, Einlagern mit mehreren Chargen/MHDs, MHD per Texterkennung, Auslagern mit Chargenauswahl, Artikel anlegen aus Open Food Facts, Einkaufsliste, Ablaufliste sowie Produkte ansehen und bearbeiten.
Projekt in Xcode öffnen
Variante A – mit XcodeGen (empfohlen)
brew install xcodegen
cd ios
xcodegen generate
open ProjectGood.xcodeproj
project.yml beschreibt das Projekt vollständig (Bundle-ID, Info.plist,
Shortcuts, URL-Schema).
Variante B – ohne XcodeGen
- Xcode → File ▸ New ▸ Project… → App, Interface SwiftUI, Sprache Swift
- Produktname
ProjectGood, Bundle-ID z. B.com.scarriffle.projectgood - Die von Xcode erzeugte
ContentView.swiftund…App.swiftlöschen - Den Ordner
Sources/per Drag & Drop ins Projekt ziehen („Copy items if needed") - In den Target-Einstellungen die mitgelieferte
Sources/Info.plistals Info.plist setzen (Build Settings ▸ Info.plist File) und Generate Info.plist File auf No stellen
Auf dem iPhone installieren
- iPhone per Kabel verbinden, in Xcode als Ziel auswählen
- Signing & Capabilities → dein Apple-Developer-Team wählen
- ▶︎ Run. Beim ersten Start auf dem iPhone unter Einstellungen ▸ Allgemein ▸ VPN & Geräteverwaltung dem Entwickler vertrauen
Erste Schritte in der App
Beim Start nach der Server-Adresse fragen lassen, z. B. http://192.168.1.50:8080
(dieselbe Adresse wie im Browser), dann mit deinem Benutzer anmelden. Adresse und
Token bleiben gespeichert – das Token liegt im Keychain.
Home-Screen-Shortcuts
Es gibt zwei Wege direkt in den Scan-Bildschirm:
Schnellaktionen – langer Druck auf das App-Symbol zeigt „Einlagern" und „Auslagern" (funktioniert ohne weitere Einrichtung).
Eigene Symbole auf dem Home-Bildschirm – über die Apple-App Kurzbefehle:
- Kurzbefehle ▸ + ▸ Aktion URL öffnen
- URL
projectgood://checkin(bzw.projectgood://checkout) eintragen - Kurzbefehl benennen, dann ▸ Zum Home-Bildschirm hinzufügen
Beide Wege öffnen die App direkt in der Kamera.
Aufbau der Quellen
| Datei | Inhalt |
|---|---|
ProjectGoodApp.swift |
App-Einstieg, Schnellaktionen, URL-Schema |
Session.swift |
Server-Adresse (UserDefaults) und Token (Keychain) |
APIClient.swift |
REST-Aufrufe gegen /api/... |
Models.swift |
Codable-Typen passend zu backend/app/schemas.py |
ScannerView.swift |
Kamera + Barcode-Erkennung (EAN-8/13, UPC-E, Code128, QR) |
RootView.swift |
Startbildschirm und Routing |
LoginView.swift |
Server + Anmeldung |
CheckInView.swift / CheckInFormView.swift |
Scan → Menge, mehrere Chargen mit MHD |
CheckOutView.swift |
Scan → Menge, Chargenauswahl oder FEFO |
ProductViews.swift |
Artikelsuche und Anlegen (mit OFF-Vorbefüllung) |
ProductDetailView.swift |
Produkt bearbeiten, Chargen korrigieren und löschen |
ListViews.swift |
Einkaufsliste, „bald ablaufend", Produktliste |
DateScanView.swift / BestBeforeText.swift |
MHD per Texterkennung ablesen |
DisplaySettings.swift |
Datumsformat und Einheiten-Beschriftungen vom Server |
CategoryPicker.swift |
Kategorie-Auswahl und Gruppe anlegen |
Gruppe und Kategorie – zwei verschiedene Dinge
Gruppe dient der Bestandsrechnung: Mehl von Rewe, Aldi und Migros zählen zusammen, wichtig ist „ich habe 5 kg Mehl“. Eine Gruppe hat deshalb einen gemeinsamen Mindestbestand mit Einheit und EAN-Codes. Ordnest du einen Artikel einer Gruppe zu, erscheint sein EAN-Code automatisch dort; wechselt er die Gruppe, wandert der Code mit.
Kategorie dient allein dem Überblick („Süßwaren“, „Molkereiprodukte“) und ist verschachtelbar wie ein Lagerort (Süßwaren → Schokolade). Sie hat keinen Bestand, keinen Mindestbestand und keine EAN-Codes. Filterst du auf eine Oberkategorie, erscheinen die Artikel ihrer Unterkategorien mit. Beim Anlegen schlägt der Server eine Kategorie aus der Open-Food-Facts-Einordnung vor.
Noch offen
- Push-Benachrichtigungen bei ablaufenden Produkten
- Lagerort je Charge beim Einlagern wählbar