XML macht das Rennen Tagebuch eines Entwicklers Teil 2

Mit XML geht das Tagebuch eines Entwicklers in die zweite Runde.

Unglücklicherweise habe ich aus privaten und beruflichen Gründen etwas länger für die Überlegungen des ersten Teils benötigt, als normal wäre und ich ursprünglich veranschlagt hatte. Das soll uns aber erst einmal nicht stören, sondern wir starten nun direkt durch und stellen weitere Überlegungen an.

Was bisher geschah

Die Problematik der Speicherung war immer Hauptaugenmerk meiner Überlegungen. Ich bin allerdings später, auch durch die ein oder andere Zuschrift eurerseits, davon abgewichen mir primär Gedanken um die Speicherung zu machen, sondern bin auf eventuelle Zusatzfunktionen eingegangen. Dazu gehören der Multiuserzugriff, die Verbindung bzw. Synchronisation mit einer App, das Einlesen der Barcodes et cetera perge perge.

Das ist im übrigen eine der wichtigsten Notiz-Zeiten, denn in dieser Phase kommen viele gute Ideen ans Tageslicht, welche schnell wieder vergessen werden können, oder an die man sich erst dann wieder erinnert, wenn es zu spät ist und die Programmdynamik eine rückwärtige Implementierung nicht, oder nur sehr schwierig zulässt.

So ging es mir mit einigen Ideen für Prepper Inventory. Bestimmte, bereits im ersten Teil erwähnte, Speicherverfahren sind auf Smartphones entweder nicht möglich, nicht ohne weiteres interpretierbar, oder, wie bei einem SQL Server, schlichtweg nicht praktikabel oder sicher genug.

Daher wurde die Speichermethode relativ “schnell” klar.

Erkenntnis

Durch den Multiuserzugriff flog die SQLite Datenbank bereits raus. Selbst wenn ich die Zugriffe limitieren würde und eine “Queue”, also eine Warteschlange hinzufügen würde, wäre der Zugriff auf Dauer zu schwerfällig geworden. Ich habe nun einige Tests mit XML durchgeführt und muss sagen, dass die Suchfunktion etwas komplexer gestaltet werden muss, und auch sequenzielle Abfragen komplett von Prepper Inventory gehandhabt werden müssen, aber der Zugriff, sowie die Suche ist schnell und in dem mir vorschwebenden Modell ist eine Zugriffsverletzung auch eher unwahrscheinlich.

Des Weiteren ist es möglich, den gesamten Ordner einfach auf einen USB Stick zu ziehen und von dort aus zu verwenden. Das geht bei einer lokalen SQL Installation nicht. Bei SQLITE würde das funktionieren, jedoch ist der Datendurchsatz eines USB Sticks nicht unbedingt für solcherlei Aufgaben ausgelegt, wodurch sich die Abfragen noch weiter verzögern könnten.

Die anderen Textbasierten Speichermethoden wären zwar in die engere Auswahl gekommen, allerdings bräuchte ich dafür spezielle Parser, die ich zum größten Teil selber schreiben müsste. Da sind mir Boardmittel lieber, zumal sie einem Din-Standard folgen, was die Weiterentwicklung für andere Programmierer einfacher machen dürfte.

Daher wird für Prepper Inventory nun folgendes Speichermodell verwendet:

And the winner is… XML

Wie bereits erwähnt kann XML relativ einfach durchsucht werden. Das biss sich jedoch mit meinem Kategorie-Management. Nun erstelle ich für jede Kategorie einen Ordner. In diesen wird eine vorher in Prepper Inventory definierte Schema Datei erstellt, welche die Felder, Controls und Eigenschaften dieser Kategorie enthält. Es wird quasi die vorher definierte Form gespeichert und anschließend neu generiert. Hierbei sollen Abstände und Größen variabel sein und mit einem Editor geändert werden können.

Eine Übersicht und, wie ich finde, sehr gute Erklärung was XML überhaupt ist findet ihr hier.

