Wow, ich muss zu aller Erst sagen: Ich bin wirklich froh, dass dieser Meilenstein hier (fast) sein Ende erreicht hat. Es ist nach außen nicht zu sehen, wir haben durch (zugegebenen relativ seltene) Meldungen immer mal versucht, die Problematik anzureißen, aber die Wahrheit ist: Es war eine unfassbare Mammutaufgabe, die anfangs sogar von uns komplett unterschätzt wurde, die wir im Berufsleben tagtäglich mit Softwareprojekten zu tun haben.

Das letzte Release, die Version 2.3.1, liegt jetzt etwa 9 Monate zurück. Danach wollte zuerst primär ich, später zwang uns ein Upgrade der internen Programmiersprache Dart, ein umfassendes Review und eine darauf aufbauende Erneuerung der Codebasis haben. Es ist einfach von Zeit zu Zeit notwendig, kritisch auf seine Arbeit zu blicken und zu schauen, welche Stellen sind noch aktuell, welche haben sich überlebt und welche sind mittlerweile so stark gewuchert, dass sie keiner mehr versteht. Durchwischen, neu sortieren, renovieren. Und da die Programmiersprache Dart auch langsam zusammen mit unserem Projekt erwachsen wurde, wurde zufälliger Weise auch da gerade entrümpelt, was für uns bedeutete: Noch mehr Umstrukturierungen.

Über unsere Ziele beim Refactoring hatten wir uns im Januar ja bereits hier und hier ausgelassen, deswegen übergehe ich jetzt erklärende Details. Wichtig ist das Fazit des Ganzen: Wir hatten uns die Pest an Bord geholt. Auch wenn wir das nirgends explizit schrieben, es vergingen selten zwei zusammenhängende Tage, an dem nicht wenigstens einer von uns intensiv am Code arbeitete. Eine so intensive Arbeit hatte ich eigentlich nur während der ersten zehn Monate, als ich dieses Baby an den Start brachte. Neben vielen privaten Projekten, Familie und Corona, war diese Aufgabe hier wirklich extrem belastend für uns. Und im Gegensatz zur damaligen Anfangsphase, war die jetzige wirklich alles andere als schön, denn sie war im höchsten Maße undankbar: Im besten Falle tat das Tool nach tagelangem Programmieren „nur“ wieder das, was es vorher tat, im wahrscheinlicheren ging dafür irgendwas anderes kaputt.

Wir lernten uns selbst zu strukturieren, wir banden die Tester noch näher in den Entwicklungsprozess ein, und versuchten auch euch, die Nutzer direkt zu integrieren, indem wir eine separate Testversion zur Verfügung stellten (was leider eher so määäh lief, da wir so gut wie nie eine externe Rückmeldung bekamen). Wir überarbeiteten, aktualisierten und erweiterten unsere internen Tests massiv, sodass wir unsere eigenen Bugs möglichst frühzeitig erkennen konnten. Wir wähnten uns schon etliche Male am Ziel, doch immer und immer wieder kamen neue Bugreports von uns selbst rein. Es war zum Mäusemelken. Es war frustrierend. Die Umstellung der Codebasis war kein Spaß, aber ich glaube, wir haben alle dabei gelernt und das Team ist in sich gereift.

Natürlich geht mein Dank an alle Mitglieder des Teams, die sich mit aller Kraft diesem großen Ziel verschrieben haben! Ihr ward alle unglaublich!

Die Grenzen dieser Version

Die Version 3.0 hatte neben dem Code-Refactoring anfangs sehr ambitionierte Ziele. Da uns das Refactoring selbst allerdings deutlich mehr als erwartet beschäftigt hatte, sind natürlich einige Sachen bisher nicht so zu erreichen gewesen, wie wir uns das gewünscht hätten. Im Refactoring selbst fehlt das komplette Kapitel um die Sache mit der Reflection, bei der sowieso nicht klar ist, ob es nicht zu einer extremen Verlangsamung des Startprozesses führen wird. Testen will ich es in den nächsten Wochen aber auf jeden Fall.

