Mein Kind liebt Flugzeuge immer noch, also habe ich das Radar upgegradet

 (substack.com/jacobbartlett)
1 Punkte von GN⁺ 2024-01-23 | 1 Kommentare | Auf WhatsApp teilen
  • Die persönliche iOS-Radar-App Aviator 2.0 funktioniert nach den Ausfällen des OpenSky Network seit Anfang Dezember wieder und bündelt in diesem Update zugleich zahlreiche Verbesserungen, die sich im realen Einsatz gezeigt haben
  • Das neue Kontrollmenü nutzt eine Struktur der progressiven Offenlegung, trennt wichtige Bedienungen von erweiterten Werkzeugen und verdeckt den Radarbildschirm dank SwiftUI modal detent und Hintergrundinteraktion weniger
  • Das Problem, dass auch zu weit entfernte Flugzeuge erfasst wurden, wurde mit einem binären Zoom-Umschalter reduziert, der durch das Wechseln der MapKit camera distance auf 70 km oder 100 km umgesetzt wird
  • Mithilfe der Daten origin_country, Höhe und category aus der OpenSky Network API kamen Flaggenanzeige, ein Tiefflugfilter für trübe Tage sowie unterschiedliche Icons für Hubschrauber, Satelliten und Flugzeuggrößen hinzu
  • Nutzer können mit ihren OpenSky-Network-Login-Daten HTTP Basic Auth verwenden, aber in Version 2.0 wird das Passwort in User Defaults gespeichert, weshalb sensible Passwörter nicht wiederverwendet werden sollten

Hintergrund zum Update Aviator 2.0

  • Aviator — Radar on your Phone ist eine iOS-Radar-App, die gebaut wurde, um zusammen mit einem Kind Flugzeuge zu finden
  • Nach dem vorherigen Beitrag hätte man über ein neues Release und Monetarisierung nachdenken können, aber die App zeigte Nutzern seit Anfang Dezember wegen Ausfällen beim OpenSky Network nur Fehler an
  • Als die App erneut geöffnet wurde, war statt des ständig sichtbaren 502-Fehlers wieder der Benachrichtigungston zur Flugzeugerkennung zu hören, was bestätigte, dass sie wieder normal funktionierte
  • Danach wurde an zwei Abenden an Aviator 2.0 gearbeitet und bestehende Ideen wurden umgesetzt

Neue Kontroll-UI, die das Radar weniger verdeckt

  • In 2.0 wurden die Bedienelemente in ein separates Menü verschoben; wichtige Aktionen stehen oben, seltener genutzte erweiterte Werkzeuge weiter unten
  • Diese Struktur verwendet progressive Offenlegung (progressive disclosure)
  • Das Menü ist als SwiftUI modal umgesetzt und hat zwei presentationDetents
    • primary: 0.15 der Bildschirmhöhe
    • extended: 0.4 der Bildschirmhöhe
  • Ein Drag-Indikator zeigt, dass sich das Menü erweitern lässt, und mit presentationBackgroundInteraction(.enabled) wird verhindert, dass die Haupt-Radar-UI von einem Schatten überdeckt wird
  • Auf presentationBackground wird Paul Hudsons emboss effect angewendet, um eine metallische Textur wie bei einem echten Radar-Bedienpult hinzuzufügen
  • Für 2.1 ist geplant, TipKit zu nutzen, damit auch junge Apple-Nutzer die Struktur der progressiven Offenlegung besser erkennen

Zoom-Stufe und Radarreichweite anpassen

  • In 1.0 funktionierte das Radar fast zu gut und erfasste sogar Flugzeuge hinter dem Horizont oder hinter Gelände, die in Wirklichkeit nicht sichtbar waren
  • In Umgebungen wie den Vororten Londons mit stufenförmigem Gelände und inselartig verbundenen Bereichen wurde das im praktischen Einsatz störend
  • In offenen Gegenden waren weit entfernte Flugzeuge dagegen tatsächlich sichtbar, daher war es nicht einfach nur ein Empfindlichkeitsproblem
  • Die Lösung war die Einführung einer Zoom-Funktion
  • Über die distance der camera im MapKit SDK in Metern wird das Hinein- und Herauszoomen der Erdoberfläche umgesetzt
    • Wenn zoomed true ist: 70 * 1_000
    • Wenn false: 100 * 1_000
  • Für einen schnellen Release am Wochenende wurde die Funktion zügig umgesetzt und zur stärkeren Betonung der vergrößerten UI ein Radar-Kreis entfernt
  • Ursprünglich sollte ein Slider die Zoom-Stufe steuern, aber selbst auf einem A17-Chip war die Framerate nicht hoch genug, daher wird derzeit ein binärer Zoom-Umschalter verwendet

