Variable von AppDelegate in allen Klassen verfügbar machen?

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

  • Wenn Du das 'warten' explizit als 'Fängt schon mal an und fährt dann fort.' verstanden hast, dann habe ich meine Interpretation von 'warten' als 'Fängt erst an, wenn es so weit ist' offenbar nicht verständlich genug mitgeteilt – was vermutlich daran lag, dass ich diese Interpretation vorausgesetzt habe.

    Also nicht Warten im Sinne von 'Lauf zum Bahnhof und wenn die Bahn kommt hol Mama ab.' sondern Warten im Sinne von 'Die Bahn ist da. Lauf zum Bahnhof und hol Mama ab.'
    «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
  • Marco Feltmann schrieb:

    Wenn Du das 'warten' explizit als 'Fängt schon mal an und fährt dann fort.' verstanden hast

    Das ist die übliche definition von 'warten'.

    Marco Feltmann schrieb:

    meine Interpretation von 'warten' als 'Fängt erst an, wenn es so weit ist

    Da wartet aber nicht viewDidLoad, sondern der ViewController, der viewDidLoad aufruft. Und der ViewController wartet streng genommen auch nicht, sondern führt verschiedene Methoden in einer definierten Reihenfolge aus.

    Marco Feltmann schrieb:

    Also nicht Warten im Sinne von 'Lauf zum Bahnhof und wenn die Bahn kommt hol Mama ab.'

    Hier wartet der Abholer.

    Marco Feltmann schrieb:

    sondern Warten im Sinne von 'Die Bahn ist da. Lauf zum Bahnhof und hol Mama ab.'

    Hier wartet der den Abholer Beauftragende, um die Abholung zu beauftragen.
  • gandhi schrieb:

    Michael schrieb:

    Hier wartet der den Abholer Beauftragende, um die Abholung zu beauftragen.


    So wie sich das anhört, solltest Du dich zum Bürokratie-Beauftragten fortbilden. Oder Dich in Brüssel bei der EU-Kommision zur Formulierung von unverständlichen Verordnungen bewerben. Die suchen immer fähige Leute ;)

    Ja, ja, spotte du nur. ;)
    Ich hätte zu Marcos Ausführungen zur viewDidLoad auch nichts gesagt, wenn nicht ausgerechnet in diesem Thread der Threadersteller hier zu der Annahme gekommen wäre, Methoden würden irgendwie während ihrer Ausführung auf magische Weise auf etwas anderes warten.
  • Michael schrieb:

    Ich hätte zu Marcos Ausführungen zur viewDidLoad auch nichts gesagt, wenn nicht ausgerechnet in diesem Thread der Threadersteller hier zu der Annahme gekommen wäre, Methoden würden irgendwie während ihrer Ausführung auf magische Weise auf etwas anderes warten.

    Ah. Uh. Autsch. Verständlich.
    «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
  • macmoonshine schrieb:

    DKCode schrieb:

    Wie bringe ich die viewDidLoad Methode dazu, zu warten, bis die Benachrichtigung angekommen ist, bzw. die "methodOFReceivedNotication" vollständig durchgelaufen ist?

    Das ist ein asynchroner Vorgang: Das Betriebssystem sendet das Device-Token irgendwann an die App, während diese läuft. Da solltest du keine synchronen Techniken verwenden. In der Programmierung wie im richtigen Leben gilt folgende Regel (bitte mitschreiben): Warten ist immer Scheiße.

    Möglicher Lösungsweg:
    1. App-Delegate versendet Device-Token als Benachrichtigung (siehe oben).
    2. Viewcontroller registriert sich in viewDidLoad als Empfänger dieser Nachrichtenempfänger.
    3. Die Empfängermethode verarbeitet das Device-Token wie gewünscht.
    Anwendung und Beispiele für Benachrichtigungen: siehe oben!


    Ja so wäre ja der Plan, nur konnte ich den Viewcontroller nicht als Empfänger in der viewDidLoad registrieren. Die Registrierung musste in der Init passieren. Daher habe ich ja auch leider das Problem, das alles in einer falschen Reihenfolge abläuft :/

    Marco Feltmann schrieb:

    DKCode schrieb:

    Wie bringe ich die viewDidLoad Methode dazu, zu warten, bis die Benachrichtigung angekommen ist, bzw. die "methodOFReceivedNotication" vollständig durchgelaufen ist?

    Gar nicht. Die -viewDidLoad Methode wartet darauf, dass das View geladen wurde. (Ich weiß, der Methodenname ist in dem Zusammenhang arg verwirrend… +scnr+)

    PushNotifications sind asynchron. Auf asynchrone Antworten zu warten ist so ein bisschen wie 'Warten auf Godot'.
    Die Antwort kann innerhalb einer viertel Sekunde da sein. Oder nach drei Wochen. Oder gar nicht.

    Du müsstest also Deine Denkweise anpassen:
    statt unbedingt zur Anzeigezeit des Views den deviceToken einblenden zu wollen lieber erst bei Bekanntgabe des deviceToken diesen einblenden.

    Ganz stumpfes Beispiel: Das Textview, das den Token zeigen soll, mit einem 'Warte auf Token vom Server…' vorbelegen.
    Vielleicht nach einem Timeout noch in ein 'Seit 60 Sekunden kein Token erhalten. Device offline?' ändern.

    Und in der asynchron aufgerufenen Methode zur Notification einfach das Device Token im Textfeld setzen.
    Lieber drei Monate darauf warten, dass das Token im Textfeld auftaucht (und den Programmierer auslachen, dass er nur von Sekunden ausgegangen ist – gibt nach drei Monaten ne hübsche Zahl) als drei Monate darauf warten, dass das View endlich angezeigt wird.


    PushNotifications sind asynchron, das ist mir bewusst, aber es geht hier ja nicht um PushNotificaitions, sondern um die Benachrichtigungen die ich laut macmoonshine verwenden soll. Da diese Abläufe in der App passieren, sollte das Senden und Empfangen der NSNotification doch eigentlich synchron ablaufen und wenn nicht, dann immerhin ohne große Verzögerung?

    Dein Beispiel mit dem Textview klingt verständlich, aber ich kann so nicht vorgehen, da der DeviceToken, den ich per NSNotification an meinen ViewController sende, direkt an den WebView per URL mit übergeben werden muss. Nur so kann ich sicherstellen, dass wenn man im WebView auf registrieren klickt, auch der DeviceToken in der Datenbank gespeichert wird. Ansonsten wird das mit den PushNotifications leider nix.

    Michael schrieb:

    gandhi schrieb:

    Michael schrieb:

    Hier wartet der den Abholer Beauftragende, um die Abholung zu beauftragen.


    So wie sich das anhört, solltest Du dich zum Bürokratie-Beauftragten fortbilden. Oder Dich in Brüssel bei der EU-Kommision zur Formulierung von unverständlichen Verordnungen bewerben. Die suchen immer fähige Leute ;)

    Ja, ja, spotte du nur. ;)
    Ich hätte zu Marcos Ausführungen zur viewDidLoad auch nichts gesagt, wenn nicht ausgerechnet in diesem Thread der Threadersteller hier zu der Annahme gekommen wäre, Methoden würden irgendwie während ihrer Ausführung auf magische Weise auf etwas anderes warten.


    Wer hat denn hier etwas von magischer Weise gesagt? Ich hab doch lediglich gefragt, ob es möglich ist, eine Art "Wait" einzubauen :)

    gandhi schrieb:

    Michael schrieb:

    Methoden würden irgendwie während ihrer Ausführung auf magische Weise auf etwas anderes warten.


    Ja, das ist mir auch aufgefallen, dass es da am grundlegenden Verständnis eines Programmablaufs mangelt. Insofern ein guter Einwurf


    Richtig es fehlt definitiv am grundlegenden Verständnis eines Xcode Programmablaufs, aber innerhalb von knapp 3 Wochen ist noch kein Meister von Himmel gefallen ^^
  • Ich würde zu gerne mal wissen was das Endergebnis werden soll. Für mich klingt das alles total konfus. Du schickst Dir eine Push-Notification damit du einen DEvicetoken erhälst mit dem Du Dich via Webview bei einem Server anmelden kannst.....
    Dir ist schon klar, dass Du, um Push-Nachrichten an ein Device schicken zu können, dieses sich vorher eh schon bei Deinem Server mit seinem Token registriert haben muss, damit dieser überhaupt eine Push-Nachricht verschicken kann????
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • macmoonshine schrieb:

    Wozu brauchst du eigentlich das Token im Viewcontroller?


    Grob geraten weil er dort eine REgistrierungswebseite lädt in die er das Token eintragen will damit der Anwender nur noch den Submit Button klciken muss, da er nicht weiß wie man einen HHTP Request per Code macht?

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • DKCode schrieb:

    Da diese Abläufe in der App passieren, sollte das Senden und Empfangen der NSNotification doch eigentlich synchron ablaufen und wenn nicht, dann immerhin ohne große Verzögerung?

    Sollte, könnte, dürfte… NSNotification laufen ungefähr synchron ab, ja. Allerdings kann es auch da zu Verzögerungen kommen, je nach Auslastung des Gerätes. Es ist meines Wissens nicht definiert, wann genau eine Notification gesendet wird und wann genau der Observer aufgerufen wird. Es ist also durchaus nicht das Verkehrteste von einer Verzögerung von bis zu 1 Minute im allerschlimmsten Fall auszugehen. Ein bisschen Pessimismus hat noch niemandem geschadet.
    (Wie funktioniert das eigentlich in Swift? Ich meine, Objective-C ist ja von Natur aus geschwätzig und Swift eher introvertiert gestaltet…)

    Du möchtest also das Laden der Website so lange hinauszögern, bis Du ein Device Token erhalten hast.
    Dann setz' doch den WebView Inhalt erst, wenn die Notification da ist.

    Beispiel: Dein WebView zeigt eine vorgefertigte 'Wait for Device Token' Seite an, die Du meinetwegen direkt im .ipa auslieferst.
    In der für die Notification registrierten Methode lädst Du dann die URL, für die Du das Token brauchst.

    Wozu Du Dich mit einem Device Token anmelden willst ist mir allerdings auch unklar.
    Wie Thallius schon schrieb: um eine Push Notification zu bekommen musst Du Dich mit Deinem Device Token bereits registriert haben.

    Vermutung:
    Du möchtest das Device mit dem Token für weitere spezielle Push Notifications registrieren.
    Dafür hast Du mit dem WebView den vollkommen falschen Ansatz gewählt und Du solltest lieber NSURLSession benutzen.
    (Ich breche vielerorts eine Lanze für NSURLSession, obwohl NSURLConnection natürlich auch ginge…)
    «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
  • DKCode schrieb:

    Da diese Abläufe in der App passieren, sollte das Senden und Empfangen der NSNotification doch eigentlich synchron ablaufen und wenn nicht, dann immerhin ohne große Verzögerung?

    Nein, auch innerhalb einer App gibt es asynchrone Abläufe.
    Benachrichtigungen (NSNotification) können sowohl synchron, als auch asynchron verschickt werden. Das entscheidet der Sender der Benachrichtigung. Was immer asynchron bzw. vollkommen unabhängig voneinander ist, ist das Anmelden für eine Benachrichtigung und das Versenden einer Benachrichtigung. Mit der Anmeldung beim NSNotificationCenter sagt der Empfänger nur, dass er eine bestimmte Benachrichtigung empfangen will. Diese Anmeldung hat keinerlei Auswirkung auf den Sender. Der Sender verschickt die Benachrichtigung erst, wenn es einen Grund für die Benachrichtigung gibt.
  • Richtig; Das Betriebssystem die Delegate-Methode erst auf, wenn das Device-Token verfügbar ist. Wie das erstellt wird und wie lange das dauert weiß nur Apple alleine. Du hast hier also immer einen asynchronen Prozess. Benachrichtigungen oder KVO helfen dir allerdings dabei, damit einfacher umgehen zu können.
    „Meine Komplikation hatte eine Komplikation.“
  • Thallius schrieb:

    Ich würde zu gerne mal wissen was das Endergebnis werden soll. Für mich klingt das alles total konfus. Du schickst Dir eine Push-Notification damit du einen DEvicetoken erhälst mit dem Du Dich via Webview bei einem Server anmelden kannst.....
    Dir ist schon klar, dass Du, um Push-Nachrichten an ein Device schicken zu können, dieses sich vorher eh schon bei Deinem Server mit seinem Token registriert haben muss, damit dieser überhaupt eine Push-Nachricht verschicken kann????


    Ja das ist alles irgendwie durcheinander geraten. Eigentlich ist es aber recht simple. Ich habe vor einiger Zeit eine Idee als WebAPP umgesetzt. Diese Idee möchte ich als IOS und Android App ebenfalls umsetzen. Damit ich aber nun nicht Monate verstreichen lasse, um die Idee auf den Markt zu schmeißen, habe ich mich dafür entschieden WebViews zu nutzen, die vorerst meine WebApp laden.

    Parallel dazu mache ich die kompletten nativen Apps. Um das hinzubekommen brauche ich aber Zeit, da ich ganz einfach, wie ihr ja auch merkt, noch eine Menge lernen muss und möchte.

    Meine IOS App soll aber noch eine Zusatzfunktion haben. Sie soll einerseits die WebApp laden andererseits aber auch PushNotifications empfangen können. Und genau das ist der Punkt.

    Ablauf:

    1. User startet IOS App
    2. DeviceToken wird generiert bevor der WebView die Webapp lädt.
    3. DeviceToken wird an die Webapp-URL angehängt
    4. WebView lädt die Webapp und der DeviceToken wird automatisch dem manuellen Registrierungsformular übergeben. Gleiches passiert mit dem Facebook Button.
    5. Der User registriert sich und die Registrierung speichert den DeviceToken in der MySQL Datenbank
    6. Wenn nun in der WebApp eine Benachrichtigungsemail verschickt wird, wird parallel dazu das PHP Script für die PushNotification aufgerufen, der DeviceToken des Users aus der MySQL Datenbank geholt und die PushNotification abgefeuert.
    7. Bei jedem Login bzw. Aufruf der App, wird geprüft ob sich der DeviceToken verändert hat und gegebenenfalls in der MySQL Datenbank aktualisiert.

    Kurzform Native APP mit WebVew und PushNotifications :)

    macmoonshine schrieb:

    Wozu brauchst du eigentlich das Token im Viewcontroller?


    Das brauche ich, um wie oben beschrieben, den DeviceToken an die WebView-URL übergeben zu können.

    Thallius schrieb:

    macmoonshine schrieb:

    Wozu brauchst du eigentlich das Token im Viewcontroller?


    Grob geraten weil er dort eine REgistrierungswebseite lädt in die er das Token eintragen will damit der Anwender nur noch den Submit Button klciken muss, da er nicht weiß wie man einen HHTP Request per Code macht?

    Gruß

    Claus


    Fast ^^ siehe oben mein Vorhaben.

    Marco Feltmann schrieb:

    DKCode schrieb:

    Da diese Abläufe in der App passieren, sollte das Senden und Empfangen der NSNotification doch eigentlich synchron ablaufen und wenn nicht, dann immerhin ohne große Verzögerung?

    Sollte, könnte, dürfte… NSNotification laufen ungefähr synchron ab, ja. Allerdings kann es auch da zu Verzögerungen kommen, je nach Auslastung des Gerätes. Es ist meines Wissens nicht definiert, wann genau eine Notification gesendet wird und wann genau der Observer aufgerufen wird. Es ist also durchaus nicht das Verkehrteste von einer Verzögerung von bis zu 1 Minute im allerschlimmsten Fall auszugehen. Ein bisschen Pessimismus hat noch niemandem geschadet.
    (Wie funktioniert das eigentlich in Swift? Ich meine, Objective-C ist ja von Natur aus geschwätzig und Swift eher introvertiert gestaltet…)

    Du möchtest also das Laden der Website so lange hinauszögern, bis Du ein Device Token erhalten hast.
    Dann setz' doch den WebView Inhalt erst, wenn die Notification da ist.

    Beispiel: Dein WebView zeigt eine vorgefertigte 'Wait for Device Token' Seite an, die Du meinetwegen direkt im .ipa auslieferst.
    In der für die Notification registrierten Methode lädst Du dann die URL, für die Du das Token brauchst.

    Wozu Du Dich mit einem Device Token anmelden willst ist mir allerdings auch unklar.
    Wie Thallius schon schrieb: um eine Push Notification zu bekommen musst Du Dich mit Deinem Device Token bereits registriert haben.

    Vermutung:
    Du möchtest das Device mit dem Token für weitere spezielle Push Notifications registrieren.
    Dafür hast Du mit dem WebView den vollkommen falschen Ansatz gewählt und Du solltest lieber NSURLSession benutzen.
    (Ich breche vielerorts eine Lanze für NSURLSession, obwohl NSURLConnection natürlich auch ginge…)


    Die Idee mit der "Wait for Device Token" Seite ist ist eigentlich gar nicht mal so blöd. Allerdings wenn es wirklich bis zu 1 Minute dauern kann, geht das für den User natürlich gar nicht :/
    Ich wüsste leider auch nicht, wie ich der App sagen kann, "warte bis der Device Token übergeben wurde und lade erst dann die WebApp in den WebView"

    Michael schrieb:

    DKCode schrieb:

    Da diese Abläufe in der App passieren, sollte das Senden und Empfangen der NSNotification doch eigentlich synchron ablaufen und wenn nicht, dann immerhin ohne große Verzögerung?

    Nein, auch innerhalb einer App gibt es asynchrone Abläufe.
    Benachrichtigungen (NSNotification) können sowohl synchron, als auch asynchron verschickt werden. Das entscheidet der Sender der Benachrichtigung. Was immer asynchron bzw. vollkommen unabhängig voneinander ist, ist das Anmelden für eine Benachrichtigung und das Versenden einer Benachrichtigung. Mit der Anmeldung beim NSNotificationCenter sagt der Empfänger nur, dass er eine bestimmte Benachrichtigung empfangen will. Diese Anmeldung hat keinerlei Auswirkung auf den Sender. Der Sender verschickt die Benachrichtigung erst, wenn es einen Grund für die Benachrichtigung gibt.


    Ok das ist gut zu wissen :)
  • DKCode schrieb:

    Damit ich aber nun nicht Monate verstreichen lasse, um die Idee auf den Markt zu schmeißen, habe ich mich dafür entschieden WebViews zu nutzen, die vorerst meine WebApp laden.

    Damit dürftest Du auf Probleme beim Freigabeprozess von Apple stoßen.

    DKCode schrieb:

    Allerdings wenn es wirklich bis zu 1 Minute dauern kann, geht das für den User natürlich gar nicht

    Was tust Du, wenn das Gerät offline ist, es kein Token gibt weil die Server down sind etc.pp.?
    «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
  • Marco Feltmann schrieb:

    DKCode schrieb:

    Damit ich aber nun nicht Monate verstreichen lasse, um die Idee auf den Markt zu schmeißen, habe ich mich dafür entschieden WebViews zu nutzen, die vorerst meine WebApp laden.

    Damit dürftest Du auf Probleme beim Freigabeprozess von Apple stoßen.

    DKCode schrieb:

    Allerdings wenn es wirklich bis zu 1 Minute dauern kann, geht das für den User natürlich gar nicht

    Was tust Du, wenn das Gerät offline ist, es kein Token gibt weil die Server down sind etc.pp.?


    Ja da hab ich schon ein bisschen recherchiert, die IOS App wird dann zugelassen, wenn der WebView nicht nur eine Firmenwebsite lädt. Da meine WebApp aber viele Funktionen hat und diese dann auch mit PushNotifications verknüpft sind, wird es hier laut Erfahrungen Anderer keine Probleme geben.

    Wenn das Gerät offline ist, dann geht die App natürlich auch nicht. Das ist aber ein Risiko, welches ich beim Start der App eingehen kann, da jeder der diese App nutzten wird, sie entweder zu Hause oder aber an Orten verwenden wird, an denen es definitiv Empfang (also Mobiles Internet) gibt. In der heutigen Zeit ist es eher selten, das man ein Iphone ohne Mobiles Internet hat. Aber wie gesagt, ich möchte die App ja komplett als Native App umsetzen, dafür brauche ich aber noch etwas Zeit :)

    macmoonshine schrieb:

    DKCode schrieb:

    Das brauche ich, um wie oben beschrieben, den DeviceToken an die WebView-URL übergeben zu können.

    Warum versendest du das Token nicht per NSURLConnection.


    Die Frage ist ja, ob es dann noch genau so funktioniert wie ich mir das Vorstelle. Denn das Problem ist ja, das ich Daten in der URL des Webview mitgeben kann, wiederum aber nicht Daten aus dem Webview herausbekomme. Heißt wenn sich der User in der WebApp (im WebView) registriert kann ich ja nicht mehr zuordnen, welche Registrierung von der IOS App ausgeführt wurde. Somit müsste der Login / die Registrierung vorab in der Nativen App passieren. Das würde ich ja noch irgendwie hinbekommen. Das eigentlich Problem ist dann aber die Session die ich ja irgendwie generieren muss. In meiner Webapp macht das alles PHP aber in Swift kenn ich mich damit noch nicht aus :/