BufferedReader in Firemonkey?

[blackdrake]

Hallo,

ich habe das Problem, dass ich bei einem Android-Projekt die Java-Klasse "BufferedReader" und "InputStreamReader" verwenden möchte, um einen InputStream blockierungsfrei Zeile für Zeile lesen zu können. Ich finde aber im Internet keine Anleitung, wie das geht.

Das Problem wurde schon hier beschrieben, hat allerdings auch keine Antwort bekommen . Bei der Google-Suche "Delphi JBufferedReader" findet sich - außer meiner Frage - nur 1 Ergebnis in Google - also scheine ich der einzigste Mensch auf der Erde zu sein, der Firemonkey benutzt und einen Stream gepuffert Zeile für Zeile lesen möchte. Im Allgemeinen bin ich sehr enttäuscht, dass man bei Firemonkey im Internet kaum Hilfestellungen findet, und auch die Hilfe von Embarcadero ist nicht zu gebrauchen :-(

Hier mal ein Versuch, die JNI zu verwenden. Stürzt aber bereits beim Konstruktor ab; ich weiß nicht, was falsch ist.

Delphi-Quellcode:

type
  JBufferedReaderClass = interface(JObjectClass)
  end;

  [JavaSignature('java/io/BufferedReader')]
  JBufferedReader = interface(JObject)
    function readLine : JString; cdecl;
  end;

  TJBufferedReader = class(TJavaGenericImport<JBufferedReaderClass, JBufferedReader>)
  end;

procedure TForm1.Button1Click(Sender: TObject);
var
  x: JBufferedReader;
begin
  x := TJBufferedReader.Create; // <-- Segmentation fault
end;

Über Hilfestellungen, insbesondere, wie man beliebige Java-APIs in Delphi per JNI inkludiert, wäre ich sehr dankbar.

[mkinzler]

Nicht

Delphi-Quellcode:

var
  x: TJBufferedReader;

?

[blackdrake]

Hallo,

wenn ich das verwende, kommt bei folgender Zeile ein Kompilierfehler:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  x: TJBufferedReader;
begin
  x := TJBufferedReader.Create; // [DCC Error] Unit1.pas(50): E2010 Incompatible types: 'TJBufferedReader' and 'JBufferedReader'
end;

[blackdrake]

Ich denke mir, dass es auch damit zusammenhängen könnte, dass der Konstruktor von BufferedReader ja Argumente erfordert

Der Konstruktor müsste also wahrlichlich so aussehen:

Delphi-Quellcode:

constructor Create(Ain: JReader);

... allerdings kann ein Interface keinen Konstruktor haben ...

[Sir Rufo]

Also bei mir geht sowas immer so

Delphi-Quellcode:

function GetConnectivityManager: JConnectivityManager;
var
  ConnectivityServiceNative: JObject;
begin
  ConnectivityServiceNative := SharedActivityContext.getSystemService( TJContext.JavaClass.CONNECTIVITY_SERVICE );

  if not Assigned( ConnectivityServiceNative )
  then
    raise Exception.Create( 'Could not locate Connectivity Service' );

  Result := TJConnectivityManager.Wrap( ( ConnectivityServiceNative as ILocalObject ).GetObjectID );

  if not Assigned( Result )
  then
    raise Exception.Create( 'Could not access Connectivity Manager' );
end;

[mkinzler]

Ich habe den JNI Wrapper mal mit Java2Op erzeugen lassen. Die Konstruktoren sind als init-Methoden implementiert.

Delphi-Quellcode:

{*******************************************************}
{                                                       }
{           CodeGear Delphi Runtime Library             }
{ Copyright(c) 2014 Embarcadero Technologies, Inc.      }
{                                                       }
{*******************************************************}

unit Androidapi.JNI.java.io.BufferedReader;

interface

uses
  Androidapi.JNIBridge,
  Androidapi.JNI.JavaTypes;

type
// ===== Forward declarations =====

  JBufferedReader = interface;//java.io.BufferedReader

// ===== Interface declarations =====

  JBufferedReaderClass = interface(JReaderClass)
    ['{ED860F80-BCB7-4BC0-977F-95DE9CACE248}']
    {class} function init(in_: JReader): JBufferedReader; cdecl; overload;
    {class} function init(in_: JReader; size: Integer): JBufferedReader; cdecl; overload;
  end;

  [JavaSignature('java/io/BufferedReader')]
  JBufferedReader = interface(JReader)
    ['{81A25906-BC48-4F21-B1D4-5FDA81218C63}']
    procedure close; cdecl;
    procedure mark(markLimit: Integer); cdecl;
    function markSupported: Boolean; cdecl;
    function read: Integer; cdecl; overload;
    function read(buffer: TJavaArray<Char>; offset: Integer; length: Integer): Integer; cdecl; overload;
    function readLine: JString; cdecl;
    function ready: Boolean; cdecl;
    procedure reset; cdecl;
    function skip(charCount: Int64): Int64; cdecl;
  end;
  TJBufferedReader = class(TJavaGenericImport<JBufferedReaderClass, JBufferedReader>) end;

implementation

procedure RegisterTypes;
begin
  TRegTypes.RegisterType('Androidapi.JNI.Interfaces.JBufferedReader', TypeInfo(Androidapi.JNI.Interfaces.JBufferedReader));
end;

initialization
  RegisterTypes;
end.

[Mavarik]

OK und jetzt nochmal zum mitschreiben bitte...

Wofür das ganze "geraffel" mit Java?

In der Zeit wo Du das gegoogled hast hättest Du das 3x schon in Delphi programmiert...

Versteh ich nicht...

Mavarik

[mjustin]

Zitat:

Zitat von Mavarik (Beitrag 1282918)

Wofür das ganze "geraffel" mit Java?
In der Zeit wo Du das gegoogled hast hättest Du das 3x schon in Delphi programmiert...

Die verlinkte Frage besagt ja, dass ein JInputStream (wo der jetzt her kommt ist wird nicht erläutert) über einen BufferedReader gelesen werden soll. Keiner mir bekannten Delphi Stream-Funktion kann man einen JInputStream als (z.B. Konstruktor-) Argument übergeben...

[Mavarik]

Zitat:

Zitat von mjustin (Beitrag 1282919)

über einen BufferedReader gelesen werden soll.

Von "gelesen werden soll" war keine Rede, sondern

Zitat:

Zitat von blackdrake (Beitrag 1282896)

die Java-Klasse "BufferedReader" und "InputStreamReader" verwenden möchte, um einen InputStream blockierungsfrei Zeile für Zeile lesen zu können.

Hierbei geht es für mich in erster Linie um die Funktionalität eines blockungsfreien Lesens...
Daher meine Antwort schreib es doch schnell in Delphi!

Mavarik

[blackdrake]

Vielen Dank für den Hinweis mit Java2OP! Ich habe dieses Tool noch nicht gekannt - hätte nicht gedacht, dass das Verwenden der Android API so einfach sein kann :)