Auch bei der „Web-API“ sind wir nicht zum endgültigen Ziel gekommen, das da hieß, intern unseren Server um die Lösung eines Problems zu bitten und eine Antwort zu bekommen. Dennoch haben wir hier einen sehr großen Schritt geschafft, denn immerhin ist es jetzt möglich, einzelne Tools mittels spezieller URL nicht nur aufzurufen, sondern die gängigsten sogar explizit mit Eingaben zu füllen.

Doch warum warten wir nicht einfach noch länger? Zum Einen ist auch hier wieder Google, die uns ein Ultimatum setzten, denn sie drohen aktuell, dass sie alle Apps aus dem PlayStore werfen, die nicht eine neue Mindestanforderung haben, was wir mit den alten Versionen noch nicht leisten konnten. Andererseits muss auch einfach mal ein Schlussstrich gezogen werden. Klar werden immer wieder hier und da Dinge auftauchen, die wir bearbeiten müssen, aber letztlich möchten wir auch gerade die Nutzer nicht warten lassen, denen wir zum Teil schon vor Monaten ein neues Feature versprochen haben oder die uns einen Bug in der bestehenden Version meldeten. Danke übrigens dafür (ich hoffe, wir haben in all dem Chaos keinen Bugreporter für unsere Tester-Liste vergessen, ansonsten gern melden!)

Highlights der Version 3.0.0

Genug dessen, was wir nicht geschafft haben. Ich denke, es ist an der Zeit, zu enthüllen, was die neue Version nicht nur intern berechtigt, einen Major-Versionsprung hinzulegen, sondern auch für euch Nutzer sichtbar:

Zu allererst würde ich tatsächlich gern die Web-Schnittstelle nennen, die auf Mikes Konto geht. Denn anders als bisher können nun alle Tools direkt per Aufruf in der Adresszeile des Browsers aufgerufen werden. Das hat den Vorteil, dass nun direkt ein Tool verlinkt werden kann, anstatt immer zu sagen: „Geht auf die Webseite zum GCW, dann klick hier und dann da.„. Es ist sogar schon möglich, für eine Reihe häufiger, einfacher Tools, gleich den Eingabetext und ggf. einige Parameter direkt im Link mitzugeben. Das eröffnet jetzt die Möglichkeit, dass externe Tools oder Browserplugins entworfen werden können, die bestimmte Codes nehmen und damit direkt unsere Webseite aufrufen können, wo sofort die Lösung angezeigt wird. (Wie gesagt, an dem Schritt, die Lösung direkt wieder zum Aufrufer zurück zu spielen, daran wird bereits getüftelt – ohne etwas versprechen zu wollen.)

Neben dem Mammutprojekt, das Wherigo-Tool zu stabilieren und zu testsichern, bestand Thomas sein Ziel darin, die Scripting-Engine GCW Script zu implementieren. Die Älteren unter euch können sich sicherlich an die Script-Funktion von Mopsos erinnern. Dies hier ist ein Versuch, ein Analogon zu schaffen, und ich denke, das sieht schon einmal ziemlich gut aus. GCW Script basiert im Grunde auf einem BASIC-Dialekt. Auch hier sind bereits einige GCW-eigene Funktionen direkt als Funktionsschnittstellen integriert. Ich persönlich denke, dass hier noch viel Reifung stattfinden muss, was allerdings nur durch konkrete Anwendungen eurerseits geschehen kann, weshalb hier noch gut sichtbar die BETA-Flag dran hängt.

