Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste ÜberarbeitungBeide Seiten der Revision
framework [2019/07/27 16:37] – [Der Controller] huwiframework [2019/07/27 16:38] – [Das Betriebssytem] huwi
Zeile 37: Zeile 37:
 Betriebssystem ist natürlich übertrieben, aber das Framework verfügt bereits über wichtige Laufzeitstrukturen, die faktisch immer wieder gebraucht werden. Diese sind in der Klasse //AppKernel// zusammengefasst. Dazu gehört natürlich die Kontrolle über die //Startsequenz// und über die //MainLoop//. Beides kennen wir aus der klassischen Mikrocontrollerprogrammierung. Wir geben jetzt die Kontrolle über diese beiden wesentlichen Strukturelemente einer Mikrocontrolleranwendung zur Verwaltung an das Framework ab. Keine Panik, so ungewöhnlich ist das nicht und es macht vieles einfacher.  Betriebssystem ist natürlich übertrieben, aber das Framework verfügt bereits über wichtige Laufzeitstrukturen, die faktisch immer wieder gebraucht werden. Diese sind in der Klasse //AppKernel// zusammengefasst. Dazu gehört natürlich die Kontrolle über die //Startsequenz// und über die //MainLoop//. Beides kennen wir aus der klassischen Mikrocontrollerprogrammierung. Wir geben jetzt die Kontrolle über diese beiden wesentlichen Strukturelemente einer Mikrocontrolleranwendung zur Verwaltung an das Framework ab. Keine Panik, so ungewöhnlich ist das nicht und es macht vieles einfacher. 
  
->>>>>>>>>>>>>>>>>>>>>{{:betriebssystem1.jpg?350|}}+>{{:betriebssystem1.jpg?350|}}
  
 Von besonderem Interesse sind für uns die Operationen **onStart** und **onWork**. Der UML Spezialist erkennt scharfen Auges an der kursiven Schrift der beiden Operationen sofort, dass diese virtuell sind, also vom Anwendungsentwickler (das sind Sie) überschrieben werden können. Das bedeutet nichts weiter, als dass Sie diese beiden Operationen in ihrer Applikation selbst noch mal hinschreiben können und das Framework diese automatisch zum richtigen Zeitpunkt aufruft. Das sind sogenannte Ereignishandler. Davon werden wir noch einige sehen. Wie wir diese richtig nutzen, wird im Tutorial beschrieben. Um diesen Aspekt noch etwas näher zu beleuchten, schauen wir uns noch an wie es möglich ist, dass bestimmte Bausteine selbstständig (parallel) ihre Aufgaben erfüllen können. Selbstständig arbeitende Bausteine sind von der Klasse //AppModul// abgeleitet und der //AppKernel// verteilt die betreffenden Ereignisse automatisch an die Bausteine vom Typ //AppModul//. Jedes //AppModul// meldet sich auch automatisch beim //AppKernel// an und wird dort in einer Liste geführt. Von besonderem Interesse sind für uns die Operationen **onStart** und **onWork**. Der UML Spezialist erkennt scharfen Auges an der kursiven Schrift der beiden Operationen sofort, dass diese virtuell sind, also vom Anwendungsentwickler (das sind Sie) überschrieben werden können. Das bedeutet nichts weiter, als dass Sie diese beiden Operationen in ihrer Applikation selbst noch mal hinschreiben können und das Framework diese automatisch zum richtigen Zeitpunkt aufruft. Das sind sogenannte Ereignishandler. Davon werden wir noch einige sehen. Wie wir diese richtig nutzen, wird im Tutorial beschrieben. Um diesen Aspekt noch etwas näher zu beleuchten, schauen wir uns noch an wie es möglich ist, dass bestimmte Bausteine selbstständig (parallel) ihre Aufgaben erfüllen können. Selbstständig arbeitende Bausteine sind von der Klasse //AppModul// abgeleitet und der //AppKernel// verteilt die betreffenden Ereignisse automatisch an die Bausteine vom Typ //AppModul//. Jedes //AppModul// meldet sich auch automatisch beim //AppKernel// an und wird dort in einer Liste geführt.
  
->>>>>>>>>>>{{:controller.jpg?550|}}+>{{:controller.jpg?550|}}
  
 Auffällig ist hier zum einen, dass der Controller jetzt einen Timer hat und zum anderen die widerum virtuellen Operationen //onTimer10ms, onTimer100ms, onTimer1s//.  An diese können wir uns als Programmierer sozusagen dranhängen. Den Timer braucht der //Controller//, um als //AppKernel// Zeitereignisse auszulösen. Wir sehen, dass auch die //AppModule// über diese Operationen verfügen. Das ist für uns jetzt weniger interessant, da wir noch keine eigenen //AppModule// entwickeln wollen.  Auffällig ist hier zum einen, dass der Controller jetzt einen Timer hat und zum anderen die widerum virtuellen Operationen //onTimer10ms, onTimer100ms, onTimer1s//.  An diese können wir uns als Programmierer sozusagen dranhängen. Den Timer braucht der //Controller//, um als //AppKernel// Zeitereignisse auszulösen. Wir sehen, dass auch die //AppModule// über diese Operationen verfügen. Das ist für uns jetzt weniger interessant, da wir noch keine eigenen //AppModule// entwickeln wollen.