Entwicklung & Code
Legacy-Code Schritt für Schritt aktualisieren mit der Mikado-Methode
Altsysteme strahlen eine gewisse Faszination aus, denn sie bieten ihre ganz eigenen, spannenden Herausforderungen. Die können viel interessanter als das Zusammenstecken moderner Frameworks zu einer Anwendung auf der grünen Wiese sein. Entwicklerinnen und Entwickler führen aber nur ungern Änderungen an Altsystemen aus, denn es ist oft nicht klar, was dabei kaputtgeht.
Weiterlesen nach der Anzeige

Falk Sippach ist Softwarearchitekt, Berater und Trainer bei der embarc Software Consulting GmbH. Er engagiert sich in der Java-Community und teilt sein Wissen in Artikeln, Blogbeiträgen und Vorträgen.
Viele Legacy-Systeme sind technologisch auf dem Stand von vor über zehn Jahren und damit nicht mehr up to date. Es fällt schwer, geeignete Mitarbeiter für die Wartung und Weiterentwicklung zu finden. Regelmäßige Aktualisierungen der eingesetzten Bibliotheken und Frameworks helfen leider nur wenig. Der Quellcode, der in den letzten Jahren schon durch so viele Hände gegangen ist, wird dadurch nicht besser.
Die größten Schwierigkeiten bestehen im fehlenden Wissen über die interne Struktur, über die Entscheidungen, die zu Beginn des Projekts getroffen wurden, und über die unklaren Auswirkungen der Änderungen. Leider lernen die meisten Entwickler in der Ausbildung oder im Studium häufig nur, wie sie neue Systeme erstellen und nicht, wie sie bestehende Software pflegen oder weiterentwickeln können.
Das Refactoring ist dabei ein Mittel zur Struktur- und Designverbesserung. Und in komplexen Umfeldern bietet die Mikado-Methode zusätzliche Unterstützung. In den Worten von Ola Ellnestam und Daniel Brolund, die die Methode erfunden haben: „Die Mikado-Methode ist ein strukturierter Weg, um signifikante Änderungen an komplexem Code vorzunehmen … für Änderungen an einem System, das zu groß ist, um es erst zu analysieren und dann zu bearbeiten. Das betrifft grundsätzlich jedes produktive System in der Welt“ (Ola Ellnestam, Daniel Brolund: The Mikado Method; Manning 2014).
Wie beim Möbelrücken
Beim Editieren an einer Legacy-Code-Basis können Entwicklerinnen und Entwickler schon mal ins Schwitzen kommen. Insbesondere dann, wenn die Änderungen außer Kontrolle geraten und sie nach mehreren Stunden Arbeit wieder ganz am Anfang stehen. Es fällt leichter, wenn es eine ausführliche Dokumentation oder wenigstens automatisierte Tests gibt. Aber häufig steckt die gesamte Wahrheit nur im Quelltext und Tests sucht das Entwicklerteam vergeblich.
Weiterlesen nach der Anzeige
Hier unterstützt die Mikado-Methode dank ihres strukturierten Vorgehens. Das Refactoring von komplexem Code läuft ähnlich ab, wie das Umstellen von Möbeln in einer Wohnung. Wenn sich die alte Polstergarnitur aus Platzgründen (Tür wäre verstellt) nicht einfach durch das neu angeschaffte Dreisitzer-Sofa austauschen lässt, dann müssen größere Umbaumaßnahmen erfolgen (siehe Abbildung 1).

