Ja danke, ich habe mich gut erholt, und arbeite gerade hart daran, dass das so bleibt 
Zum Thema:
Ich habe gerade nochmal ein paar Recherchen angestellt und danach, auf der Terrasse sitzend, mit einer Flasche Kronen Pils und einem Schuss Fanta über die Geschichte meditiert.
Zunächst ist zu sagen, dass die eigentliche Suche - also der Teil, der im Datenbankserver (bzw. SQLite) abläuft - doch relativ schnell ist. Eine Suche nach “the” in einer Datenbank mit ca. 100.000 Titeln dauert nur 1-2 Sekunden. Der jetzige Zeitaufwand entsteht also nur bei der Verarbeitung der Ergebnisse. Hier muss man grundlegend zwischen der mAirListDB-Verwaltung und mAirList selbst unterscheiden:
In der Datenbankverwaltung ist das ListView-Objekt (genauer: Virtual Treeview, aber das spielt hier keine Rolle) in der GUI direkt mit dem ResultSet der Datenbank verbunden. Das heißt unter anderem, die Details (Titel, Interpret, Länge; mehr wird zunächst nicht abgefragt) werden erst übertragen, wenn sie benötigt werden, wenn man also in der Liste zu dem fraglichen Element scrollt. Daher dauert die Suche dort nur 3-4 Sekunden, die Verzögerungen beim Herunterblättern sind kaum wahrnehmbar.
Bei mAirList selbst sieht es anders aus. Hier ist eine direkte Verknüpfung zwischen dem ListView und dem SQL-ResultSet nicht möglich. Allein schon deshalb, weil es sich ja nicht bei allen Datenbanken um SQL-Datenbanken handelt (siehe: iTunes). Daher wird hier ein anderer Weg eingeschlagen: Es werden zunächst nur die IDs der passenden Titel ermittelt, und dann werden für jeden Titel mit weiteren SQL-Anfragen die Details aus der Datenbank gefischt. Und diesmal wirklich alle - heraus kommt jeweils ein vollständiges PlaylistItem. Die Ergebnisse werden dann mit den PlaylistItems aus den anderen Datenbanken (wenn man in allen gleichzeitig sucht) in eine Gesamt-“Playlist” zusammengeführt und angezeigt (das verwendete ListView-Objekt ist identisch mit dem, was z.B. für die Darstellung des Container-Inhalts oder des Papierkorbs verwendet wird).
Der zweite Schritt - das Ermitteln der Details für jeden Treffer, um jeweils ein vollwertiges PlaylistItem aufzubauen - ist derjenige, der Zeit kostet. Hier muss ich ansetzen.
Ich sehe zwei Lösungsmöglichkeiten, die unterschiedliche Auswirkungen auf die Bedienung und Usability haben, und die ich daher hier zur Diskussion stellen möchte:
-
Es wird wie bisher zunächst nur die Liste der IDs aus der Datenbank geladen. Diese wird an einen Hintergrundthread übergeben, der nun nach und nach die PlaylistItems erzeugt und in die Ergebnisliste einträgt. Anders als bisher geschieht das allerdings im Hintergrund, mAirList bleibt also weiter bedienbar, der Benutzer sieht, wie sich die Einträge nach und nach aufbauen, und der Vorgang lässt sich im Zweifel auch einfach abbrechen. Tut man es nicht, dauert es ähnlich lange wie jetzt, bis alle Ergebnisse vorliegen. Es ist weiterhin möglich, alle Datenbanken gleichzeitig zu durchsuchen.
-
Ich ermögliche - durch eine zusätzliche Abstraktionsschicht - eine direkte Ankopplung des ListViews an das SQL-ResultSet. Es werden erst nur Titel, Interpret und Länge aus der Datenbank geholt, die eigentlichen PlaylistItems werden erst dann erzeugt, wenn man ein Element tatsächlich verwendet. Die Performance entspräche in etwa dem, was wir jetzt schon bei der Suche in der Verwaltungssoftware haben: In meinen Tests ca. 4-5 Sekunden, in denen allerdings die GUI hängt. Allerdings kann man dann nur noch in einer Datenbank auf einmal suchen.
Ich bin etwas unentschlossen, welche der Möglichkeiten ich bevorzuge. Ich tendiere zu Nummer 1. Vor allem ist die leichter zu implementieren, weil weniger Änderungen am Browser vorzunehmen sind. Der Nachteil ist, dass die Suche “bis zum bitteren Ende” noch immer genauso lange dauern kann wie jetzt. Man darf sich aber die Frage stellen, wie sinnvoll eine Suche ist, die zigtausend unübersichtliche Ergebnisse zurückliefert. Wenn der Benutzer sieht, dass die Liste zu lang wird, wird er die Such eher abbrechen (das ist dann möglich) und den Suchbegriff verfeinern.
Was denkt ihr?
Dann darf ich mir folgende Anmerkung erlauben: Ich habe gestern gesehen, was passiert, wenn man bei dem System mit dem Z am Anfang eine Suchanfrage startet, die zu viele Ergebnisse zurückliefert. Das fällt für mich unter “Möglichkeit 3” und steht nicht zu Diskussion