Viele Dateien bereitstellen

[greenmile]

In meinem aktuellen Projekt muss ich für einen Produktkatalog, der unter Android/iOS laufen soll, ca 500 Bilddateien bereitstellen; die müssen leider mitinstalliert werden, können also nicht per HTTP von irgendeinem Server abgerufen werden. Ich kann diese Dateien ja über das Menü "Projekt" / "Bereitstellung" einbinden ... Allerdings dauert das bei 500 Dateien schon ne ganze Weile, anschließend muss ich dann noch für jede der Dateien jeweils für iOS und für Android den jeweiligen Remote-Pfad eingeben. Also jeden Eintrag doppelt anklicken, rechte Maustaste und den Pfad einfügen (STRG+V funktioniert da leider genauso wenig wie Mehrfach-Auswahl).

Gibt es eine einfachere Möglichkeit? Da sitze ich ja ewig dran :?

[Sir Rufo]

Pack den ganzen "Rotz" in eine Datei (zip oder simpler Stream mit Index) und stelle nur diese eine Datei bereit.

[greenmile]

Die Idee hatte ich auch schon, also dass ich die ZIP ja mitgeben kann und beim Start in ein eigenes Unterverzeichnis entpacke, wenn es das noch nicht gibt. Ist nur die Frage: Überleben die Verzeichnisse unterhalb von "assets\internal\" bzw. "StartUp\Documents\" ein Beenden bzw. Updaten der App? Das habe ich noch nicht so ganz kapiert, also den Unterschied von assets und assets\internal.

[Dejan Vu]

Kann SQLite mit BLOB's umgehen? Wenn ja...: Tadaa.

[greenmile]

Zitat:

Zitat von Dejan Vu (Beitrag 1260006)

Kann SQLite mit BLOB's umgehen? Wenn ja...: Tadaa.

Du speicherst nicht ernsthaft binäre Dateien in BLOB's? Also, nichts für ungut, aber wärst Du mein Azubi, dann würde es dafür (und nur dafür) ein - geben.

[Sir Rufo]

Ich würde die gar nicht entpacken, sondern direkt aus dem Stream herauslesen.

Zum Starten den Index aus dem Stream lesen und dann mit diesem direkt darauf zugreifen.
Bilder, die schon einmal aus dem Stream geladen wurden einfach als Instanz im Speicher cachen.
Wenn dann die Benachrichtigung "Memory low" kommt, einfach diesen Cache wieder reduzieren bzw. komplett entleeren.

Siehe dazu auch das Flyweight-Pattern

[Perlsau]

Zitat:

Zitat von greenmile (Beitrag 1260008)

Zitat:

Zitat von Dejan Vu (Beitrag 1260006)

Kann SQLite mit BLOB's umgehen? Wenn ja...: Tadaa.

Du speicherst nicht ernsthaft binäre Dateien in BLOB's? Also, nichts für ungut, aber wärst Du mein Azubi, dann würde es dafür (und nur dafür) ein - geben.

Mein lieber GreenMile, auch ich speichere in etlichen Anwendungen zahlreiche Bilddateien in Blobfeldern einer Firebird-Datenbank. Bei einem Kunden sind das nach inzwischen gut fünf Jahren Einsatz der Anwendung über 30.000 Bilddateien geworden, die noch immer sauber und fehlerfrei in der Anwendung zur Verfügung stehen und sich jederzeit auf jeden beliebigen Datenträger mit einem Klick speichern lassen.

Welche Probleme sollte es deiner Meinung denn bereiten, Bilddateien in einer Datenbank zu verwahren?

Im Übrigen vergraulst du dir hilfsbereite User, wenn du hier ständig auf dein Alter und deine angebliche Erfahrung pochst und gleichzeitig versuchst, gutgemeinte Tippgeber herabzuwürdigen, indem du ihnen beispielsweise vorführst, wie du am liebsten mit ihnen umspringen würdest. Das ist ähnlich beleidigend wie der Spruch meiner ältlichen Nachbarin, als ich vor 10 Jahren mit ziemlich langen Haaren in diese Wohnung eingezogen war und angeglich die Treppe im Hausflur nicht ausreichend gründlich gewischt hatte: "Wären Sie mein Sohn, würde ich's Ihnen schon zeigen ..." Dabei ist die "Dame" vielleicht gerade mal 10 Jahre älter als ich. Später stellte sich heraus, daß ihr Jüngster (gut 30 Jahre jünger als ich) ein ziemlich verzogener Bengel ist, der wohl auch schon mit dem Gesetz in Konflikt stand. Mein anfänglicher Verdacht einer typischen Projektion hatte sich bestätigt.

