Schlagwort-Archive: FireMonkey

Firemonkey App Framework FAF (1)

For over two years now I am working on a framework for my mobile projects .
Why another „Framework“ ? Just want to make my work easier, FAF allows me to setup a working, deployable prototype of an app within less than an hour.

  • Using App- and ViewController (extendable to MVC).
  • Every view comes with an container form inherited from a common base form for easy design per platform (+ IUIView interface).
  • A view can be „fullscreen“ (thus hiding content of Mainform) or embedded.
  • Standard Views are Splash, Setup, Login, Settings, Main (in contrast to Application.Mainform)
  • MainForm comes with TMultiView Menu and a basic IMainView interface
  • On startup for every view a TViewInfo is registered.
  • At runtime the view’s content layout is assigned the main form container as parent
  • Views can be closed or stacked (hidden)n controlled by a TUIViewController with a  TUIViewStack.
  • Templates for views like Splash, Login, Setup, Settings, Main etc
  • Very basic preparations for multi language
  • Local storage for data

Working on

  • (Better) usage of TMultiView Menu
  • Global Color and Font Settings via Code, XML, JSON etc
  • Core Structure for MVC and / or MVVM
  • Dependency Injection Container / IoC
  • More View Templates
  • Multi Language
  • etc. (enough ideas)

I have a version with a DependencyInjection container but so far any code in the implementation section did not work properly. Still checking.

Due to bugs not working in 10.1 Berlin properly.

 

Delphi 10.1 Berlin THTTPClient Trouble (2)

Ok, switching to english for recapitulation

  1. Response.ContenAsString now checks for Content-Encoding = gzip and uses a compression stream (did make app crash)
  2. With AcceptEncoding = identity it can be avoided that a server adds this encoding
  3. It doesn’t matter what Encoding, Charset etc is set always get an EEncodingError querying IHTTPResponse.ContentAsString
    after successful POST (works in 10.0)
    (Embarcadero QC RSP-14300)
  4. Instead using IHTTPResponse.ContentAsString passing a TStringStream with HTTPClient.Post then
    no exception and StringStream.DataString is readable without any problem
  5. But final problem: Response delivers HTML and no JSON anymoreNow checking server side first if there is a problem before passing another bug report.
  6. My customer detected the reason:
    In Delphi 10.0 HTTPClient managed cookies from server login „behind the scene“ and sent it with every post..
    Proof: Setting HTTPClient.AllowCookies := False and an app does not work.
    In Delphi 10.1 Berlin this has changed, now there has to be added before a HTTPClient.Post
    HTTPClient.CustomHeaders[‚Cookie‘] := ‚WebBrokerSessionId=‘ + FSessionID;
    Otherwise any test app does not work.
    Removing such an automatism like this is a bug, time for another report. (Embarcadero QC RSP-14301)

 

Delphi 10.1 Berlin :: Problems with changed Fonts (Bug or Feature ?)

Just realized by going through the forms of an actual project that the font of TLabel was changed.
In the original app neither style nor anything else concerning fonts was changed but any added label uses a different font (style) now.

Screenshots show the difference

Delphi 10.0 New Form with Label

Delphi 10.0 New Form with Label (Android)

Delphi 10.0 Base Form with new Label

Delphi 10.0 App Base Form with new Label (Android)

Delphi 10.1 New Form with Label (Android)

Delphi 10.1 New Form with Label (Android)

Delphi 10.1 Base Form with Label (Android)

Delphi 10.1 App Base Form with Label (Android)

(to be continued … may be)

Delphi 10.1 Berlin THTTPClient Trouble

Ein KO Kriterium für den Einsatz von Delphi 10.1 war eine Exception vom Typ EZCompressionError in einem FMX Projekt, welches mit Delphi 10.0 einwandfrei funktioniert.

Bei der Ursachensuche musste ich feststellen, dass die Interna von THTTPClient – und allem was damit zusammenhängt – sich grundlegend geändert haben:
In IHTTPResponse.ContentAsString wird jetzt z.B. das „Content-Encoding“ abgefragt und falls dieses „gzip“ ist, wird ein Compression Stream für die Ausgabe erzeugt, in 10.0. wurde das „Content-Encoding“ ignoriert. Und da kracht es gleich beim Login.
Mit HTTPClient.AcceptEncoding := ‚identity‘ war das Problem erstmal vom Tisch (womit jedes serverseitige Encoding  unterbunden wird).

Das nächste Probleme:
Egal welches Encoding, Charset etc, beim Abruf der JSON Daten vom Server, wenn intern die Streams umkopiert werden, kommt immer die Exception EEncodingError „Keine Zuordnung für Unicode-Zeichen in der Multibyte-Zielcodeseite vorhanden“. (Es ist egal, was für das Encoding angegeben ist: serverseitig ANSI)

Nach langem Hin und Her und einigen Stunden Debugging:
Wenn entweder ein Stream im HTTPClient.Post() für den Response übergeben oder Response.ContentStream abgefragt wird (in TStringStream umkopieren), dann klappt das ohne Exception und es gibt lesbaren Response String.
Aber: Der Response enthält keine JSON Daten sondern HTML! Was geht nun schief ?
Fiddler zeigt alles als korrekt an, das Sever Log zeigt keine (offensichtlichen) Fehler.

Negativ ist in diesem Zusammenhang die Hilfe aufgefallen: Ich bin da auf zu viele Einträge mit “ … zu diesem Zeitpunkt keine weiteren Informationen“ gestossen.

Fortsetzung folgt (wahrscheinlich, nicht garantiert)