Beim Verrücken von Möbeln ergeben sich oft ähnliche Probleme wie beim Refactoring von Software (Abb. 1).
Der Esstisch muss für das neue Sofa weichen. Er soll an den Platz der alten Polstergarnitur rücken, die aber erst mal entfernt werden muss. Genau wie in der Programmierung kann man sich hier schnell im Chaos verlieren. Wenn die Bewohner einfach das neue Sofa ins Zimmer stellen, ist möglicherweise gar kein Platz mehr, um die Möbel umzustellen.
Darum werden die Schritte zunächst nur theoretisch durchdacht und die Hindernisse (zum Beispiel beim Verrücken des Esstischs) jeweils festgehalten. Im nächsten Schritt werden die Bewohner versuchen, das gerade entdeckte Problem zu beseitigen. Dabei stehen aber häufig weitere Hindernisse im Weg, wie in diesem Fall die alte Polstergarnitur. Diese muss zunächst aus der Wohnung entfernt werden. Dann kann der Esstisch umziehen und schließlich das neue Sofa endlich an den geplanten Platz gestellt werden.
Verbessertes Softwaredesign durch Refactoring
Refactoring ist ein Hilfsmittel zur Verbesserung des Softwaredesigns. Bereits vor über zwanzig Jahren hat Martin Fowler in seinem Buch folgende Definition dazu festgehalten: „Refactoring (Substantiv): Eine Änderung an der internen Struktur einer Software, um sie verständlicher zu machen und kostengünstiger ändern zu können, ohne ihr sichtbares Verhalten zu ändern“ (Martin Fowler; Refactoring: Improving the Design of Existing Code; Addison Wesley 2019).
Wer den Quellcode restrukturieren will, wird dazu letztlich eine Serie von Refactorings anwenden. Dabei handelt es sich um sogenannte verhaltenserhaltende Code-Transformationen: An der fachlichen Logik ändert sich nichts. Das Ziel ist eine verständlichere interne Struktur, die zukünftige Änderungen erleichtert und die Testbarkeit erhöht. Damit das Refactoring gut funktioniert, braucht es einige Verbündete.
Dazu zählen schnelle Compile- und Build-Zeiten, vorhandene automatisierte Unit- beziehungsweise Integrationstests sowie eine Versionsverwaltung, um Änderungen jederzeit leicht rückgängig machen zu können. Zudem kann der Einsatz von Werkzeugen bei der sicheren und zügigen Durchführung unterstützen. Viele moderne Entwicklungsumgebungen wie Eclipse oder IntelliJ bringen ein komfortables Tool-Set mit.
Durch das Refactoring sichern Entwickler bestehende Investitionen in ihrer Software ab, verhindern den Designverfall und erhöhen die Lesbarkeit, Änderbarkeit sowie Testbarkeit. Sie können gegebenenfalls gut versteckte Fehler finden, Wissen durch aktives Lernen am Code transferieren, und sie helfen auch den nachfolgenden Entwicklern, die oft vergessene Nutzer des Quellcodes sind. Ganz nach dem Motto von Martin Golding: „Schreibe deinen Code so, als wäre der Typ, der ihn verstehen muss, ein Psychopath mit einer Axt, der weiß, wo du wohnst.“
Die Arbeitsweise basiert dabei auf zwei grundlegenden Prinzipien: erstens den Programmcode nicht kaputt machen und zweitens jeweils nur eine Sache bearbeiten. Bei der Durchführung gehört daher viel Selbstdisziplin dazu. Entwickler sollen immer nur kleine Schritte machen und dann den Code kompilieren sowie die Tests ausführen. Anschließend beginnt es wieder von vorn.
Wichtig ist auch Kent Becks Metapher der zwei Hüte. Man kann immer nur einen Hut auf den Kopf setzen. Daher sollte beim Refactoring kein inhaltlicher Code geändert, also keine neuen Features eingebaut oder Bugs repariert werden.
Angewendet werden können Refactorings bei unterschiedlichen Gelegenheiten: zum Beispiel regelmäßig täglich eine halbe Stunde, damit der Code gesund bleibt. Oder wenn Entwickler den Quellcode nicht (mehr) verstehen und ihn beim Lesen aktiv kennenlernen möchten. Außerdem bietet sich das Refactoring bei geplanten Änderungen an, zum Beispiel vor Erweiterungen beziehungsweise Bugfixes. Oder einfach während eines Code-Reviews, wenn Unstimmigkeiten im Code auffallen. Getreu dem Motto der Boyscout Rule von Robert C. Martin: „Den Platz immer sauberer hinterlassen, als Du ihn vorgefunden hast.“ (Kevlin Henney: 97 Things Every Programmer Should Know; O’Reilly 2010)
Wirklich fertig werden Entwickler übrigens nie. Jedes Refactoring hat möglicherweise ein Gegen-Refactoring. Denn es gibt keine wirklichen Sackgassen und es lässt sich ewig weitermachen. Von daher ist es sehr sinnvoll, Grenzen zu setzen. Entwickler könnten aufhören, wenn der zu analysierende Code verstanden, ein gesetztes Zeitlimit erreicht ist oder der Chef beziehungsweise der Kunde mit einem anderen Auftrag um die Ecke kommt.
So hilft die Mikado-Methode
Refactoring scheint eigentlich ganz einfach zu sein, aber doch auch wieder nicht. Das Vorgehen – möglichst kleine Schritte und das ständige Kompilieren beziehungsweise Ausführen der Tests – gerät schnell in Vergessenheit. Was bei einem überschaubaren Kontext noch gut funktioniert, fällt bei komplexen Softwaresystemen deutlich schwerer. Gemäß der Mikado-Methode lassen sich rasch blockierende Elemente ermitteln und analysieren. Diese Hindernisse werden dann aber zunächst nur notiert und erst nach der gesamten Analyse Schritt für Schritt entfernt. In den Worten von Ellnestam und Brolund: „Die Mikado-Methode hilft dabei, am Business Value orientierte Verbesserungen über mehrere Iterationen und Arbeitsschritte zu visualisieren, zu planen und umzusetzen, ohne dass die Codebasis während des Prozesses jemals kaputtgeht“ (Ola Ellnestam, Daniel Brolund: The Mikado Method; Manning 2014).
Die Vorgehensweise ist dabei relativ einfach (siehe Abbildung 2). Zunächst legen die Entwickler das Ziel fest (1). Das ist der Startpunkt der anstehenden Änderungen und gleichzeitig auch das Erfolgskriterium für das Ende. Anschließend beginnt das Team damit, erste Lösungsansätze auszuprobieren (2). Bei diesen Experimenten darf es den Code aktiv ändern, um Hypothesen zu prüfen und deren Auswirkungen zu beobachten. Hindernisse visualisieren die Testerinnen und Tester transparent für alle im Mikado-Graph (3). Die durch die Experimente eingeführten Änderungen machen sie dann direkt wieder rückgängig (4), zum Beispiel durch einen git reset. Anschließend geht es bei Schritt 2 weiter und das Vorgehen wiederholt sich so lange, bis keine Hindernisse mehr im Weg stehen.
Abbildung 2 zeigt den Gesamtablauf der Mikado-Methode. Durch den wiederkehrenden Zyklus Ausprobieren-Visualisieren-Rückgängigmachen (2) baut sich Stück für Stück der Mikado-Graph auf. Dieser Graph enthält viele wertvolle Informationen über die Struktur des Systems. Die Erstellung kann jederzeit unterbrochen und später fortgesetzt werden. Die Code-Basis ist dabei immer in einem lauffähigen Zustand, denn alle durchgeführten Experimente werden ja nach dem Dokumentieren wieder rückgängig gemacht. Sobald alle Hindernisse auf dem Weg zum festgelegten Ziel analysiert sind, wird der Graph rückwärts abgespult. Alle dokumentierten Änderungen werden der Reihe nach ausgeführt (3), bis das ursprüngliche Ziel erreicht ist (4).