Im Übrigen scheint es mit deinen Programmierkenntnissen doch nicht so weit her zu sein, wenn du ein Zip-Archiv erst einmal "in ein eigenes Unterverzeichnis entpacke"n willst, bevor du auf die darin befindlichen Bild-Dateien zu- oder lieber gleich auf typisierte Dateien zurückgreifst, weil du nicht gut mit Datenbanken kannst. Ich kann mich des Eindrucks nicht erwehren, daß du hier ein Selbstwert- und Autoritätsproblem auszutragen und mit deinem Gehabe zu kompensieren suchst, das im Grunde hier nicht hergehört: Du bist hier nicht in deinem Ausbildungsbetrieb der Chef und die Autoritätsperson, sondern einer unter Gleichen, weshalb man sich auch auf Augenhöhe begegnen sollte, ohne jede Selbsterhöhung, Selbstbeweihräucherung und Herabsetzung vermeintlich Jüngerer (sagt dir ein selbständiger Entwickler Jahrgang '60 ohne Azubis).

[jaenicke]

Bei Datenbanken wie MS SQL oder Firebird kann man problemlos dafür Blob-Felder nutzen. Die mit Delphi mitgelieferten Beispieldatenbanken enthielten übrigens die Fischbilder auch. (Die aktuellen Beispiele habe ich mir schon länger nicht mehr angeschaut, kA wie das heute ist.)

SQLite hingegen ist dafür leider nicht gut geeignet, auch wenn es theoretisch geht. Einerseits gibt es Probleme mit bestimmten Zeichen, so dass diese kodiert werden müssen, andererseits wird es nicht empfohlen größere binäre Daten abzulegen und die Limits sind auch relativ gering.

[Bernhard Geyer]

Zitat:

Zitat von Perlsau (Beitrag 1260016)

Zitat:

Zitat von greenmile (Beitrag 1260008)

Zitat:

Zitat von Dejan Vu (Beitrag 1260006)

Kann SQLite mit BLOB's umgehen? Wenn ja...: Tadaa.

Du speicherst nicht ernsthaft binäre Dateien in BLOB's? Also, nichts für ungut, aber wärst Du mein Azubi, dann würde es dafür (und nur dafür) ein - geben.

Mein lieber GreenMile, auch ich speichere in etlichen Anwendungen zahlreiche Bilddateien in Blobfeldern einer Firebird-Datenbank. Bei einem Kunden sind das nach inzwischen gut fünf Jahren Einsatz der Anwendung über 30.000 Bilddateien geworden, die noch immer sauber und fehlerfrei in der Anwendung zur Verfügung stehen und sich jederzeit auf jeden beliebigen Datenträger mit einem Klick speichern lassen.

Binärdateien (Bilder und Co.) in DBs zu speichern ist kein Problem. Und wenn ich mich erinnere gab es schön gefühlt 2000 Diskussionen die sich mit dem Thema "Soll man (Binär)Dateien in der Datenbank speichern oder doch nur Referenzen auf die eigentlichen Dateien darauf speichern. Das Ergebnis war fast immer: Es kommt darauf an.
Wir selbst speichern auch Bilddateien in der DB. Exedateien dagegen nicht.


@Dejan Vu: Bei SQLite kommt das auf die Menge der Bilder an und wie schnell (viel in kurzer Zeit) du sie benötigst. Gegenüber anderen DBMS war (vor 3-4 Jahren)SQLite erheblich langsamer bei BLOB-Feldern diese zu speichern.

[Dejan Vu]

Zitat:

Zitat von greenmile (Beitrag 1260008)

Du speicherst nicht ernsthaft binäre Dateien in BLOB's? Also, nichts für ungut, aber wärst Du mein Azubi, dann würde es dafür (und nur dafür) ein - geben.

Sagt der, der typisierte Dateien verwendet. ;-)
Allerdings wüsste jetzt auch konkret nicht, was ich großartig Anderes als binäre Dateien in einem BLOB (binary large object) ablegen sollte. Ich meine, irgendwie impliziert der Name, das das nicht ganz falsch sein kann.

Vielleicht hältst Du dich mit bewertenden Äußerungen gegenüber anderen in Zukunft etwas zurück. Es wäre denkbar, das Du dich damit zu weit aus dem Fenster legst und bei zwei Versuchen ist es ja auch zweimal ein Eigentor geworden.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1260055)

Bei SQLite kommt das auf die Menge der Bilder an und wie schnell (viel in kurzer Zeit) du sie benötigst. Gegenüber anderen DBMS war (vor 3-4 Jahren)SQLite erheblich langsamer bei BLOB-Feldern diese zu speichern.

Ich würde das im konkreten Fall auch erst einmal testen. Aber Du schreibst, das die Performance beim *speichern* schlecht ist. Hier soll aber *gelesen* werden. Wie verhält sich das mit der Performance dann?

Als Container für binäre Daten wird es vermutlich brauchbar sein, für den schnellen Zugriff ist es vielleicht nur bedingt geeignet (wie gesagt: Probieren). Der wahlfreie Zugriff ist aber das Entscheidende (als Alternative zu einem Dateisystem).

Gewiss: Irgend eine andere structured storage engine würde es genauso tun, aber wenn man schon bei SQLite ist und das offensichtlicher Industriestandard im Tabletsektor ist, sollte man sich das vielleicht mal anschauen.

Edit:
Nichts ersetzt eigene Versuche, aber SQLite kennt die Frage wohl schon:
http://www.sqlite.org/intern-v-extern-blob.html

Natürlich ist das nicht auf einem Tablet, sondern einer Linux-Büchse, aber es zeigt schon, das es eine Alternative zu sein scheint. Es kommt hier ausnahmsweise mal auf die Größe an.