CraftSale - Artikelverwaltung für Kunsthandwerk

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

Aufgrund der Corona-Krise: Die Veröffentlichung von Stellenangeboten und -gesuchen ist bis 31.12.2021 kostenfrei. Das beinhaltet auch Angebote und Gesuche von und für Freischaffende und Selbstständige.

  • CraftSale - Artikelverwaltung für Kunsthandwerk

    Hallo zusammen,

    Apple hat gerade CraftSale freigegeben, mein aktuelles Hobbyprojekt. Ich würde Euch gerne ein paar Low- und Highlights vorstellen, wobei aufmerksame Foren-Leser*innen schon das ein oder andere Thema kennen werden:

    Motivation

    Meine Frau verkauft Selbstgenähtes auf Kunsthandwerkermärkten - zugegeben, im Moment eher weniger. Um den Überblick über ihren Artikelbestand und evt. "Nachproduktionen" zu wahren, benutzte sie eine sehr generische Inventory-App, die ich entsprechend konfiguriert hatte. Obwohl ich großen Respekt vor deren Entwicklung habe, gab es doch ein paar Nachteile: Die App bietet allgemeine Verzeichnisse, z. B. für Bücher, DVDs, Versicherungen ... und kann damit nicht optimal auf die o.g. Aufgabe zugeschnitten sein. Außerdem schien sie mit dem aktuellen Bestand von > 6.000 Artikeln am Limit und wir fürchteten das "Lock-in", falls der Entwickler einmal die Lust verlieren oder ernste Bugs auftreten würden. Das Thema gärte schon länger und reizte mich durch ein paar technische Aspekte, auf die ich unten eingehe.

    Idee

    Ich wollte eine UISplitView-basierte App unter Mac Catalyst schreiben, deren Daten in Core Data gespeichert und mittels iCloud synchronisiert werden sollten. Die Konfiguration von Artikellisten sollte dynamisch auf Basis von Kriterien möglich sein und auch als Grundlage für (Verkaufs-) Berichte und HTML-Exporte dienen. Letztere werden auf dem Mac für das Organisieren der Nachproduktion verwendet, daher auch der Wunsch einer macOS-Version mit der Perspektive, dieses Thema später zu integrieren. Ausserdem wollte ich das Projekt nutzen, um ein paar neue Dinge auszuprobieren (iOS 14 als Deployment Target war kein Problem). Und last but not least mussten natürlich die Bestandsdaten aus der anderen App übernommen werden (keiner möchte tausende von Artikel inkl. Fotos neu erfassen), diese lagen als gezipptes CSV zzgl. JPEGs vor.

    Umsetzung

    Komplett in Objective-C programmiert mit einer recht spannenden View-Hierarchie: Eine UISplitView, zwei geschachtelte MasterViews und eine in einen UIPageView-Controller eingebetteten DetailView mit UITableView und UICollectionView als deren Header. Die CollectionView-Zellen rufen wiederum in einen UIPageView-Controller eingebettete UIScrollViews mit UIImageViews auf. Dann noch modale Dialoge zur Datenänderung. Okay, wenn ich das so schreibe, komme ich mir schon leicht irre vor, das versteht so keiner ... schaut Euch bei Interesse die App einfach an, das kann man schlecht beschreiben :) Interessant vielleicht, dass nur die rudimentäre SplitView-Struktur im Storyboard liegt, der Rest wird programmatisch erzeugt.

    Hier stichwortartig ein paar Punkte in der Umsetzung, die mich forderten, teilweise mit Links in's Forum. Bei Interesse an Details meldet Euch einfach hier im Thread, mehr würde im Moment echt den Rahmen dieses Postings sprengen:
    • UIScene-Support: Hatte ich - bedingt durch das Apple-Template - eigentlich vor, auch wenn die App gar keine mehrfachen Fenster unterstützen sollte. Ich stolperte dann über den komplett geänderten State-Restoration-Prozess (Link) sowie Handoff mit einem konzeptionellen Problem (s.u.). Dann habe ich das Projekt auf den klassischen AppDelegate umgebaut.
    • State Restoration: Das Verfahren wurde von Apple zwecks Unterstützung von mehreren Scenes komplett umgestellt (Link). Das neue Konzept ist quasi eine Unterart von Hand-Off und stellte mich wie gesagt vor ein konzeptionelles Problem (s.u.). Ich habe deshalb die klassische Variante implementiert.
    • Hand-Off: Hätte ich gerne als Goodie zusätzlich zur State Restauration implementiert. Die Umsetzung war angesichts der View-Controller-Hierarchie schon spannend, letztlich scheiterte ich aber an der Notwendigkeit, ein iCloud-synchronisiertes Core-Data-Objekt auf unterschiedlichen Geräten zu referenzieren (Link). Das liesse sich mit Änderungen im Datenmodell lösen, aber ich wollte endlich die App "auf die Strasse bringen".
    • OpenSSL unter Mac Catalyst ließ mich etwas schwitzen, da die Bibliotheken plattformspezifisch sind, aber durch Namensgleichheit problematisch einzubinden waren. Ich habe es über Verwendung eines XCFrameworks gelöst (Link). Notwendig war OpenSSL für die Receipt-Validierung zur Unterstützung von In-App-Purchase. Für die eigentliche Überprüfung verwende ich externen Code ("Receigen").
    • Export / Import von Core Data sollte für Backups und zum Bereitstellen von Beispiel-Daten genutzt werden. Hierbei ist das Erstellen einer gesonderten ID zur Abbildung von Relationen sinnvoll (Link).
    • ZIP-Archive für die Backups und den Import aus der Vorgänger-App: Eine der Stellen, wo ich auf externen Code ("SSZipArchive") zurückgegriffen habe (Link).
    • Die UI hat ein paar diverse (Standard-) Komponenten, die mich trotzdem beschäftigten:
      • Eine UICollectionView mit Fotos als headerView einer UITableView inkl. Kontextmenüs für die Fotos mit Vorschau und Umsortieren (Link).
      • Eine zoom- / scrollbare UIImageView ... eigentlich kein Hexenwerk, aber ich habe hier eine schöne externe Lösung gefunden ("ISVImageScrollView"), die ich gerne verwendete (Link).
      • Der neue UIDatePicker machte unter Mac Catalyst im inline-Modus innerhalb der AccessoryView einer UITableViewCell etwas Probleme. Gelöst durch dynamisch eingeblendete Zeilen à la Erinnerungen-App (Link)
      • UITextFields zur Eingabe von Mengen und Währungen mit Berücksichtigung der Lokalisierung (Link)
      • Eine UINavigationBar mit weisser Schrift auf farbigem Hintergrund. Die Anpassung per Appearance führte zu ekligen Nebeneffekten mit anderen Controllern. Die Lösung ist letztlich eine eigene Klasse, die sauber referenziert werden kann (Link, Link).
    • Letztlich führte Apple's Review Prozess noch zu Spass (Link): Zum einen störte er sich an der Verwendung des Wortes "Demo" für Beispieldaten, zum anderen stolperte der IAP-Prozess beim Reviewer, nicht aber bei mir. Die Fehlersuche gestaltete sich daher etwas schwierig.
    Fazit

    Nach fast 7 Monaten, 365 Commits, ca. 10k LoC (viele Kommentare / Leerzeilen) und drei Review-Anläufen ging mir in den letzten Tagen etwas die Luft aus. Trotzdem hat das Projekt unheimlich viel Spass gemacht und ich freue mich schon auf dessen produktive Nutzung ... auch wenn diese in der momentanen Situation übersichtlich sein wird. Kommerziell wird das Thema uninteressant bleiben, da es - mal wieder - eine reine Nischenlösung darstellt. Aber das kennt Ihr von mir ja schon. Und es stehen schon Punkte auf der Todo-Liste... Hierzu gehört auch der macOS-Support, den wir zwar intern schon verwenden, für die Öffentlichkeit ist das Look & Feel aber (noch?) ungeeignet.

    Die letzten Tage habe ich mit dem Erstellen eines kleinen Web-Auftritts und von Anleitungs-Videos verbracht. Für letztere nutze ich gerne (zum vierten Mal) Fremd-Code ("FingerTips"), damit man sehen kann, wo auf dem iPhone getoucht wird.

    Sorry for the book ... und danke, wenn Ihr bis hierhin gelesen habt. Promo-Codes gibt es nicht, weil man die App kostenlos laden und mit max. 20 Artikel pro Shop ausprobieren kann :)

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.

    Dieser Beitrag wurde bereits 10 mal editiert, zuletzt von MyMattes ()