Gesamtablauf: Nach dem Ablauf der Zyklen setzt das Team alle Änderungen in umgekehrter Reihenfolge um. Der rechte, bunte Teil der Grafik zeigt das nachfolgende Beispiel (Abb. 2).
Entwicklung & Code
Visual Studio Code 1.108: Profile importieren per Drag & Drop
Microsoft hat Visual Studio Code 1.108 veröffentlicht. Traditionell nutzt Microsoft den Dezember für Aufräumarbeiten statt für ein reguläres Release, doch in diesem Jahr gibt es offenbar zwölf statt elf Releases. Dabei haben die VS-Code-Entwickler die Tradition beibehalten, im Dezember Issues und Pull Requests aufzuräumen: Rund 6000 davon wurden geschlossen, und darüber hinaus sind einige Feature-Updates in das Dezember-Update eingeflossen.
Weiterlesen nach der Anzeige
Profile importieren per Drag & Drop
Es ist nun möglich, Einstellungsprofile per Drag & Drop einer .code-profile-Datei in VS Code zu ziehen, ähnlich wie bei einer .code-workspace-Datei zum Öffnen eines Workspace. Dann öffnet sich der Profile-Editor, der eine Vorschau zeigt und das Importieren des Profils ermöglicht. Das soll es vereinfachen, Profile mit Teammitgliedern zu teilen oder schnell eine neue Umgebung aufzusetzen.
Spezialisierte Skills für den KI-Agenten
Als experimentelles Feature lassen sich Agent Skills in GitHub Copilot verwenden. Entwicklerinnen und Entwickler können dem KI-Agenten dadurch neue Fähigkeiten beibringen und ihn beispielsweise mit domänenspezifischem Wissen füttern. Agent Skills bestehen aus Ordnern mit Anweisungen, Skripte und Ressourcen, die GitHub Copilot bei Bedarf laden kann. Sie sind ein offener Standard und wurden ursprünglich vom Unternehmen Anthropic entwickelt.
Zu den Vorteilen zählen laut Microsoft die Kombinierbarkeit mehrerer Skills für das Erstellen komplexer Workflows, die Spezialisierungsmöglichkeit für domänenspezifische Aufgaben ohne wiederholenden Kontext und das effiziente Laden ausschließlich relevanter Inhalte. Die Skills können zudem Wiederholungen vermeiden, da sie sich über alle Unterhaltungen hinweg verwenden lassen.
Das Erstellen und Verwenden von Agent Skills behandelt die VS-Code-Dokumentation im Detail. Dort kommen auch die Unterschiede zwischen den Agent Skills und den VS-Code-spezifischen benutzerdefinierten Anweisungen (Custom Instructions) zur Sprache.
Weiterlesen nach der Anzeige
Neuerungen in Agent-Sessions- und Chat-Ansicht
Die Agent-Sessions-Ansicht wurde überarbeitet: Sie bietet nun Keyboard-Zugang zu Aktionen wie „Archivieren“, „State lesen“ und „Session öffnen“, zeigt Informationen zu geänderten Dateien sowie zugehörigen Pull Requests für eine Session und kann aus den neuen Gruppenabschnitten heraus mehrere Sessions auf einmal archivieren.