Weiterhin befinden sich in den Kategorieordnern die Gegenstände, welche gespeichert werden. Sollte wie beim Messer in der Kategorie nun Werkzeug und Waffe stehen, so wird dieser Eintrag Zwei mal vorgenommen.

Was mir noch nicht ganz klar ist, ist die Auswahl der Kategorie bei den Abfragen. Möchte ich beispielsweise wissen wie viele Metallgegenstände ich habe, so wird das Messer in diesem Fall doppelt gezählt. Das kann man mit einer ID oder Kategorieabfrage lösen. Problematisch wird es, wenn ich die Eigenschaft wissen möchte, welche für das Messer als Waffe von Relevanz ist, jedoch nicht als Werkzeug. Tötungsgrad beispielsweise. Wenn ich vorher keine Suchkategorie definiere, wird das Messer zwar als Waffe erkannt, jedoch hat es keine Eigenschaft die so heißt. Da wird ein wenig Hirnschmalz benötigt um alle Eventualitäten sauber abzusichern.

Hier eine kurze Vorstellung meinerseits:

XML Workflow

Igitt ein Spinnennnetz

Man sieht den Hauptordner „Prepper Inventory“.

Dieser hat aktuell 3 Unterordner.

  • Kategorien
  • Data
  • Config

Data enthält die benötigten .dlls und Klassen die wir im Laufe der Zeit entwickeln. Gegebenenfalls noch einen Pluginordner.

Config enthält neben der Userconfig auch noch einige Konfigurationen für die Darstellung und gegebenenfalls Verbindungsinformationen. Ich bin mir jedoch sicher, dass wir einiges ins Programm selbst schreiben müssen. Hier sollen auch die Custom-Imports für die Suche hin kommen. Sinn ist, dass ein String oder ein Ordner von User A aus dem Programm exportiert wird, sodass User B diese Suche nutzen kann um meinetwegen den gesamten Nährwert seines Lebensmittelvorrates zu erhalten. Wie genau ich das durchsetze weiß ich allerdings noch nicht. Da muss ich einige „Best Practice“ studieren. Ich halte euch dahingehend aber auf dem Laufenden.

Der Ordner „Kategorien“ enthält den Ansi-Code für Windows und das Tastaturlayout.

Nein natürlich nicht. In den Kategorien werden die einzelnen Ordner gepackt. Dabei enthält jeder Kategorieordner neben den (Teils doppelten) Gegenständen eine Schema Datei.

Diese beinhaltet die verwendeten Controls wie Textbox, Button, Combobox etc. Sie repräsentiert quasi das Kategoriefenster und bestimmt wie die Daten dargestellt werden.

Etwas Sorgen bereitet mir die Darstellung bei verschiedenen Auflösungen. Man kann die Daten nämlich nur „fix“ in Pixel eingeben. andernfalls sind Berechnungen notwendig. Außerdem kann es sein, dass eine Kategorie zu viele Datenfelder enthält um auf kleinen Bildschirmen dargestellt zu werden. Das wird mit Sicherheit eine Herausforderung.

Nicht das Ziel aus den Augen verlieren

Unser Hauptziel soll jedoch nicht nur die Inventarisierung sein, sondern auch die Auswertung dieser Dinge. Das bedeutet, dass ich die Eigenschaften dem Endanwender bekannt machen muss, damit dieser brauchbare Informationen und Vergleiche anstellen kann. Auch wenn dieses System mehr könnte, sollte man sich erst einmal auf das Wesentliche konzentrieren und eventuelle spätere Ideen auch später umsetzen.

Jetzt, da wir uns das Grundkonzept und die technischen Möglichkeiten überlegt haben, wissen wir, was für ein Aufwand auf uns zukommt. Die Zeit die wir für die Suchoptionen investieren müssen, ist durch die XML Entscheidung extrem angestiegen, dürfte sich bei sauberer Programmierung jedoch lohnen.

Im nächsten Schritt geht es dann ans Layout.

 


-- Download XML macht das Rennen Tagebuch eines Entwicklers Teil 2 als PDF --


Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.