Bzgl. "Blockierungsfrei lesen selbst programmieren" - das habe ich schon versucht. Allerdings ging das (wie in StackOverflow beschrieben) nur mit der JInputStream.available() Funktion, die laut Javadokumentation nicht für diesen Zweck verwendet werden soll, da der Wert nur eine grobe Schätzung ist - in der Tat haben manche Geräte wegen der schlechten Schätzung dauerhaft blockiert oder nie gelesen, da available() bei manchen Geräten immer 0 oder immer >0 war.

Daher war meine Absicht, den BufferedReader zu verwenden, da das die einzige saubere Möglichkeit ist, einen Stream zuverlässig blockierungsfrei zu lesen.

Der Vollständigkeit halber meinen alten Code, der wegen der schlechten Schätzung von available() nicht auf allen Geräten läuft:

Delphi-Quellcode:

var // of TBufLineJStream
  buf: TJavaArray<Byte>;
  FStream: JInputStream;
  FCurIncompleteString: String;
  FReadLines: TQueue<String>;

const // of TBufLineJStream
  BufferSize = 65536;

procedure TBufLineJStream._ReadFromStream;
var
  c: Char;
  i, readCount: integer;
begin
  while FStream.available > 0 do
  begin
    readCount := FStream.read(buf, 0, BufferSize);
    for i := 0 to readCount-1 do
    begin
      c := Chr(buf.Items[i]);
      if c = #13 then
      begin
        // The line is complete
        FReadLines.Enqueue(FCurIncompleteString);
        FCurIncompleteString := '';
      end
      else
      begin
        // The line is not complete yet
        FCurIncompleteString := FCurIncompleteString + c;
      end;
    end;
  end;
end;

function TBufLineJStream.ReadLineNonBlocking(var outStr: string): boolean;
begin
  _ReadFromStream;

  result := FReadLines.Count > 0;
  if result then outStr := FReadLines.Dequeue;
end;

Die Dokumentation von Java warnt vor eer Verwendung von available() um blockierungsfreies Lesen zu realisieren:

Zitat:

[...]

Note that this method provides such a weak guarantee that it is not very useful in practice.

Firstly, the guarantee is "without blocking for more input" rather than "without blocking": a read may still block waiting for I/O to complete — [...]

[...]

The default implementation of this method in InputStream always returns 0. Subclasses should override this method if they are able to indicate the number of bytes available.