Der einzig richtige Moment, um sogenannte Breaking Changes einzubauen, sind große Versionswechsel. Wir haben hiermit die Chance genutzt und eine frühere Entscheidung revidiert, die sich als unpraktisch herausgestellt hat: Der Formelrechner hatte ja vor einiger Zeit die Text-Funktionen bekommen, um beispielsweise direkt den Buchstabenwortwort berechnen zu können. Das lief einfach über bww(C) = 3. Doch nun stellte sich die Frage, was wenn es parallel noch eine Variable C gab? Wir hatten da ein paar Algorithmen, die sicher stellten, dass hier ein einigermaßen konsistentes Verhalten erzeugt wurde, aber so ganz glücklich war das immer nicht. Als jetzt auch c:geo ihre eigene Formel-Engine einbrachte, haben wir gedacht, dass es günstiger Zeitpunkt wäre, uns dahingehend anzugleichen: Texte werden nur noch als Texte interpretiert, wenn sie in Anführungszeichen oder Hochkommata gesetzt werden. bww("C") = 3, aber bww(C) würde meckern, wenn es keine Variable C gibt. Damit kann es aber sein, dass eure alten Formeln mit Text nun ggf. nicht mehr funktionieren, was eben diesen Breaking Change ausmacht.

(Separate Artikel zum Formelrechner und zur Web-API werden auf jeden Fall folgen)

Was nun?

Im Gegensatz zu sonst werden wir – bedingt durch die Größe des Updates – die einzelnen Versionen stufenweise ausrollen:

  1. Heute ging die normale Android-Version in die öffentlichen Beta-Versionen. Da wird sie auch länger als sonst verweilen, weil wir wirklich sicher stellen wollen, dass wir da nicht etwas ganz Grundlegendes kaputt gemacht haben. Ich habe zwar mittlerweile so meine Vorbehalte was die Mitarbeit unserer mittlerweile knapp 600 Betatester betrifft, aber man darf ja noch träumen 😉
  2. Parallel haben wir die Web-Version geupdatet, damit Interessierte sich schon einmal die Web-API anschauen können und Feedback dalassen können.
  3. Wenn so weit alles in Ordnung scheint, können wir die Android-Gold-Version in ein paar Wochen nachziehen. Natürlich sind die Gold-User nicht benachteiligt und können die neuen Features genauso verwenden, weil sie ja beide Versionen parallel installieren können.
  4. Parallel werden wir die iOS-Version prüfen. Ja, wir haben das in all den Monaten nämlich noch nicht geschafft – wir haben schlicht Angst davor, sind wir doch alles Android-User (an dieser Stelle mal wieder der Aufruf: Falls ein iOS-User Lust hat, mitzuarbeiten: Immer gern!), und iOS hat immer noch ganz eigene Probleme. Die iPhöner müssen sich also noch ein bisschen gedulden, sorry 😉

Changelog

Tja, und da ich jetzt schon wieder viel zu viel gequatscht habe: Hier der obligatorische, abschließende Changelog des Releases, in dem natürlich die tausenden Bugfixes und kleinen, teils gut versteckten Tool-Verbesserungen nicht einzeln aufgezählt werden konnten:

[chg] Neue interne Code-Struktur
[new] WebAPI, Deep Links
[new] GCW Skript
[new] Zahlenpyramide
[new] Diplomatenkennzeichen
[new] Buchstabieralphabete
[new] Sternbilder
[new] Base64: Dateierkennung
[new] kgV, ggT
[new] Geohashing
[new] Ave Maria-Code
[new] UFI-Codes
[new] Unix/Excel Times
[new] Geschwindigkeit/Beschleunigung
[new] Kalenderwoche
[new] Einstellungen: Speicher/Laden
[new] Tastaturen: Smartphone-Layouts
[new] Segmentanzeigen: Typen
[new] Freie Karte: Punkte fixieren
[new] Einheitenrechner: Beschleunigung
[new] Koords einmessen: Kartenansicht
[new] Formelrechner: c:geo-Export
[new] HochRunterLinksRechts: Diagonale
[new] Gade: Export nach Formelrechner
[new] Einstellungen: DMM-Präzision
[new] Symboltabellen
[chg] BREAKING: Formelrechner: Texte