Bevor wir an unserer Schule die Vorzüge von WebUntis genießen durften, gab es lediglich einen zentralen Vertretungsplan (DSBmobile). Da aber immer den Überblick zu behalten war nicht sonderlich angenehm, sodass zumindest mein Wunsch nach einem Widget größer wurde, das die Vertretungen, die einen betreffen, übersichtlich und jederzeit aktuell angezeigt.

Doch wo genau sollte man die Vertretungsdaten herbekommen?

Wer in seinen Softwareprojekten auf externe Daten jeglicher Art angewiesen ist, hat allgemein zwei Möglichkeiten, sich diese zu beschaffen:

Die erste Option ist über eine API (engl. „Application Programming Interface“ = sinngemäß „Schnittstelle“). Hier können standardisierte Anfragen direkt an den Server des Anbieters gestellt werden und man bekommt wohl strukturierte Daten zurück – mega praktisch! Jedoch setzt dies auch voraus, dass der Anbieter, von dem man die Daten haben möchte, diese Schnittstelle zum einen für die Öffentlichkeit ausgelegt und zum anderen diese auch entsprechend ausführlich dokumentiert hat.

Ist dies nicht der Fall, muss man selbst die Daten sammeln. Aber wie könnte das funktionieren? Im Prinzip muss man sich bewusst machen, dass die Daten, die man haben möchte, schon irgendwo aufgeführt werden, beispielsweise auf einer Website. Diese kann man natürlich auch programmatisch aufrufen und die dahinterliegende HTML-Struktur auswerten.

Im Falle unseres ehemaligen Vertretungsplanes durfte ich beide Ansätze verfolgen: Das Abrufen des Plans (der übrigens keine Lehrerkürzel enthielt, die gab es nur auf den Fernsehern im Flur zu sehen) war programmatisch über eine inoffiziell dokumentierte API möglich. Der Plan an sich (eine HTML-Datei) musste jedoch noch weiter ausgewertet werden.

In einem Browser wäre solch eine Auswertung mithilfe von der CSS-Selektoren-API relativ einfach machbar. Glücklicherweise haben sich andere Menschen die Mühe gemacht, diesen Workflow ohne einen Browser über Bibliotheken verfügbar zu machen. Davon gibt es zahlreiche, für meine damalige Implementierung in Rust habe ich die (zugegebenermaßen recht schlicht benannte) „scraper“-Bibliothek genutzt.

Nach ein paar mehr oder weniger kleinen Schwierigkeiten durch unhandliche Datumsformatierungen und dem Fakt, dass die Pläne nach einer gewissen Anzahl von Zeilen aufgeteilt wurden (trotz des theoretisch unlimitierten, vertikalen Platzes) hat das alles ziemlich gut funktioniert.

Nachdem ich die Daten über eine kleine API verfügbar gemacht und dafür gesorgt habe, dass sie regelmäßig aktualisiert wurden, blieb nur noch das Widget übrig. Da ich zum damaligen Zeitpunkt noch keinen Mac besaß, kam die Entwicklung einer eigenen App dafür leider nicht infrage. Doch zum Glück kann man mithilfe der App „Scriptable“ über JavaScript eigene Widgets zusammenbasteln. Den Code davon möchte ich dir aber lieber ersparen. Das Endresultat sah wie folgt aus:

Ende gut, alles gut, oder? Nun, lediglich drei Monate später (April 2023) wurde dann WebUntis / UntisMobile eingeführt, was gleichzeitig auch bedeutete, dass bei DSBmobile (verständlicherweise) keine Aktualisierungen des Plans seitens der Schule mehr vorgenommen wurden. Zugegeben: Ein klein wenig enttäuscht war ich schon. War also all diese Mühe umsonst? Ich würde sagen nein, retrospektiv habe ich aus dem Projekt, das übrigens frei auf GitHub verfügbar ist (MIT-lizenziert), sehr viel Erfahrung mitgenommen.

Wenn du dich vielleicht auch einmal an der kleinen Herausforderung des Auslesens des Plans versuchen möchtest, so findest du hier ein paar Beispieldateien. Probiere es doch einfach mal in der Programmiersprache deines Vertrauens.

Obwohl ich auch heute Funktionen wie ein Widget oder Push-Benachrichtigungen vermisse, nutze ich Untis trotzdem sehr gerne. Die Möglichkeit, zwischen Kursen einfach kurz auf seinen aktuellen Stundenplan gucken zu können, ist einfach genial. Zum Glück haben wir ja so einen lockeren und vertrauensvollen Umgang mit der Nutzung von digitalen Endgeräten im Schulgebäude – oder zumindest bis Anfang August…