Die Agent Sessions View bietet neue Funktionen.
(Bild: Microsoft)
Neuerungen gibt es auch im Chat. Unter anderem werden nun vorherige Chat-Sessions nicht automatisch wiederhergestellt, wenn VS Code neu gestartet wird. Allerdings lassen sich aus der Agent-Sessions-Steuerung frühere Chat-Sessions aufrufen. Dieses neue Verhalten lässt sich in der Einstellung chat.viewRestorePreviousSession anpassen.
Hausputz im Dezember
Im Rahmen des jährlichen Dezember-Housekeeping hat das VS-Code-Entwicklungsteam dieses Mal 5951 offene Issues und Pull Requests geschlossen. Für weitere 1203 Issues wurde eine Triage durchgeführt, sodass diese nicht länger unter „Unknown Type“ laufen.

Das VS-Code-Team hat aufgeräumt: 5951 offene Issues und PRs wurden im Dezember 2025 geschlossen.
(Bild: Microsoft)
Alle weiteren Informationen zu den Neuerungen in VS Code 1.108 teilt das Entwicklungsteam in der Ankündigung mit.
(mai)
Entwicklung & Code
Neu in .NET 10.0 [5]: Erweiterungsblöcke in C# 14.0
Die nachträgliche Erweiterbarkeit von Klassen um zusätzliche Methoden gibt es unter dem Namen Extension Methods bereits seit der C#-Sprachversion 3.0, die im Jahr 2007 zusammen mit .NET Framework 3.5 erschien. Dies ist sogar dann möglich, wenn die Klassen bereits an anderer Stelle kompiliert wurden, wie etwa die von Microsoft bereitgestellten Bibliotheken im .NET Framework.
Weiterlesen nach der Anzeige

