knuspermagier.de
Since 2005.

BetterReminders (2)

Wie versprochen ein paar weitere Gedanken zu diesem kleinen SwiftUI-Experiment.

Mein Ziel ist es ja irgendwie, eine brauchbare App zu bekommen, an der ich auch tatsächlich mehr Spaß habe, als an der originalen Reminders-App. Ich will alles ein kleines bisschen mehr so haben, wie Things das macht. Allerdings habe ich mir auch ein paar Grenzen gesetzt, da ich auch nicht ein zu großes Fass aufmachen wollte.

Zum Beispiel will ich es eigentlich auf jeden Fall vermeiden, dass ich Daten zusätzlich speichern muss. Es wäre super, wenn nur die Reminders-API anbinden müsste und alles über die dort enthaltenen Daten abfrühstücken kann.

Leider fand ich bei der Recherche nach ein paar Features direkt ein paar nervige Probleme, die mir diesen Wunsch leider kaputt machen. So hat EKReminder zum Beispiel gar keine Property oder Funktion um an die Tags eines Reminders zu kommen. Danke, Apple. Eigentlich wollte ich ja smartere Smart Lists bauen, aber wenn ich die Tags gar nicht auslesen kann, fällt mir das etwas schwer. Also, was tun? Tags selber führen, was am Ende bedeutet, dass die Todos in der normalen App einfach keine Tags haben? Dumm.

Des Weiteren gibt es keine Möglichkeit die manuelle Sortierung zu ändern. Ich bekomme die Reminder zwar in der Reihenfolge, wie sie auch sonst angezeigt werden, aber ich kann das natürlich nicht wieder speichern, falls ich in meiner App etwas an der Sortierung ändern würde.

Wie ich gelesen habe, bekommt man auch keine Informationen über Subtaks, was blöd ist, aber mir erstmal egal, da ich keine verwende.


Da ich noch recht viel einbauen müsste, um die App wirklich benutzen zu können, wie etwa… Drag and Drop, das Anlegen von Todos und all so Kram und es mich echt ziemlich nervt, dass man nicht an die Tags kommt, bin ich doch relativ demotiviert, das weiter zu bauen und werde mich vielleicht doch eher mit der Stock-App arrangieren.


Oder, ach komm, mal gucken wie Drag and Drop funktioniert, kann ja auch nicht schaden.

Es funktioniert. Auch gar nicht so schlimm. Letztendlich packt man an den View, der gedraggt werden soll ein .onDrag() dran, dass einen NSItemProvider returned, in den man Dinge reinstopfen kann, die in dem Drag-Vorgang übertragen werden sollen. Das Ziel bekommt ein .onDrop, in dem quasi entschieden wird, ob das gedraggte Ding angenommen werden soll, oder nicht. Interessanterweise läuft das noch über Delegates, ein Begriff, der mir noch aus den guten [[alten Zeiten] alloc] init] (alter Objective C-Witz!!) geläufig ist. Auch die Tatsache, dass man einen NSItemProvider braucht deutet ja schon darauf hin, dass hier noch ein bisschen was altes rumhängt. Aber es funktioniert.

Also, sobald man ein paar Stunden herumprobiert hat, an welches Element genau man jetzt das .onDrop() dran hängt. Als ich es am VStack bzw an der List hatte, die die Todolisten rendert, ging es jedenfalls nicht. Im Nachhinein brauchte ich das auch gar nicht, ich wollte ja eigentlich Todos auf andere Todolisten ziehen können, also ist nun auch genau der entsprechende Kalender-Eintrag das Drop-Ziel, aber wenn ich mal eine Drag'n'Drop-Sortierung in der Liste implementieren will, müsste ja eigentlich... die Liste der Drop-Empfänger sein? Naja, das ist eine Übung für ein anderes mal. Ist wahrscheinlich auch eher verwirrend, diese unklaren Gedankengänge zu lesen!

Jedenfalls musste ich nicht nur ein bisschen Herumprobieren sondern mich auch mal comitten, das ganze Datenhandling etwas aufzuräumen und langsam raus aus meiner Proof of Concept-Phase herauszutreten. Eigentlich fehlt jetzt nicht mehr viel, bis ich mein selbstgestecktes MVP-Ziel erreicht habe. Todos anlegen wäre also das Nächste!

Kommentare, Feedback und andere Anmerkungen?
Schreib mir eine E-Mail 🤓