Mit Android APP auf ein SDCard Ordner zugreifen

[tdeck]

Hallo Leute,

ich wollte meinen Kunden eigentlich die Möglichkeit geben auf einen Ordner in der SD-Card via TOpenDialog() und TSaveDialog() auf dortige Dateien zu zugreifen, um CFG-Dateien und Logbücher von unseren Steuerungen abzulegen.
Die Permissions sind gesetzt, die Meldung zum bestätigen kam auch.

Jetzt habe ich in einigen Foren gelesen, diese Dialoge funktionieren nur unter Windows/IOS.
Aber in den Angaben der Hilfe steht davon nichts! Es kann doch nicht sein, dass eine Entwicklungsoberfläche wie Embarcadero sowas nicht richtig eingebaut hat? Oder etwa doch?
Muss man sich diesen Dateibrowser wirklich komplett selbst für Android zusammenbauen?

Oder gibt es dafür eine passende Komponente, wenn Sie gut funktioniert darf sie auch entsprechend kosten.
Ich möchte mich bei meiner Programmierung eigentlich nicht mit solchen grundlegenden Dialogen beschäftigen, dafür habe ich
Embarcadero gekauft, damit ich mich damit nicht auseinander setzen muss (dachte ich).

Wir habt ihr das gelöst? Eine Ablage in GoogleDrive oder so bringt nichts, da in vielen Technikräumen bei dem Kunden keine Internetverbindung möglich ist, es sollte auf die SD-Card abgelegt und gelesen werden.

[Olli73]

Ich habe mir vor Jahren Mal so einen Dialog selber gebaut. Ob der unter aktuellen Android-Versionen noch funktioniert, weiß ich nicht. Die Zugriffe auf Speicher außerhalb der eigenen Anwendung soll ja komplizierter oder gar unmöglich geworden sein!?

[tdeck]

Zitat:

Zitat von Olli73 (Beitrag 1510804)

Ich habe mir vor Jahren Mal so einen Dialog selber gebaut. Ob der unter aktuellen Android-Versionen noch funktioniert, weiß ich nicht. Die Zugriffe auf Speicher außerhalb der eigenen Anwendung soll ja komplizierter oder gar unmöglich geworden sein!?

Hallo,

eigentlich nicht. Man muss nur die Permissions passend setzen, dann darf man auch auf die Speicher zugreifen. In den alten Androidversionen war das einfacher, aber mit der Komponente TMobilePermissions ist das recht einfach geworden.

Ich verstehe das halt nicht, ich suche schon den ganzen Tag nach einen passenden Ansatz.
Es gibt ein paar Lösungsansätze die aber eine JAVA-Jar-Bibliothek in Delphi einbinden und da dann den JAVA-Code als JAVA-Klasse aufrufen. Nur wenn ich damit anfange, kann ich gleich in JAVA das ganze fertig machen.

Thorsten

[tdeck]

Hallo Leute,

ich habe eine Lösung gefunden. Ich habe WinSoft.sk angeschrieben, von denen nutze ich auch schon die USB-Android-Lib für Delphi.
Machen klasse und saubere Arbeit, er hat in dem Paket "Utils library" eine entsprechende saubere Lösung.

In dem Demo Storage kann man es sich anschauen, perfekt! Alles was ich dazu brauche.

Nur schade das Embarcadero es nicht ordentlich hinbekommt (mal wieder "Halbfertige" Sachen), aber jeden Mist mit Python reinnehmen :-(

Thorsten

[TurboMagic]

Naja, so einfach ist das doch nicht. Stichwort ist scoped storage. Zumindest für den SharedDownloads Ordner.

Der systemeigene Dialog in Android, den EMBT Kapseln müsste liefert anders als der in Windows keinen Dateinamen zurück sondern irgend so einen Provider.

Und Filtern nach Dateiendungen geht nur für dem System bereits bekannte Mime Types. Eigene Dateiendungen müssen dann über */* oder so abgehandelt werden.

Soweit mein Stand. Damit wird das Kapseln zumindest erschwert. Alternativ müsste EMBT was komplett eigenes stricken.

[tdeck]

Hallo TurboMagic,

doch eigentlich schon :-D . Das war jetzt recht einfach, ein paar Stunden Arbeit und ich konnte mit der App die Dateien lesen und schreiben. Per Compiler-Anweisung schalte ich das öffnen/speichern der Datei zwischen Android und Windows als Ziel einfach um.

Code:

//---------------------------------------------------
// 27.08.2022
// V1.1967
// Android Ladefunktion eingefügt
//
procedure TForm1.BtnLadeCfgClick(Sender: TObject);
begin
  // Lade Config File
  //
  // Windows
  {$ifdef MSWINDOWS}
    // Öffnen der Datei mit TOpenDialog
    //
     WindLoadConfig;
  {$endif MSWINDOWS}

  // Android
  {$ifdef ANDROID}
    TDocument.Open(
      procedure (Document: TDocument)
      begin
        if Document <> nil then
        try
          // Debugausgabe
          AddLine('Path: ' + Document.Path);
          Addline('Anzahl Bytes: '+ IntToStr(High(Document.Read))  );
          AddLine('Content: ' + IntToHex(Document.Read[0]));

          // Datei prüfen und verarbeiten
          //
           AndroidGetConfig(Document.Read);

        finally
          Document.Free;
        end;
      end, '', '*/*');
   {$endif ANDROID}

end; // Ende BtnLadeCfg

Klar nutze ich jetzt erstmal keine eigene "Mime Types" (damit habe ich mich noch nicht beschäftigt), und starte die Dateiauswahl mit "*/*", damit habe ich aber kein Problem. Meine Kunden sind geschulte Techniker, die wissen welche Datei-Endungen geöffnet werden können. Die erstellten Dateien von mir haben ein bestimmtes Header in den ersten Bytes. Passen die nicht wird die Datei nicht verarbeitet und es gibt eine passende Meldung.

Klar wäre es sauberer wenn dies einfach mit dem FMX TOpenDialog/TSaveDialog gemacht werden könnte, dazu müsste aber Embarcadero da mal Hand anlegen.

Thorsten

[TurboMagic]

Hallo,

naja, wie geschrieben ist das mit dem hand anlegen hier nicht ganz so leicht, weil ja dein
Dokument Öffnen in Android (ich hatte das auch schon mal umgesetzt, keine Panik! ;-) )
gleich mit einem Dokument Objekt kommt und nicht wie TOpenDialog mit einem Dateinamen!

Zu den Mime-Types: soweit ich damals rausgefunden habe (lasse mich aber gerne von den
Ergebnissen deiner Nachforschungen eines besseren belehren!) kann man eigene Mime-Types
für den Zweck gar nicht wirklich definieren, es sei denn man definiert welche für den
Aufruf deiner App durch andere mittels Intent. Das kann für manche Apps nützlich sein,
aber sicher nicht für jede. Und selbst das definieren dafür war, wenn man den ganzen
StackOverflow Posts dazu glauben darf, auch nicht problemfrei oder richtig dokumentiert
oder es gab mal wieder komische Änderungen zwischen den Android Versionen.

Ich habe da manchmal den Eindruck, dass beim Android API manchmal von denen nicht
genügend nachgedacht wird, wer was wofür eigentlich braucht. Nur weil die was nicht
nützlich finden bedeutet es ja nicht, dass es andere nicht gebrauchen könnten.

Und anders als mit EMBT findet in deren Bugtracker auch keine wirklich sinnvolle
Kommunikation mit den Kunden statt!

Grüße
TurboMagic