Dr. Holger Schwichtenberg ist technischer Leiter des Expertennetzwerks www.IT-Visions.de, das mit 53 renommierten Experten zahlreiche mittlere und große Unternehmen durch Beratungen und Schulungen sowie bei der Softwareentwicklung unterstützt. Durch seine Auftritte auf zahlreichen nationalen und internationalen Fachkonferenzen sowie mehr als 90 Fachbücher und mehr als 1500 Fachartikel gehört Holger Schwichtenberg zu den bekanntesten Experten für .NET und Webtechniken in Deutschland.
Man kann mit Extension Methods aber lediglich eine Instanzmethode zu bestehenden Klassen ergänzen. So mussten Entwicklerinnen und Entwickler zwangsweise Konstrukte, die vom Namen her eigentlich Properties waren, leidigerweise als Methoden ausdrücken, siehe IsEmptyClassic() im nächsten Listing.
In der .NET-Klassenbibliothek gibt es aus diesem Grund einige Erweiterungsmethoden, die Namen besitzen, die man intuitiv als Property erwarten würde, darunter
Enumerable.Count()Queryable.Count()Enumerable.First()Enumerable.Last()
Folgender Beispielcode zeigt die klassischen Erweiterungsmethoden:
public static class StringExtensionClassic
{
public static string TruncateClassic(this string s, int count)
{
if (s == null) return "";
if (s.Length <= count) return s;
return s.Substring(0, count) + "...";
}
public static bool IsEmptyClassic(this string s)
=> String.IsNullOrEmpty(s);
}
In C# 14.0 bietet Microsoft nun mit dem neuen Block-Schlüsselwort extension eine verallgemeinerte Möglichkeit der Erweiterung bestehender .NET-Klassen, die Erweiterungsblöcke (Extension Blocks) oder Erweiterungsmitglieder (Extension Members) genannt werden.
Weiterlesen nach der Anzeige
Das Schlüsselwort extension muss Teil einer statischen, nicht generischen Klasse auf der obersten Ebene sein (also keine Nested Class). Nach dem Schlüsselwort extension deklariert man den zu erweiternden Typ (Receiver). Im nächsten Listing ist der Receiver die Klasse System.String (alternativ abgekürzt durch den eingebauten Typ string). Alle Methoden und Properties innerhalb des Extension-Blocks erweitern dann den hier genannten Receiver-Typ. Aktuell kann man in diesen Extension-Blöcken folgende Konstrukte verwenden (siehe nächstes Listing):
- Instanz-Methoden
- Statische Methoden
- Instanz-Properties
- Statische Properties
- Operatoren
Da es keine Instanzfelder (Fields) in Erweiterungsblöcken gibt, kann man mit Erweiterungsblöcken nicht den Zustand einer Klasse erweitern. Man kann nur bestehende Zustände lesen und verändern (sofern der Typ mutable ist).