Zusätzliche Funktionen durch Daten des OpenSky Network

  • Flaggenanzeige

    • Die OpenSky Network API sammelt verschiedenste Informationen aus Flugzeug-Transpondern, aber in 1.0 wurden diese Daten nicht ausreichend genutzt
    • In 2.0 wurde ein Umschalter hinzugefügt, der unter jedem Flugzeug-Icon das Herkunftsland als Flaggen-Emoji anzeigt
    • Die Umsetzung basiert auf dem Wert origin_country
    • Es wird die vom API gelieferte Textzeichenfolge des Herkunftslands verwendet
    • Diese wird mithilfe einer online gefundenen Liste von Ländernamen in einen zweistelligen Ländercode umgewandelt
    • Der Ländercode wird in Unicode-Skalare umgewandelt, um das Flaggen-Emoji zu erzeugen
    • Wenn Nutzer die Funktion aktivieren, wird flight.flag als Text der MapKit annotation angezeigt

  • Modus für trübe Tage

    • An trüben Tagen in Großbritannien waren viele der in der App angezeigten Flugzeuge in Wirklichkeit hinter Wolken verborgen
    • Es wurde ein Button hinzugefügt, der hoch fliegende Flugzeuge ausblendet, sodass zwischen einem klaren Modus und einem Regenmodus gewechselt werden kann
    • Dabei werden die vom OpenSky Network gelieferten Höhendaten genutzt; als Basiswert für niedrige Wolken werden 2,5 km verwendet
    • Wenn geo_altitude < 2500.0 ist, wird isLowAltitude true
    • Wenn die Einstellung cloudy aktiviert ist, werden in den MapKit annotations nur Flugzeuge in niedriger Höhe angezeigt

Verbesserte Flugzeug-Icons

  • Beim Testen im Park flog ein Hubschrauber direkt über den Kopf hinweg, aber Aviator zeigte ihn als normales Flugzeug-Icon an
  • Die OpenSky Network API liefert mit einem zusätzlichen Query-Parameter die Eigenschaft category, die den Flugzeugtyp des jeweiligen Transponders angibt
  • Diese Kategorie kann unter anderem Folgendes enthalten
    • leichte Flugzeuge unter 15.500 Pfund
    • schwere Flugzeuge über 300.000 Pfund
    • Drehflügler wie Hubschrauber
    • Raum-/atmosphärenüberschreitende Fahrzeuge
    • Fallschirme oder Fallschirmspringer
  • Im neuesten Update werden nun Größenklassen von Flugzeugen unterschieden, und Satelliten sowie Hubschrauber erhalten eigene Icons
  • Im Enum AircraftCategory werden Bild, Emoji und Skalierungswert getrennt
    • rotorcraft verwendet das SFSymbol xmark.circle.fill
    • spaceTransatmospheric verwendet das Emoji 🛰️
    • small, large, heavy verwenden die Skalierungen 0.6, 1, 1.5
  • Das Hubschrauber-Emoji wirkte nach der Umwandlung in eine einfarbige flache Darstellung zu rundlich, daher wurde ein abstrakteres SFSymbol mit Kreuz in einem Kreis gewählt
  • Um Emojis wie Bilder zu behandeln, wird Text skaliert und dann als Maske für ein Rectangle verwendet, worauf Farbe und ein CRT-Bildschirmeffekt angewendet werden

OpenSky-Network-Login für Nutzer

  • Es wurde eine Funktion hinzugefügt, mit der Nutzer ihre eigenen OpenSky-Network-Zugangsdaten eingeben können
  • Diese Funktion war nach der Android-Version eine der am häufigsten gewünschten und soll Rate Limiting bei nicht authentifizierter API-Nutzung vermeiden
  • Im vollständigen Kontrollmenü können Kontodaten eingegeben werden; außerdem gibt es einen Link zur Registrierungsseite
  • Die Umsetzung erfolgt mit TextField und SecureField in SwiftUI
    • @AppStorage("username")
    • @AppStorage("password")
  • In 2.0 wird das Passwort bei der schnellen Produktivsetzung in User Defaults gespeichert
  • Im nächsten Release soll es im Keychain gespeichert werden; bis dahin sollten keine sensiblen Passwörter wiederverwendet werden
  • Eingegebener Benutzername und Passwort werden Base64-kodiert und als Basic-Authentifizierung im Authorization-Header an API-Anfragen angehängt

