Handoff - komplex oder liegt's an mir

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Handoff - komplex oder liegt's an mir

    Hallo zusammen!

    Hat jemand von Euch schon einmal Handoff in mehr als nur einer "Single-View"-App implementiert?

    Ich pirsche mich so langsam an das Prinzip heran: Viele Delegate-Methoden und noch mehr Log-Ausgaben später habe ich ein ungefähres Verständnis über den Ablauf. Ein grundsätzlicher Punkt ist mir aber noch unklar:
    • Warum sollte man mehrere unterschiedliche Activities einführen? Mein Anspruch wäre, die App in ihrem aktuellen Zustand auf einen anderen Gerät weiter zu benutzen. Also bräuchte ich doch nur eine User Activity, die immer alle Informationen beinhaltet, den aktuellen Stand wiederherzustellen.
    • Diese Aktivität ist dann auch für die neue State Restoration via SceneDelegate nutzbar.
    Mehrere Aktivitäten könnte ich mir nur für Spotlight / Siri sinnvoll vorstellen.

    Habe ich etwas missverstanden? Wer hat Erfahrung mit Handoff (idealerweise sogar in Kombination mit der neuen Store Restauration) und hilft mir auf's Pferd?

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • Moin!

    Ich renne die ganze Zeit mit dem Kopf gegen die Wand und brauche Hilfe ?(

    Bei dem Versuch, Handoff - und darauf aufsetzend State Restoration für iOS 13 - einzusetzen, scheitere ich an einer sehr grundlegenden Sache: Das Datenmodell meiner App basiert auf Core Data und für die "Wiederherstellung" muss ich Object-Referenzen von einem Gerät an das andere übermitteln. Leider sind die ObjectIDs bzw. ihre URIRespresentations auf den Geräten unterschiedlich, auch wenn das Core-Data-Modell mittels CloudKit synchronisiert wurde.

    Irgendwie verständlich, aber wie soll ich nun den Status des einen Gerätes auf dem anderen reproduzieren? Das hiesse in Konsequenz ja, dass ich in meinem Datenmodell einen eigenen Identifier vorsehen müsste ... das konnte ich bisher erfolgreich vermeiden.

    Any ideas?

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • Ich fürchte, das funktioniert nur über einen „event-based data storage“.
    Also statt „Ich halte die aktuellen Zustände meiner Daten im Speicher vor“ ein „Ich halte jede einzelne Änderung an meinen Daten im Speicher vor“. Also so‘n bisschen Git/SVN mäßig.

    Ob und wenn ja wie einfach das mit Cloud Kit umzusetzen ist weiß ich nicht. Dass das Unmengen an Serverspeicher braucht ist mir auch klar.
    Da gabs auf der Macoun mindestens einen inspirierenden Talk zum Thema.
    Ich such schnell…

    Ah: macoun.de/material2018.php
    Leider nur das Material zu „Effizientes Offline-First-Sync: Ein Überblick“

    Vermutlich ist Dir der 2019er „Die Magie hinter Handoff und Continuity“ (zu Finden auf macoun.de/material2019.php) bereits bekannt, vielleicht aber auch eher hilfreich für einen zweiten Wurf. ¯\_(ツ)_/¯

    Mein eigenes „Ich mach was mit CloudKit und HandOff und Krams“ liegt irgendwie immer mal wieder auf Eis, weshalb ich da aktuell keine praktischen Erfahrungen vorweisen kann – außer von der Nutzung, und die ist wirklich genial!
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
  • Traue ich mich jetzt zu sagen, dass ich nicht an die Macoun-Talk gedacht habe? Shame on me und danke für den Stups ... auch wenn es dort mehr um die Kommunikations-Interna von Handoff geht.

    Ich befand mich eben in einer Zwickmühle: Das Problem der Objektreferenz halte ich mit einer eigenen ID für lösbar: Klar gibt es ein paar Edge-Cases, wo z. B. das referenzierte Objekt noch nicht gesyncht wurde, aber das lässt sich händeln. Es ist halt "nur" Aufwand.

    Kritischer ist das komplette Restore einer komplexeren View-Hierarchie, insbesondere da der UISplitViewController im internen Aufbau zwischen iPhone und iPad unterscheidet. Letztlich muss man eben vom Root ausgehend alle Benutzer-Aktionen nachbilden und die entsprechenden Informationen in der NSUserActivity ablegen. Kann man machen, aber das stabil für jeden App-Zustand hinzubekommen, ist für mich momentan Overkill.

    BTW, die "legacy state restoration" habe ich nun in knapp einem Tag implementiert ... dabei allerdings auch in alten Apps gespiekt. Ich kann noch immer nicht glauben, dass Apple dieses Prinzip mit automatischer Speicherung der View-Hierarchie mittels restorationIdentifier komplett über Bord geworfen hat.

    Schönen Restsonntag, Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • Ich denke und hoffe ja, dass sie im Rahmen von SwiftUI noch mehr UIKit/AppKit Altlasten über Board kippen. ;)

    Stimmt, es ist nur Arbeit. Wenns nicht zwingend notwendig ist, lässt es sich sicherlich hinten an stellen.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P