Der Compiler meckert bei dem Versuch, eine Property mit Setter in einem Erweiterungsblock anzulegen.
Ein Erweiterungsblock darf beliebig viele Erweiterungsmitglieder enthalten. Eine Klasse darf mehrere Erweiterungsblöcke sowie zusätzlich auch klassische Extension Methods und andere statische Mitglieder enthalten. Das erlaubt Entwicklerinnen und Entwicklern, in bestehenden Klassen mit klassischen Erweiterungsmethoden nun noch die neuen Erweiterungsblöcke zu implementieren. Es darf auch mehrere Klassen mit Extension-Blöcken für einen Receiver-Typ geben.
Folgendes Codebeispiel zeigt die Erweiterungen für System.String mit C# 14.0:
public static class MyExtensions
{
// NEU in C# 14.0: // NEU in C# 14.0 Erweiterungsmitglieder (Schlüsselwort extension)
extension(System.String s) // <-- Receiver (Zielklasse).
{
///
/// Erweitern um eine Instanz-Methode (alternative Möglichkeit zur bisherigen Syntax)
///
public string Truncate(int count)
{
if (s == null) return "";
if (s.Length <= count) return s;
return s.Substring(0, count) + string.Dots;
}
///
/// NEU: Erweitern um eine Instanz-Eigenschaft nur mit Getter
///
public bool IsEmpty => String.IsNullOrEmpty(s);
///
/// NEU: Erweitern um eine Instanz-Eigenschaft mit Getter und Setter
///
public int Size
{
get { return s.Length; }
set
{
// Neuzuweisung geht nicht; Da Strings immutable sind, funktioniert die Setter-Logik so nicht!!!
if (value < s.Length) s = s.Substring(0, value);
if (value > s.Length) s = s + new string('.', value - s.Length);
}
}
///
/// NEU: Erweitern um eine statische Methode
///
public static string Create(int count, char c = '.')
{
return new string(c, count);
}
///
/// NEU: Erweitern um eine statische Instanz-Eigenschaft
///
public static string Dots => "...";
// NEU: Erweitern um eine Operatorüberladung
public static string operator *(string str, int i) // Operatorüberladung
{
return string.Concat(Enumerable.Repeat(str, i)); ;
}
// NEU: Operatorüberladung als Extension und neu ist auch, dass man ++ überladen kann
public void operator ++()
{
s = s + String.Dots; // Das funktioniert so nicht, da Strings immutable sind!!!
}
}
}
Folgender Code zeigt den Aufruf der Erweiterungsmethoden für die Klassen String und List:
public void Run()
{
CUI.Demo(nameof(CS14_ExtensionDemo) + ": String");
string s1 = "Hallo Holger";
Console.WriteLine($"Vorher: {s1}");
string s2 = s1.TruncateClassic(5);
Console.WriteLine($"Nach TruncateClassic(): {s1}"); // Hello...
Console.WriteLine($"IsEmptyClassic():{s2.IsEmptyClassic()}"); // false
string s3 = "Hallo Holger";
Console.WriteLine($"Vorher: {s3}");
string s4 = s3.Truncate(5);
Console.WriteLine($"Nach Truncate(): {s4}"); // Hello...
Console.WriteLine($"IsEmpty:{s4.IsEmpty}"); // false
string s5 = (s1 + "! ") * 3;
Console.WriteLine($"*3: {s5}"); // "Hallo Holger!Hallo Holger!Hallo Holger!"
string s6 = string.Create(5, '#');
Console.WriteLine($"string.Create(5, '#'): {s6}"); // "#####"
#region nicht möglich
CUI.H2("s1.Size = 5 --> das geht nicht, weil die Size Property versucht, die Zeichenkette neu zuzuweisen!");
// Das geht nicht, weil die Size Property versucht, die Zeichenkette neu zuzuweisen!
s1.Size = 5;
Console.WriteLine(s1); // "Hallo Holger" statt wie erwartet "Hallo"
s1++;
Console.WriteLine(s1); // "Hallo Holger" statt wie erwartet "Hallo Holger..."
#endregion
}

