Flutter -- Tutorial Teil 3 Starter Code

Im ersten und im zweiten Teil dieser kleinen Serie, haben wir uns schon mit einigen Punkten beschäftigt, die ich wichtig für Flutter finde.

Aller Anfang ist....leicht !

Für Anfänger bietet sowohl Android Studio, wie Visual Studio Code einen bequemen Einstieg zum Flutter SDK.
Beide Programme erstellen uns die Ordnerstruktur und beglücken uns mit einem kleinen Demoprogramm, das wir gleich ausprobieren können.

Im weiteren Verlauf des Artikel beziehe ich mich auf Visual Studio Code, aber das prinzipielle ist auch für Android Studio gültig !

Was die default Ordnerstruktur angeht, ist für uns zuerst mal das main.dart File wichtig. Es enthält das kleine Demoprogramm.
In einem anderen Post werden wir noch das pubspec.yaml File betrachten. Dieses ist dann von Bedeutung, wenn es um den Import von Librarys bzw den Code von Drittanbietern geht.

Das widget_test.dart File fällt unter die Rubrik "debuggen". Ich werde in diesem Post nicht darauf eingehen, aber ein Blick auf den Code lohnt sich allemal.

In Visual Studio Code können wir bequem neue Files generieren. Beim erlernen von Flutter, ist es wohl noch nicht so entscheidend, wie wir unsere Files ordnen.
Auf längere Sicht aber, ist es sicher ratsam, sich hierzu ein paar Gedanken zu machen. Abseits von den Ordnern brauchen wir aber noch einen Emulator, oder ein reales Smartphone, um unseren Code zu testen.

Mit Android Studio kann man mehrere Emulatoren von Smartphones oder Tabletts installieren. Dies kann dann nützlich sein, wenn man seinen Code auf verschiedenen Endgeräten testen will.

In Visual Studio Code klicken wir auf No Devices und erhalten dann am oberen Bildschirmrand die Möglichkeit einen Emulator auszuwählen.
Mit einem weiteren Klick in das Editoren Fenster, nur um sicher zu gehen das das Fenster den Fokus hat, und der F5 Taste starten wir den Code im Debugg Modus.

Aus dem Code habe ich alles nicht wesentliche entfernt. Er stellt einen guten Startpunkt dar, um ein paar Dinge zu betrachten.

Der Code besteht im wesentlichen aus einem StatelessWidget und einem StatefulWidget. Beide Widgets haben eine build(...) Funktion und beide operieren mit dem "context".

Die build(..) Funktion verankert das Widget in der Objekthierarchie von Flutter und "baut" es auf. Der context wiederum enthält Informationen darüber, vereinfacht geschrieben, wie diese Verankerung aussieht. Das erste Widget das "gebaut" wird, integriert sich in die Umgebung, die unsere App aufgerufen hat. Die zweite build(..) Funktion, in unserem Fall vom StatefulWidget, verkettet dieses wiederum, mit dem ersten Widget und gliedert sich so in die Objekthierarchie ein.

Der build(..) Funktion wird der aktuelle context übergeben und retourniert einen neuen context, in welchem unser Widget gebaut / ausgeführt wird. Da der neue context auch immer eine Verkettung zum Ursprungs context hat, ist gewährleistet, das die Widget Struktur durchlässig ist.

Im StatelessWidget Widget legen wir durch return fest, das die build(..) Funktion uns eine MaterialApp retourniert. Das ermöglicht Zugriff auf eine Vielzahl von Möglichkeiten in Flutter, ist aber nicht zwingend. Wir könnten uns z.b. auch einen Container retournieren lassen.
Wir spendieren unserer MaterialApp noch einen title , Farben mit ThemeData und tragen unser home Widget ein.

StatefulWidget

Das StatefulWidget wird dann eingesetzt, wenn sich der Zustand des Widgets, sprich eine Variable, ändern kann und wir darauf reagieren möchten. Ein gutes Beispiel ist ein Button oder ein Inputfeld. Flutter bietet dort schon eingebaute Möglichkeiten, die wir dann programmtechnisch mit Leben füllen müssen, z.b. die onpressed() Funktion bei Buttons. Eine vereinfachte Darstellung:

Schema

Das StatefulWidget in unserem Beispiel ist momentan nutzlos, da wir ja noch keine Elemente definiert haben, die wir dynamisch ändern möchten. Das machen wir dann im nächsten Teil dieser kleinen Serie.