Selbstverständlich darf auf der deuschen Coderage kein FMX Vortrag von mir/uns fehlen.
Key-Thema ist selbstverständlich das FDK und die Entwicklung von mobilen- und Desktopwendungen mit FMX.
Gerne nehmen wir im Vorfeld Themen auf, die wir in unserem Vortrag näher beleuchten sollen.
Anregungen bitte per e-Mail an Info@delphiprofi.de
Wednesday, June 1, 2016
Tuesday, May 31, 2016
Firemonkey & Form.KeyPreview
Wer hat nicht in Firemokey schon das Form.KeyPreview vermisst?
Der einfachste Workaround hierfür ist:
type
TForm1 = class( TForm )
private
{ Private-Deklarationen }
protected
procedure IsDialogKey(const Key: Word;
const KeyChar: WideChar;
const Shift: TShiftState;
var IsDialog: boolean); override;
public
{ Public-Deklarationen }
end;
Aber nicht den inherited vergessen!
Saturday, May 28, 2016
FDK - E-Mails - Serverfehler!
Leider hatte sich ein Konfigurationsfehler in meinem E-Mail-Server eingeschlichen, daher sind alle mails an Info@delphiprofi.de leider verloren gegangen.
Falls also keine Antwort zurückgekommen ist, bitte nochmal schreiben...
Sorry
Falls also keine Antwort zurückgekommen ist, bitte nochmal schreiben...
Sorry
Monday, May 23, 2016
MVVM - Oder was ich dafür halte...
Mit diesem Satz beginne ich eigentlich immer, wenn ich über MVVM spreche...
Angefangen hat es hiermit und nun? Natürlich bin ich ein gutes Stück weiter, aber gerade habe ich ein Video von 2014 (Visual Studio Tollbox / channel8.msdn.com / MVVM Best Practices ) gefunden... Die beste Aussage aus dem Video ist zwischen 02:45 - 03:45.
"Egal" wie man es nennt... Es geht um ein Pattern - wie auch immer man es implementiert.
Trotzdem habe ich mich jetzt daran gewöhnt die drei Jungs beim "richtigen" Namen zu nennen.
View -> ViewModel -> Model.
Natürlich habe ich meine Projekt auch entsprechend refrakturiert, damit bei Vorträgen die Zuhörer sich nicht wundern, warum mein ViewModel nur Model heißt und mein Model -> Datenbankinterface...
Aber wie gesagt, es war schon immer ein MVVM-Pattern.
Für mein Verständnis war eine View ein Form, ein Viewmodel die Formlogic und das Model die Formdatenschicht. Auch wenn es das nicht ganz trifft, sind für einen Delphianer diese Begriffe verständlicher.
Doch spätestens, wenn man feststellt, dass eine Form auch mehrere View's und jede View auch Unterviews haben kann, stellt man doch fest, neue Begrifflichkeiten müssen her.
Also kann man auch direkt die "offiziellen" nehmen.
Aber man braucht nur mal zu googlen... Es gibt viele Leute die nach dem gleichen Motto programmieren. (Auch wenn es jeder ein bisschen anders macht).
Einfach mal beim nächsten Programmierer Treffen in die Runde Fragen:
- Wer erzeugt die View?
- Wer erzeugt das Viewmodel?
- Darf die View Code enthalten?
- Darf die View das Viewmodel kennen?
- Wer räumt den Speicher wieder auf?
- Wer schließt die Form?
Und schon ist der Ärger vorprogrammiert und die Hartliner (also die Oberschlauen, die mit dem Patternbuch unter dem Kopfkissen schlafen gehen) müssen jedem der es nicht hören will, die einzig richtige Lösung aufschwatzen...
Immer schön geschmeidig bleiben....
Für mich gelten nun folgende Regeln:
1. Form -> also die MainView -> View first -> wenn von der Application erzeugt, wird das MainViewModel drangehängt.
Alle anderen View's sind ViewModel-first... Die View wird über eine Viewlocator erzeugt und das Model wird per Constructor Injection dem ViewModel übergeben (oder holt es sich per Factory aus dem Pool).
Meine View's kennen Ihr Viewmodel. (Property's des Viewmodel werden einem Binder übergeben, damit die View darauf zugreifen kann.
Meine ViewModel kommunizieren per multicast Event mit den Views.
Models sind immer interfaces.
Das ganze Boilerplate-Code ist natürlich im FDK, somit kann ich mich auf das wesentliche konzentrieren.
Angefangen hat es hiermit und nun? Natürlich bin ich ein gutes Stück weiter, aber gerade habe ich ein Video von 2014 (Visual Studio Tollbox / channel8.msdn.com / MVVM Best Practices ) gefunden... Die beste Aussage aus dem Video ist zwischen 02:45 - 03:45.
"Egal" wie man es nennt... Es geht um ein Pattern - wie auch immer man es implementiert.
Trotzdem habe ich mich jetzt daran gewöhnt die drei Jungs beim "richtigen" Namen zu nennen.
View -> ViewModel -> Model.
Natürlich habe ich meine Projekt auch entsprechend refrakturiert, damit bei Vorträgen die Zuhörer sich nicht wundern, warum mein ViewModel nur Model heißt und mein Model -> Datenbankinterface...
Aber wie gesagt, es war schon immer ein MVVM-Pattern.
Für mein Verständnis war eine View ein Form, ein Viewmodel die Formlogic und das Model die Formdatenschicht. Auch wenn es das nicht ganz trifft, sind für einen Delphianer diese Begriffe verständlicher.
Doch spätestens, wenn man feststellt, dass eine Form auch mehrere View's und jede View auch Unterviews haben kann, stellt man doch fest, neue Begrifflichkeiten müssen her.
Also kann man auch direkt die "offiziellen" nehmen.
Aber man braucht nur mal zu googlen... Es gibt viele Leute die nach dem gleichen Motto programmieren. (Auch wenn es jeder ein bisschen anders macht).
Einfach mal beim nächsten Programmierer Treffen in die Runde Fragen:
- Wer erzeugt die View?
- Wer erzeugt das Viewmodel?
- Darf die View Code enthalten?
- Darf die View das Viewmodel kennen?
- Wer räumt den Speicher wieder auf?
- Wer schließt die Form?
Und schon ist der Ärger vorprogrammiert und die Hartliner (also die Oberschlauen, die mit dem Patternbuch unter dem Kopfkissen schlafen gehen) müssen jedem der es nicht hören will, die einzig richtige Lösung aufschwatzen...
Immer schön geschmeidig bleiben....
Für mich gelten nun folgende Regeln:
1. Form -> also die MainView -> View first -> wenn von der Application erzeugt, wird das MainViewModel drangehängt.
Alle anderen View's sind ViewModel-first... Die View wird über eine Viewlocator erzeugt und das Model wird per Constructor Injection dem ViewModel übergeben (oder holt es sich per Factory aus dem Pool).
Meine View's kennen Ihr Viewmodel. (Property's des Viewmodel werden einem Binder übergeben, damit die View darauf zugreifen kann.
Meine ViewModel kommunizieren per multicast Event mit den Views.
Models sind immer interfaces.
Das ganze Boilerplate-Code ist natürlich im FDK, somit kann ich mich auf das wesentliche konzentrieren.
Wednesday, May 18, 2016
Delphi 10.1 Berlin, Grids and DblClick-Events...
Interessanterweise fehlen einige Events im ObjectInspector.
Zum Beispiel der dblClick Event.
Workaround:
Einfach im Source-Code zuweisen.
procedure TForm1.FormCreate(Sender: TObject);
begin
Grid1.OnDblClick := Grid1DbkClick; // Kein Eintrag im OI
end;
Zum Beispiel der dblClick Event.
Workaround:
Einfach im Source-Code zuweisen.
procedure TForm1.FormCreate(Sender: TObject);
begin
Grid1.OnDblClick := Grid1DbkClick; // Kein Eintrag im OI
end;
FDK - Größen und Datumsausgabe!
Ein Auszug aus einem Consolen
Testprogramm für Größen und Datumsausgabe!
Var
lSize: TSizeInBytes;
begin
lSize := 12345678; // Bytes
WriteLn( lSize.ToString( ) );
WriteLn( lSize.ToString( TSizeBase.f1000 ) );
WriteLn( lSize.ToString( TSizeBase.f1024 ) );
WriteLn( lSize.ToString( TSizeUnit.Kilo ) );
WriteLn( lSize.ToString( TSizeBase.f1000, TSizeUnit.Kilo ) );
WriteLn( lSize.ToString( TSizeBase.f1024, TSizeUnit.Kilo ) );
end;
lSize: TSizeInBytes;
begin
lSize := 12345678; // Bytes
WriteLn( lSize.ToString( ) );
WriteLn( lSize.ToString( TSizeBase.f1000 ) );
WriteLn( lSize.ToString( TSizeBase.f1024 ) );
WriteLn( lSize.ToString( TSizeUnit.Kilo ) );
WriteLn( lSize.ToString( TSizeBase.f1000, TSizeUnit.Kilo ) );
WriteLn( lSize.ToString( TSizeBase.f1024, TSizeUnit.Kilo ) );
end;
Erzeugt folgende Ausgabe auf den
entsprechenden Plattformen:
Windows
/ Android
|
OSX
/ iOS
|
11,8 MB
|
12,3 MB
|
12,3 MB
|
12,3 MB
|
11,8 MB
|
11,8 MB
|
12.056,3 KB
|
12.345,7 KB
|
12.345,7 KB
|
12.345,7 KB
|
12.056,3 KB
|
12.056,3 KB
|
Var
lDate: TDateTime;
begin
lDate := TDateTime // Helper für TDateTime
{} .ParseISO8601( '2016-04-24', {AsUtc} True )
{} .AddHours( 4 )
{} .AddMinutes( 4 )
{} .AddSeconds( 5 )
{};
WriteLn( lDate.ToString( ) );
WriteLn( lDate.ToShortDateString( ) );
WriteLn( lDate.ToLongDateString( ) );
end;
lDate: TDateTime;
begin
lDate := TDateTime // Helper für TDateTime
{} .ParseISO8601( '2016-04-24', {AsUtc} True )
{} .AddHours( 4 )
{} .AddMinutes( 4 )
{} .AddSeconds( 5 )
{};
WriteLn( lDate.ToString( ) );
WriteLn( lDate.ToShortDateString( ) );
WriteLn( lDate.ToLongDateString( ) );
end;
Erzeugt folgende Ausgabe:
24.04.2016
04:04:05
24.04.2016
Sonntag, 24. April 2016
24.04.2016
Sonntag, 24. April 2016
Tuesday, May 17, 2016
FDK - Parallel-Multithreading-Pipeline
Ein kleiner Codeauszug aus unser
Multithread Pipeline:
TPipeline.Configure( )
{} .Throttle( 10 ) // max. 10 Items in der OutputCollection
{} .Stage<Integer>(
procedure( Output: IBlockingCollection<Integer> )
var
i: Integer;
begin
for i := 1 to 100 do
Output.Add( GetDataFromWebservice( i ) )
end )
{} .NumTasks( 5 ) // Anzahl der Tasks für die nächste Stage
{} .Stage(
procedure( const Input: Integer; out Output: Integer )
begin
Output := CalculateData( Input );
end )
{} .Stage(
procedure( Input, Output: IBlockingCollection<Integer> )
var
v: Integer;
begin
for v in Input do
begin
WriteDataInDatabase( v );
end;
end )
{} .Run( );
{} .Throttle( 10 ) // max. 10 Items in der OutputCollection
{} .Stage<Integer>(
procedure( Output: IBlockingCollection<Integer> )
var
i: Integer;
begin
for i := 1 to 100 do
Output.Add( GetDataFromWebservice( i ) )
end )
{} .NumTasks( 5 ) // Anzahl der Tasks für die nächste Stage
{} .Stage(
procedure( const Input: Integer; out Output: Integer )
begin
Output := CalculateData( Input );
end )
{} .Stage(
procedure( Input, Output: IBlockingCollection<Integer> )
var
v: Integer;
begin
for v in Input do
begin
WriteDataInDatabase( v );
end;
end )
{} .Run( );
Der abgebildete Arbeitsprozess
holt in diesem Beispiel 100 Daten (hier zu Demonstration Integer-Werte) von
einem theoretischen Webserver (Im Thread). Maximal ( 10 ) Werte werden hierbei
in die Verarbeitungspipeline eingestellt.
Wenn die nachfolgende Stage ( In 5 Threads ) diese Werte nicht schnell
genug abarbeiten kann, werden die Threads die die Daten von Webserver holen,
nach Erreichen des Throttlewertes „schlafen“ gelegt. Das „Aufwachen“ passiert
natürlich sofort wenn wieder Platz in der Eingangsqueue ist. Dieses Verhalten
kontrolliert die BlockingCollection für alle Stages. Falls die Anzahl der
Threads nicht angegeben ist, gilt der default Wert.
Monday, May 16, 2016
Android & Application: Wird beendet beim drehen des Devices. (sudden death)
Unerklärlicherweise werden Android Apps - ohne eine Meldung beendet - wenn man das Device dreht.
Grund hierfür ist ein "Fehler" in der "AndroidManifest.template.xml".
Bisher hatte es immer funktioniert mit:
android:configChanges="orientation|keyboard|keyboardHidden|"
Jetzt - warum auch immer - ist es nötig diesen Eintrag ein zu setzen:
android:configChanges="orientation|keyboard|keyboardHidden|screenSize"
Ein Grund hierfür ist mir zur Zeit nicht bekannt... Aber danach funktioniert es wieder.
PS.: Vielen Danke an die Delphi-Praxis User (Rollo62 & DeddyH)
Grund hierfür ist ein "Fehler" in der "AndroidManifest.template.xml".
Bisher hatte es immer funktioniert mit:
android:configChanges="orientation|keyboard|keyboardHidden|"
Jetzt - warum auch immer - ist es nötig diesen Eintrag ein zu setzen:
android:configChanges="orientation|keyboard|keyboardHidden|screenSize"
Ein Grund hierfür ist mir zur Zeit nicht bekannt... Aber danach funktioniert es wieder.
PS.: Vielen Danke an die Delphi-Praxis User (Rollo62 & DeddyH)
Friday, May 13, 2016
FDK Das Firemonkey-Development-Kit
FDK
Das Firemonkey-Development-Kit!
· Noch eine
Komponentensammlung?
Der Firemonkey-Development-Kit kurz FDK
ist mehr als nur ein paar Komponenten, die man auf ein Form klicken kann.
Eigentlich hat das FDK keine einzige Komponente die man auf ein Formular
klicken „muss“.
· Ist das
FDK nur für das Firemonkey Framework oder auch für die VCL Programmierung
nützlich?
Die Grundidee
basiert auf Firemonkey aber der überwiegende Teil des Kit’s ist auch für VCL-Programmierer eine große
Hilfe.
· Was
bietet das FDK?
· Kurz gesagt: Code den jeder braucht, den jeder
immer und immer wieder neu schreibt oder nie benutzt hat, weil es doch auch auf
herkömmliche Wege geht, oder zu kompliziert war. Das FDK soll Ihnen einen
einfacheren Einstieg in die cross-Plattform-Programmierung ermöglichen. Die
Benutzung von Threads, Queues und Pipelines erleichtern. Die Performance Ihrer
Software verbessern. Keyfeatures für Ihre Anwendung sind hierbei:
Wiederverwendbarer und leicht pflegbareren Code. Der Funktionsumfang wird
stetig erweitert. Sie möchten gerne XY verwenden…? Das FDK hat hierfür wahrscheinlich
ein Interface welches Ihnen die Benutzung erleichtert. Hinzu kommen Software
Pattern, die heutzutage immer öfter zur Anwendung kommen.
·
Welche
Bereiche der Programmierung werden von FDK abgedeckt?
o
Decoupled object creation
o
Threads and background execution
o
Easy
use of data compression and converting
o
Easy
use of databases and datastructures
o
Fluidcreation
of objects/controls (less typing, more readable)
o
FMX
Application Event handling for mobile platforms
o
Array
and enumerables handling
o
Threaded
queues and pipelines for dataprocessing
o
File
and stream handling
o
Statemachine
o
Observer
Pattern
o
Application
logging
o
Lots
of helpers
o
See
feature Matrix for more…
·
Welche
Delphi Version wird benötigt?
VCL & FMX
Projekte können mit 10.4, 10.3, 10.2, 10.1, 10.0 erstellt werden.
(Auch wenn für die mobilen Plattformen eigentlich nur die aktuellste Version in
Frage kommt.)
·
Welche
Versionen gibt es vom FDK?
Wir bieten zwei verschiedene Pakete in zwei
verschiedenen Versionen.
1. Lite
Version.
Enthalten sind die wichtigsten
Komponenten um mit dem FDK beginnen zu können, sowie ein Updateservice von
Änderungen und Bugfixes.
2. Full-Featured-Version
Enthalten ist der komplette
Funktionsumfang und kostenfreie Updates von Änderungen, Bugfixes und neuen
Features.
Beide Versionen
gibt es als:
DCU
Distribution.
Sie erhalten die DCU’s für Delphi (10 Seattle), 10.1 Berlin, 10.2 Tokio, 10.3 Rio. Mit erscheinen der nächsten Delphi
Version endet der Update-Service.
Full-Source-Code-Distribution.
Enthalten ist der komplette
Source-Codes inkl. kostenfreien Updates von Änderungen, Bugfixes und neuen Features
für 1 Jahr, bezogen auf die gekaufte Version.
·
Was
kostet das FDK?
Version
|
Distribution
|
Erst
Käufer
|
Update
Verlängerung
|
Lite
|
DCU
|
49,- €
|
19,- €
|
Full
|
DCU
|
99,- €
|
59,- €
|
Lite
|
SOURCE
|
199,- €
|
69,- €
|
Full
|
SOURCE
|
399,- €
|
199,- €
|
Zur Zeit ist die DCU Version noch nicht im Setup enthalten, da sich bisher keiner dafür interessiert hat. ( Ich arbeite daran )!
*) Der Updatezeitraum beginnt – falls
enthalten – mit dem Tag der Auslieferung. Lizenz gilt pro Developer. 2. Developer 30% Rabatt. Company-Licence X 3,5.
Die Bestellung kann einfach über das Setup-Programm ausgeführt werden, da diese einen eigenen Shop integriert hat! Download unter : http://www.delphiprofi.de/FDK/FDKSetup.Zip
Fragen einfach an: Frank@delphiprofi.de
Fragen einfach an: Frank@delphiprofi.de
Berlin 10.1 & Android
Das verhalten unter Andoid hat sich mal wieder mit Delphi 10.1 geändert...
Dadurch feuert ggf. der Mouse-Up event erst dann, wenn der Button / das Form schon lange nicht mehr existiert...
Also am besten alle Aktionen besonders Form & Button free's wieder mal in den OnIdle-Event verlegen. Denn da ist die Animation oder der Maus-Up erledigt...
Dadurch feuert ggf. der Mouse-Up event erst dann, wenn der Button / das Form schon lange nicht mehr existiert...
Also am besten alle Aktionen besonders Form & Button free's wieder mal in den OnIdle-Event verlegen. Denn da ist die Animation oder der Maus-Up erledigt...
Thursday, May 12, 2016
Code-Camp & Firemonkey
Als Feedback vom Code-Camp musste ich wieder einmal feststellen, dass die Zahl derjenigen, die sich für Firemonkey interessieren verschwindend klein ist.
Für mich zwar unverständlich, aber interessanter Weise war die Zahl derjenigen die sich für FMX-Desktop Anwendungen interessieren im Verhältnis 10:2.
Na gut... Dann sind wir trotzdem mit unserem FDK auf dem richtigen Weg, den:
das FDK ist auch für FMX-Desktop und mindestens 80% - oder mehr - ist auch für VCL-Entwickler geeignet.
Für mich zwar unverständlich, aber interessanter Weise war die Zahl derjenigen die sich für FMX-Desktop Anwendungen interessieren im Verhältnis 10:2.
Na gut... Dann sind wir trotzdem mit unserem FDK auf dem richtigen Weg, den:
das FDK ist auch für FMX-Desktop und mindestens 80% - oder mehr - ist auch für VCL-Entwickler geeignet.
Saturday, April 9, 2016
Welches Keyboardcodes in der Delphi IDE?
Immer noch das "Beste" - hier im Original, damit es nicht verloren geht:
Bible, Dijkstra 5:15
"and the clueless shall spend their time reinventing the wheel while the elite merely use the Wordstar key mappings"
Bible, Dijkstra 5:15
"and the clueless shall spend their time reinventing the wheel while the elite merely use the Wordstar key mappings"
Subscribe to:
Posts (Atom)