Ausgabe des Beispielcodes
(rme)
Entwicklung & Code
iOS: Apps können Mitteilungen geräuschlos ausliefern – ohne User-Kontrolle
Das Topangebot von Too Good to Go für leckere Donuts, die immer so schnell weg sind, oder die Information aus der Airthings-App, dass mit der Luft etwas nicht stimmt: Manche iOS-Mitteilungen (Notifications) scheinen wie verhext zu sein. Sie tauchen trotz der Tatsache, dass sie ganz normal in den Systemeinstellungen aktiviert sind, nur dann auf, wenn man das iPhone gerade aktiv bedient. Es gibt weder einen Auslieferungston noch, bei lautlosem Gerät, eine Vibration. In der Übersicht auf dem Sperrbildschirm sind sie ebenfalls zu sehen – nur eben erst dann, wenn man aktiv nachschaut. Das hat zur Folge, dass selbst vom Nutzer als wichtig angesehene Mitteilungen untergehen. Des Rätsels Lösung: Apple ermöglicht es Entwicklern, Mitteilungen auch „heimlich“ auszuliefern, eine Funktion im Code, die diese aktiv wählen müssen. Der Nutzer hat darüber dann allerdings keinerlei Kontrolle mehr, was viele nicht wissen.
Weiterlesen nach der Anzeige
Eine Konstante sorgt für Nerv
Seit iOS 15 können Developer für Mitteilungen nämlich auswählen, welchen „Interruption Level“ diese haben. Das Feature nennt sich UNNotificationInterruptionLevel, eine Konstante, die darlegt, wie wichtig eine Notification sein soll. Hier kann der Entwickler sie auf „Active“ stellen und damit ganz normal ausliefern – mit Aufleuchten des Bildschirms und Sound/Vibration. „Critical“ gibt die Mitteilung auch mit Ton aus, wenn das Gerät lautlos gestellt wurde. „TimeSensitive“ macht aus der Mitteilung eine „dringliche Mitteilung“, die auch einen Fokus durchbrechen kann.
Und dann gibt es noch „Passive“, also passiv. Und genau das ist die nervigste Variante für User, die informiert bleiben wollen: „Das System fügt die Benachrichtigung zur Benachrichtigungsliste hinzu, ohne den Bildschirm hell zu machen [falls das Gerät nicht verwendet wird] oder einen Ton abzuspielen.“ Das Problem betrifft auch die Apple Watch: Auch dort werden solche Mitteilungen lautlos ausgeliefert und landen nur in der Mitteilungsübersicht.
Entwickler nehmen Nutzern Einstellmöglichkeiten
Warum Developer für ihre Mitteilungen manchmal „Passive“ wählen, lässt sich schwer sagen. Eventuell denken diese, dass sie die Kunden nicht mit Mitteilungen überfrachten sollten. Manchmal ändert sich die Einstellung auch von App-Version zu App-Version – so geschehen bei erwähnter Airthings-App, die früher alle Warnungen sichtbar auslieferte. Dass damit dann möglicherweise wichtige Informationen schlicht verpasst werden, nehmen die Developer hin. User können wenig tun, sich nur bei den Entwicklern / App-Herstellern melden und diese bitten, doch wieder eine Änderung durchzuführen, damit Mitteilungen normal (UNNotificationInterruptionLevel auf „Active“) ausgeliefert werden.
Normal heißt dann, dass sich wie gewohnt über die Systemeinstellungen auswählen lässt, ob die Mitteilung einer App einen Benachrichtigungston und/oder eine Vibration hat – eine Sache von wenigen Sekunden. Entwickler, die fürchten, User mit zu vielen Mitteilungen zu überfrachten, können diesen erklären, wie sie hier gegebenenfalls vorgehen, statt ihnen die Entscheidung einfach abzunehmen. Und Apple sollte darüber nachdenken, ob sich die heimliche Auslieferung nicht über einen zentralen Knopf einfach abdrehen lassen könnte, wenn Nutzer dies wünschen. Hinzu kommt: Potenziell nervige Apps – von der Uber-Werbung bis zu Facebook – liefern ihre Mitteilungen natürlich niemals lautlos aus.
Weiterlesen nach der Anzeige
(bsc)
-
UX/UI & Webdesignvor 3 MonatenIllustrierte Reise nach New York City › PAGE online
-
Künstliche Intelligenzvor 3 MonatenAus Softwarefehlern lernen – Teil 3: Eine Marssonde gerät außer Kontrolle
-
Künstliche Intelligenzvor 3 Monaten
Top 10: Die beste kabellose Überwachungskamera im Test
-
UX/UI & Webdesignvor 3 MonatenSK Rapid Wien erneuert visuelle Identität
-
Entwicklung & Codevor 2 MonatenKommandozeile adé: Praktische, grafische Git-Verwaltung für den Mac
-
Künstliche Intelligenzvor 3 MonatenNeue PC-Spiele im November 2025: „Anno 117: Pax Romana“
-
Künstliche Intelligenzvor 3 MonatenDonnerstag: Deutsches Flugtaxi-Start-up am Ende, KI-Rechenzentren mit ARM-Chips
-
UX/UI & Webdesignvor 2 MonatenArndt Benedikt rebranded GreatVita › PAGE online