Abschluss

  • Aviator 2.0 ist ein Update, das eine App zum Spielen und Entdecken mit einem Kind weiter verbessert
  • Es wird um Kommentare mit Funktionsideen oder ASO-Tipps gebeten sowie um Downloads und Bewertungen für Aviator — Radar on your Phone 2.0

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-01-23
Hacker-News-Kommentare

  • Fortsetzung eines Beitrags, der vor zwei Monaten ziemlich populär war
    0: https://news.ycombinator.com/item?id=38435908 My toddler loves planes, so I built her a radar (1304 points, 56 days ago)

  • Beim Blick auf die App musste ich an ein Problem denken, das ich damals beim Programmieren von DVDs hatte. Bei Toggle-Buttons ist nicht klar, welcher Modus gerade aktiv ist
    Es ist verwirrend, ob das Flaggen- oder Wolken-Icon den aktuellen Modus zeigt oder ob man darauf drücken muss, um in diesen Modus zu wechseln. Auch beim Wetter-Toggle fühlt es sich umgekehrt an: Bedeutet ein Druck auf die Wolke, dass man den bewölkten Modus sehen will, oder dass man zur klaren Ansicht wechseln will?
    In meinem aktuellen Projekt ändern +/- Buttons die Größe eines Zeitfensters: Bei der Startzeit verringert + den Sekundenwert und - erhöht ihn. Bei der Endzeit ist es umgekehrt. Aus Sicht der Fenstergröße verhalten sich beide wie erwartet, deshalb muss am Ende die Perspektive des Nutzers eindeutig gemacht werden

    • Das ist genau das, was ich an moderner UX am meisten hasse, besonders bei TV-Apps. Wenn von zwei Menüpunkten einer fett weiß und der andere fett schwarz ist, weiß ich nicht, was ich gerade anklicken will
      Auch der Untertitel-Toggle von YouTube wechselt zwischen weißer Schrift auf schwarzem Grund und schwarzer Schrift auf weißem Grund, sodass man erst einmal drücken muss; wenn sich die Lippen bewegen, aber keine Untertitel erscheinen, muss man den anderen Icon-Modus ausprobieren
      Mit dem Übergang zu Touchscreens scheint der gesunde Menschenverstand für zustandsbehaftetes Positions-Input-Feedback verloren gegangen zu sein
    • Stimmt. Ich glaube, ich war etwas zu sehr darauf fixiert, es wie ein Bedienpanel aussehen zu lassen, statt die UX wirklich gut zu machen
      Und ja, es war tatsächlich verwirrend. Bei einem Bugfix in letzter Minute habe ich ausgerechnet das Wolken-Icon umgekehrt zu den anderen eingebaut und so veröffentlicht

  • Es wäre wirklich cool, wenn ein Flugzeug beim Durchlauf des Radarscans kurz aufblitzen würde und dann an fester Position bis zum nächsten Sweep langsam verblasst
    Außerdem wäre es schön, anhand der aktuellen GPS-Höhe und Position des Geräts sowie der umliegenden Gebäude, Hügel und Höhen aus OpenStreetMap die je Azimut sichtbare Skyline zu berechnen. Dann könnte man das auf der Karte wie Radarabschattung darstellen. So ähnlich wie ein Fischfinder, der durch einen Baumstamm blickt, oder Schiffsradar, bei dem andere Schiffe etwas verdecken
    Wenn man das baut, würden sich Leute aus der Branche wohl am Kopf kratzen und sich fragen, wie ein Telefon radiale Scans macht
    [1] https://www.researchgate.net/figure/Occlusion-percentage-for...

    • Das sind alles tolle Ideen. Die aktuelle App ist eher die Pareto-Version der potenziell möglichen 100-%-Vollversion

  • Das hatte ich schon im Blog geschrieben, aber als Elternteil eines Kleinkinds stimme ich zu, dass die Farbauswahl der wichtigste Teil ist
    Ich habe ein paar Funktionsideen, die vielleicht noch nicht umgesetzt sind, weil es ja ein lustiges Nebenprojekt ist. Erstens eine Live View, die mit der Handykamera und den AR-Funktionen des iPhone einen Punkt an die ungefähre Position des Flugzeugs setzt. Ich habe schon ein wenig Code geschrieben, der das aus Nutzerposition und ADS-B-Informationen berechnet
    Zweitens könnte man Flugzeuge als „gesehen“ oder „verpasst“ markieren und dieses Feedback nutzen, um die Anzeige anzupassen
    Drittens: Badges und Statistiken. Wenn deine Tochter meinem Kind ähnelt, wird sie es lieben, in der App Badges zu bekommen. Man könnte frühere Beobachtungen in einer lokalen DB speichern und Dinge wie „Anzahl gesehener Airlines“, „Anzahl gesehener Flugzeugtypen“, „längste Flugzeit“ oder „kürzeste Flugzeit“ verfolgen. Ich verstehe allerdings gut die Probleme, die mit Gamification bei Apps für Kinder einhergehen

    • Es mag etwas altmodisch klingen, aber ich versuche meinem Kind immer wieder zu vermitteln, dass es sich wünschen soll, Produzent von Technologie zu sein, statt nur Konsument von Technologie
      Wir sprechen oft darüber, warum man keine 30 Dollar für digitale Währungen wie Robux ausgeben sollte. Ich erkläre, dass das etwas anderes ist als Dinge mit echtem Wert, etwa ein Tennisschläger oder Schuhe
      Deshalb wehre ich mich gegen Gamification und versuche, ihm Werkzeuge zu geben, damit es nicht stundenlang in repetitive Aufgaben hineingezogen wird, nur um Badges oder wertlose digitale Artefakte zu bekommen
      Bei einer App für Kinder würde ich solche Funktionen lieber weglassen. Man kann zeigen, dass es Apps gibt, die keine Werbung haben und nicht gamifiziert sind, dem Leben aber echten Wert hinzufügen
    • Vielen Dank für die Ideen. Ich frage mich, ob ich für Punkt 1 eine Vision Pro auftreiben kann

  • Hätte jemand aus der HN-Community Lust, ein Open-Source-Crowdsourcing-Projekt zu starten, um das auf Android zu portieren?
    Die Lizenz ist nur eine Vermutung, aber wer das initiale GitHub-Repository anlegt, könnte wohl die Formulierung des Autors verwenden: „Ich warte darauf, dass ein ambitionierter Android-Engineer es selbst portiert. Ich habe genug Details in den Beitrag gepackt. Solange es für alle kostenlos bleibt, ist es in Ordnung.“

    • Danke für diesen Vorschlag. Ich habe noch nie eine Mobile-App gebaut, würde es aber gern lernen
      Selbst wenn ich zu dieser Radar-App keine hochwertige Android-App beitragen kann, wäre es wahrscheinlich gut investierte Zeit, etwas zu portieren, das zum Paradigma „An app can be a home-cooked meal“[0] passt. Es ist vermutlich mit einer einheitlichen Vision und einem klaren Paradigma geschrieben und frei von Bloat, Werbung, Tracking usw., sodass der Code leichter zu verstehen sein dürfte
      Dieser Vorschlag könnte mich vielleicht wieder zur Freude am Programmieren führen
      0: https://news.ycombinator.com/item?id=38877423
    • Ich habe keine Kapazität für langfristige Wartung, könnte aber wohl ein wenig beitragen. Meine E-Mail steht im Profil

  • Etwas anderes, aber als jemand mit schlechtem Orientierungssinn ist für mich die wichtigste Funktion auf dem Smartphone, wie genau der kleine Pfeil auf der Karte zeigt, in welche Richtung ich schaue.
    Ich nutze Android; wenn es sich nicht sicher ist, zeigt es einen blauen Unsicherheitskegel an und fordert mich manchmal auf, das Handy in einer Acht zu bewegen oder zur Kalibrierung auf Gebäude in der Umgebung zu zeigen.
    Wo liegen hier technisch die Grenzen? Ist das iPhone besser als Android? Liegt es an der Hardware, am Beschleunigungssensor, am Kompass, am GPS-Signal oder an der Software? Es verwirrt mich immer noch ziemlich oft und zeigt den Kegel in die völlig falsche Richtung. Wenn das iPhone das deutlich besser kann, wäre mir das fast wichtig genug, um zu wechseln.

    • Schön, dass du das ansprichst. Im Originalbeitrag habe ich dieselbe Beobachtung gemacht.
      Ich dachte, es gäbe Einschränkungen auf GPS-Seite, aber der Heading-Delegate von CoreLocation liefert zumindest bei der 120-Hz-Bildrate meines Geräts die Richtung perfekt zurück.
      Vielleicht ist Google Maps einfach nicht besonders gut.
    • Als jemand, der beides ähnlich häufig nutzt: Android reicht eher die rohen Sensorwerte durch, während iOS anscheinend eine Art Debounce-Verzögerung und Schätzung einbaut.
      Beide liegen ähnlich oft mit der Richtung daneben. Das ist allerdings nur eine Einschätzung aus der Nutzungserfahrung, keine gesicherte Tatsache.
    • Apple-Produkte und -Animationen setzen im Allgemeinen stärker auf Glättung und Hysterese. Es wirkt, als würden sie dem Nutzer Genauigkeit verbergen, damit der Pfeil nicht stark zittert; Android-UIs scheinen Artefakte aus der verrauschten GPS/IMU-Fusion und der inhärenten Ungenauigkeit des Magnetometers eher direkt zu zeigen.
      Früher war unter iOS der träge Pfeil ziemlich nervig, inzwischen fällt mit schnellerer Hardware eher der springende Pfeil anderer Plattformen auf.
      Kurz gesagt: Die meiste aktuelle Hardware ist ähnlich gut darin, die eigene Position in Raum und Zeit recht genau zu erfassen. Wie gut aber mit den aktuellen Daten Koppelnavigation und Lagebestimmung funktionieren und wie die von Nutzern erwartete Rauschfilterung in der Hand umgesetzt wird, unterscheidet sich je nach Navigationssoftware.

  • Durch die Tony-Hawk-Spiele bin ich zu Heavy Metal gekommen. Motörheads „Ace of Spades“ in THPS3 und Iron Maidens „Number of the Beast“ in THPS4 waren der Auslöser; es könnte also einen Brotkrumenpfad von Plattformspielen zu Heavy Metal geben.

  • Gut gemacht, denn der wichtigste Nutzer wurde eindeutig glücklich gemacht.

  • Cool. Außerdem bekomme ich Lust, ein !remindme zu setzen, um in 18 Jahren zu prüfen, ob die Tochter die Fluglotsenprüfung bestanden hat.

    • Sie ist jetzt 2, und eine Flugschülerlizenz kann man ab 16 bekommen, also sollte die Erinnerung auf in 14 Jahren gesetzt werden.
    • Bekommt man kostenlose Flüge, wenn die Tochter Pilotin wird? Vielleicht verpasse ich gerade eine Gelegenheit, sie unauffällig in Richtung STEM zu lenken.

  • Ich frage mich, ob Kinder auch in der Welt nach 9/11 noch ins Cockpit eingeladen werden können.

    • Mein Vater war Pilot, und unsere Familienurlaube richteten sich oft nach seinem Flugplan. Als kleines Kind nach dem Pushback ins Cockpit eingeladen zu werden und die „Triebwerke zu starten“, war das Stolzeste, was ich je erlebt hatte.
      Ich erinnere mich vage daran, einen Knopf gedrückt zu haben, während mein Vater auf die sich bewegenden Instrumente zeigte. Klar in Erinnerung ist mir das Gefühl, auf dem Weg zurück zum Sitz das größte Kind der Welt zu sein.
      Nach 9/11 dürfte so etwas wohl definitiv schwer passieren.
    • Ich habe im Internet den Tipp gesehen, dass man nicht vor dem Start fragen sollte, wenn ein Kind das Cockpit sehen möchte. Zu dem Zeitpunkt haben die Piloten mit Checklisten und Vorbereitungen viel zu tun.
      Wenn man dagegen nach der Landung fragt, ob das Kind das Cockpit sehen darf, sind die Erfolgschancen deutlich höher.
    • Unsere Kinder waren auch nach 9/11 im Cockpit. Allerdings muss es vor dem Start sein.
      Während des Flugs lassen sie kaum noch Crew hinein, gelegentlich darf nur die leitende Flugbegleitung hinein. Die Kinder fragen beim Einsteigen, wenn die Cockpittür noch offen ist.
    • Am 1. Januar 2024 wurde ein sechsjähriges Kind zum ersten Mal ins Cockpit eingeladen. Bis zu diesem Moment hatte ich mich dasselbe gefragt.
      Es war ein US-Inlandsflug mit JetBlue.
    • Ich habe schon gesehen, wie so etwas am Gate passiert. Die Piloten lassen die Tür normalerweise offen, sodass man hingehen und sie ansprechen kann. Im schlimmsten Fall wird man abgewiesen, also lohnt es sich zu fragen.
      Irgendwo habe ich noch die Delta-Flügelanstecknadel, die ich als Kind auf einer Reise bekommen habe, als ich unterwegs das Cockpit sehen durfte. Das war eine tolle Erfahrung, an die ich mich bis heute erinnere, und ich hoffe, dass andere Kinder wenigstens einen Teil davon erleben können.